Aller au contenu
Financial Context Wiki

Gas et frais de transaction

Guide tenant compte du fork sur les unités de gas, les coûts intrinsèques et d'exécution, les plafonds de frais EIP-1559, le burn des frais de base, les frais de priorité, les REVERT, les pannes de gas, les remboursements, le gas des blobs et les composantes des frais L2.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

Le gas est l’unité comptable du protocole pour le travail d’exécution et l’accès à l’état ; les frais de gas constituent un montant monétaire calculé à partir des unités de gas facturées et d’un prix unitaire. Sur Ethereum avec EIP-1559, effectiveGasPrice = min(maxFeePerGas, baseFeePerGas + maxPriorityFeePerGas), les frais d’exécution sont gasUsed * effectiveGasPrice, la part correspondant aux frais de base est brûlée et celle de priorité est versée par l’intermédiaire du destinataire des frais du bloc. La limite de gas et les plafonds de frais autorisent des maximums ; ils ne sont pas automatiquement dépensés.

Le gas effectivement consommé dépend des calldata, du chemin des opcodes, de l’expansion mémoire, des accès cold et warm à l’état, des modifications du stockage, des appels imbriqués, des précompilés, du succès ou de l’échec, des remboursements et du fork actif. Un prix supérieur peut améliorer la compétitivité pour l’inclusion, mais ne corrige ni un REVERT, ni une limite de gas insuffisante, ni un contrat malveillant, ni une cotation périmée, ni des calldata erronées. Les transactions de blobs et de nombreuses L2 ajoutent des composantes distinctes liées aux données ou au protocole, qu’il ne faut pas assimiler par hypothèse au gas de l’EVM.

Frais de réseau
0,000462 native
Équivalent Fiat
$1,39
Frais de base
22 gwei

Les résultats sont des approximations pédagogiques. Ils excluent les règles du site, les taxes, la latence, le comportement d'Oracle et d'autres paramètres spécifiques au protocole, sauf indication contraire.

Fonctionnement

  1. Fixez la chaîne, le fork, le bloc ou state tag, le type de transaction, l’expéditeur, le nonce, la destination, la valeur, les calldata, l’access list, les champs de blobs, le token de gas et la devise des frais. Précisez si la cotation concerne une transaction L1, une exécution L2, une publication de données, un retrait ou un parcours composite.
  2. Reconstituez le gas intrinsèque avant l’exécution : enveloppe de transaction, coût des octets de calldata, création, access list et surcoût propre au type. Si la limite de gas est inférieure au gas intrinsèque ou si l’expéditeur ne satisfait pas les contrôles de validité du coût maximal, la transaction est rejetée avant toute exécution incluse, plutôt qu’incluse puis revertie.
  3. Tracez l’exécution selon le fork cible. Mesurez les coûts dynamiques des opcodes, l’expansion mémoire, les comptes ou slots de stockage cold et warm, SSTORE, la transmission du gas lors des appels, le transfert de valeur, le coût des précompilés, les logs et les remboursements. Une même fonction ABI peut suivre des branches différentes et consommer une quantité de gas différente selon l’état.
  4. Séparez les résultats. Une exécution réussie valide ses effets. REVERT annule le périmètre en échec et peut restituer le gas non utilisé dans cette frame ; un arrêt exceptionnel pour épuisement du gas consomme normalement le gas mis à disposition de la frame. Un échec de niveau supérieur inclus consomme néanmoins le nonce et le gas facturé, même si l’état du contrat, le transfert de valeur et les logs sont annulés.
  5. Valorisez le gas d’exécution. Pour une transaction de type 2, calculez le prix effectif à partir des frais de base, du plafond de priorité et du plafond total ; répartissez ensuite le gas facturé entre frais de base brûlés et frais de priorité. Distinguez le gas inutilisé et la marge non consommée du plafond de frais des remboursements protocolaires de gas, produits par un nettoyage d’état éligible et limités par le plafond de remboursement actif.
  6. Valorisez séparément les autres marchés de frais. Une transaction de blobs paie le gas d’exécution plus blobGasUsed * blobGasPrice, sous réserve de maxFeePerBlobGas ; les frais de base des blobs suivent leur propre mécanisme d’ajustement. Les frais payés par un utilisateur L2 peuvent inclure l’exécution L2, les données L1 compressées ou le coût des blobs, des frais d’opérateur ou de protocole et des marges, selon des formules et des scalaires propres au déploiement et à la mise à niveau.
  7. Rapprochez estimation, inclusion et reçu. Avant de signer, vérifiez que le solde couvre la valeur et les frais maximums autorisés, simulez sur un état fixé et définissez des plafonds bornés. Après inclusion, consignez la limite de gas, le gas consommé indiqué par le reçu, le prix effectif, les frais de base, les frais de priorité, les effets des remboursements, le gas des blobs, les champs de frais L2, le statut et la variation du solde ; traitez séparément l’erreur d’estimation, le remplacement et la finalité.

Exemples détaillés

  • Succès de type 2 et plafonds. La limite de gas est de 120,000, le gas consommé de 70,000, les frais de base de 25 gwei, les frais maximums de priorité de 3 gwei et les frais maximums de 40 gwei. Le prix effectif est min(40, 25 + 3) = 28 gwei ; les frais réels sont 70,000 * 28 gwei = 0.001960 ETH, répartis entre 0.001750 ETH brûlés et 0.000210 ETH de frais de priorité. L’autorisation maximale des frais d’exécution est de 120,000 * 40 gwei = 0.004800 ETH ; les 50,000 gas inutilisés et la marge non consommée du plafond ne sont pas des remboursements protocolaires liés au nettoyage.
  • REVERT contre épuisement du gas. Deux appels inclus ont chacun une limite de gas de 100,000 et un prix effectif de 30 gwei. L’appel A exécute REVERT lorsque le gas consommé du reçu atteint 60,000 ; ses frais sont donc de 60,000 * 30 gwei = 0.001800 ETH. L’appel B épuise toute la limite de gas de la transaction ; ses frais sont donc de 100,000 * 30 gwei = 0.003000 ETH. Ces deux échecs de niveau supérieur annulent les effets du contrat et consomment le nonce de l’expéditeur, mais REVERT peut préserver du gas inutilisé, contrairement à l’épuisement du gas.
  • Plafond de remboursement. Dans un cas pédagogique EIP-3529 circonscrit à un fork, l’exécution consomme 100,000 gas avant remboursement et génère un compteur de remboursement de 30,000 gas. Le remboursement maximum appliqué est de 100,000 / 5 = 20,000 gas ; le gas facturé est donc de 100,000 - 20,000 = 80,000 gas. À 20 gwei, les frais sont de 0.001600 ETH au lieu de 0.002000 ETH, soit une économie de 0.000400 ETH ; les règles et opérations éligibles peuvent changer selon le fork.
  • Marché distinct des frais de blobs. Une transaction hypothétique de blobs consomme 100,000 unités de gas d’exécution à 20 gwei et contient deux blobs. Avec 131,072 blob gas/blob, le gas de blobs consommé est de 262,144 ; à un prix du gas de blobs de 5 gwei, les frais de blobs sont de 262,144 * 5 gwei = 0.00131072 ETH. Les frais d’exécution sont de 0.002000 ETH ; les frais protocolaires combinés s’élèvent donc à 0.00331072 ETH. Les 5 gwei retenus sont illustratifs, et les frais de blobs ne constituent ni un pourboire de priorité au validateur ni la totalité des frais de bout en bout d’un utilisateur L2.

Risques

  • Utiliser une chaîne, un fork, un token de gas, un type de transaction ou une devise de frais erronés.
  • Confondre les unités de gas, wei, gwei, ETH et les conversions en monnaie fiduciaire.
  • Traiter la limite de gas comme les frais attendus ou réels.
  • Échouer aux contrôles préalables du gas intrinsèque ou du coût maximal.
  • Se fier à une estimation périmée après modification de l’état, des frais de base ou des calldata.
  • Fixer une limite de gas inférieure aux besoins de la branche réellement exécutée.
  • Supposer qu’un prix du gas supérieur peut empêcher un REVERT du contrat.
  • Confondre REVERT, épuisement du gas, opcode non valide et rejet avant validation.
  • Manquer l’échec intercepté d’un appel enfant malgré un statut supérieur 1.
  • Mal valoriser les accès cold et warm à l’état ou utiliser une access list incomplète.
  • Ignorer l’expansion mémoire, la transmission du gas, les précompilés ou le coût des logs.
  • Appliquer des règles obsolètes de remboursement du stockage ou dépasser le plafond.
  • Comptabiliser le gas inutilisé ou la marge du plafond comme remboursement protocolaire de gas.
  • Fixer les frais maximums sous les frais de base du bloc d’inclusion.
  • Surpayer la priorité sans comprendre la politique du builder ou du séquenceur.
  • Ne pas détenir le token de gas natif malgré la détention d’autres actifs.
  • Omettre le gas des blobs, son plafond de frais ou les frais de disponibilité des données.
  • Considérer comme universelle la formule d’exécution, de données, de scalaires et d’opérateur d’une L2.
  • Ignorer les courses liées au remplacement, au nonce, à une transaction abandonnée et à la réservation du solde.
  • Considérer une transaction payée ou réussie comme une preuve de sécurité du contrat ou de finalité.

Idées reçues

  • Le gas représente un pourcentage de la valeur transférée.
  • Augmenter la limite de gas accroît nécessairement le montant facturé.
  • Des frais maximums ou de priorité élevés garantissent une exécution réussie.
  • Toute autorisation inutilisée et tout remboursement pour nettoyage de l’état relèvent du même mécanisme.
  • Les frais L2 se limitent au gas EVM local et les frais de blobs sont du gas d’exécution ordinaire.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...