La mécanique du gaz en détail : unité de mesure, marché des frais et interruption d'exécution

Un virement ETH minimal consomme invariablement 21 000 gaz (Gtransaction de l'annexe G du Yellow Paper) ; la consommation d'un virement ERC-20 dépend de l'implémentation du contrat et de l'état froid ou chaud des slots, et se situe le plus souvent dans l'ordre de plusieurs dizaines de milliers de gaz — estimation d'ordre de grandeur, et non mesure réelle. Ces nombres sont fixés par le protocole et seul un hard fork les modifie ; en revanche, la quantité d'ETH réellement payée pour une même transaction peut varier d'un facteur dix en quelques heures. Le premier est une unité de mesure, la seconde un prix. Ce n'est qu'en séparant ces deux notions que l'on peut discuter proprement des frais, du récit de scalabilité et du comportement à l'interruption d'exécution.

Le mécanisme du gaz assume simultanément trois fonctions : convertir calculs et opérations d'état en une unité commune, répartir un espace de bloc limité au moyen d'un marché de prix, et offrir une frontière d'annulation déterministe lorsque les ressources s'épuisent. L'article suit ces trois fils : ce que contiennent respectivement le coût intrinsèque et le coût dynamique, comment sont tarifés les accès froids et chauds, ce que rembourse une transaction selon qu'elle se termine comme invalide, en REVERT ou en out-of-gas, où passent les frontières entre base fee, priority fee et gaz de la couche d'exécution après l'EIP-1559, et pourquoi le gaz rend le DoS tarifable sans pour autant rendre la tarification toujours juste.

Le gaz est une unité de mesure du calcul et du stockage, pas un prix de jeton

Le gaz est une unité de compte abstraite, qui correspond à la quantité de ressources consommée par l'exécution d'une instruction, une lecture-écriture d'état ou l'extension d'un mot de mémoire. Sa valeur est donnée par des constantes de protocole : par exemple 3 gaz pour une addition (Gverylow), 100 gaz pour un SLOAD en accès chaud après Berlin (bloc 12 244 000, 15 avril 2021), 20 000 gaz pour un SSTORE écrivant une valeur non nulle à partir de zéro. Ces constantes ne changent que par hard fork et sont indépendantes de l'offre et de la demande du marché.

Le prix du gaz s'exprime en wei, l'unité courante étant le gwei, avec 1 gwei = 10⁹ wei. Les frais d'une transaction valent gas_used multiplié par effective_gas_price, la première grandeur étant déterminée par le déroulement de l'exécution et la seconde conjointement par le marché des frais et l'offre inscrite dans la signature de la transaction. Cette relation multiplicative est la base de toute la suite.

Distinguer ces deux niveaux présente plusieurs avantages immédiats. Quand on parle de « réduire le gaz », il faut d'abord vérifier si l'objectif est de baisser gas_used ou le gas price : le premier suppose de réduire les opérations, d'optimiser la disposition du stockage ou de modifier les règles de tarification de l'EVM, tandis que le second dépend de la demande du moment et de la forme du marché des frais — l'EIP-1559 a rendu ce dernier plus prévisible, sans changer le prix d'une seule instruction. Quand on parle de « qui encaisse les frais », la part du base fee est détruite par le protocole et n'a donc aucun bénéficiaire, seuls les priority fee entrant sur le compte du validateur. Quand on parle de « plafond de transaction », gas_limit est un plafond de capacité et non de frais ; le plafond de frais est max_fee_per_gas, un champ distinct.

Coût intrinsèque : la part débitée avant même le début de l'exécution

Chaque transaction paie d'abord un coût intrinsèque (intrinsic gas), débité avant que l'EVM n'exécute sa première instruction. La formule (64) du Yellow Paper le note g₀ : un prix de base fixe de 21 000 (Gtransaction), auquel s'ajoutent 4 gaz par octet nul et 16 gaz par octet non nul du champ de données (le prix de l'octet non nul ayant été ramené de 68 à 16 par l'EIP-2028, hard fork Istanbul, bloc 9 069 000, 8 décembre 2019), puis 32 000 de plus s'il s'agit d'une transaction de création de contrat (Gtxcreate) ; après l'EIP-2930 (hard fork Berlin, bloc 12 244 000, 15 avril 2021), 2 400 gaz par adresse et 1 900 gaz par clé de stockage figurant dans l'access list ; après l'EIP-3860 (hard fork Shanghai, bloc 17 034 870, 12 avril 2023), 2 gaz de plus par mot de 32 octets d'initcode lors d'une création de contrat.

La signification de 21 000 se lit facilement à tort comme « les frais d'un virement ». Formulé exactement, ce nombre représente le prix plancher du simple fait qu'« il y a une transaction », indépendamment du montant transféré. Un virement ETH minimal a un calldata vide, la partie données n'entraîne donc aucun coût supplémentaire, d'où précisément 21 000.

L'EIP-2929 (hard fork Berlin, bloc 12 244 000, 15 avril 2021) définit en outre l'ensemble chaud au début d'une transaction : l'adresse de l'expéditeur, celle du destinataire (pour une transaction de création, l'adresse créée) et toutes les adresses des contrats précompilés figurent déjà dans accessed_addresses et ne sont pas facturées comme accès froid. C'est pourquoi, lorsqu'un virement vise une adresse ordinaire, l'accès au compte du destinataire n'entraîne aucun frais supplémentaire.

Le coût intrinsèque étant débité avant l'exécution, trois frontières de comportement en découlent. Une transaction dont le gas_limit est inférieur au coût intrinsèque est purement invalide : elle n'est pas incluse dans un bloc et aucun gaz n'est débité. En cas d'interruption en cours d'exécution pour out-of-gas, le coût intrinsèque n'est pas remboursé. Les 2 400 et 1 900 de l'access list (tarifs d'après Berlin) relèvent du prépaiement : on parcourt à l'avance les adresses et slots qui seront visités pour les placer en état chaud, mais si l'exécution ne les visite finalement pas, la somme n'est pas restituée.

Coût dynamique : comment s'additionnent extension de mémoire et accès froids ou chauds

Le coût de la phase d'exécution est la somme d'une partie statique et d'une partie dynamique. La partie statique est le prix fixe de l'opcode, exprimé par la table des frais de l'annexe G du Yellow Paper en quelques paliers : Gverylow 3 gaz (ADD, SUB, MLOAD, MSTORE, la famille PUSH, etc.), Glow 5, Gmid 8, Ghigh 10, Gbase 2, Gjumpdest 1.

La partie dynamique dépend de la taille des opérandes et de l'état froid ou chaud des accès. L'extension de mémoire se tarife selon C_mem(a) = 3a + ⌊a² / 512⌋ (formule (328) du Yellow Paper, Gmemory = 3), où a est le nombre de mots ; le montant débité est la différence avant et après extension, ce poste restant à peu près linéaire jusqu'à 704 octets (22 mots), au-delà desquels le terme quadratique entre en jeu. Les opérations de copie ajoutent 3 gaz par mot au prix de base (Gcopy) ; KECCAK256 coûte 30 gaz (Gkeccak256) plus 6 gaz par mot (Gkeccak256word) ; LOG coûte 375 gaz (Glog) plus 375 gaz par topic (Glogtopic), puis 8 gaz par octet (Glogdata) ; EXP coûte 10 gaz (Gexp) plus 50 gaz par octet d'exposant (Gexpbyte).

Les accès froids et chauds sont définis par l'EIP-2929 (hard fork Berlin). Le premier accès à une paire (adresse, slot) est un accès froid, facturé 2 100 gaz pour un SLOAD ; un nouvel accès dans la même transaction est un accès chaud, facturé 100 gaz. Le prix froid d'un accès à un compte est de 2 600 gaz, pour CALL, CALLCODE, DELEGATECALL, STATICCALL, BALANCE ainsi que EXTCODESIZE, EXTCODECOPY et EXTCODEHASH. Cet ensemble a pour portée la transaction et est annulé en même temps qu'elle.

Le mécanisme froid/chaud vient directement des leçons laissées par deux attaques DoS. L'EIP-150 (Tangerine Whistle, bloc 2 463 000, 18 octobre 2016), après les attaques de septembre et octobre 2016, avait déjà fait passer SLOAD de 50 à 200 gaz, CALL de 40 à 700 et SELFDESTRUCT de 0 à 5 000. La motivation de l'EIP-2929 cite une mesure tirée de l'article arXiv:1909.07220 paru en 2019 : en rejouant l'historique d'Ethereum sur le matériel des auteurs, le même lot de transactions malveillantes mettait 20 à 80 secondes, contre quelques millisecondes pour des transactions ordinaires, signe que les opcodes de lecture d'état restaient sous-tarifés. Il s'agit d'une mesure ponctuelle, représentative du seul matériel et de la seule charge de 2019, qui ne peut servir de référence suivie dans le temps.

Trois issues possibles à l'interruption d'exécution : transaction invalide, REVERT et out-of-gas

Une transaction peut se terminer à trois stades différents, avec chaque fois une portée d'annulation et un traitement des frais distincts.

La première est la transaction invalide : nonce qui ne correspond pas, signature erronée, solde insuffisant pour couvrir l'avance de gaz, gas_limit inférieur au coût intrinsèque, etc. Ce type de transaction n'entre jamais dans un bloc et ne consomme aucun gaz ; il s'agit d'un rejet hors chaîne, tout autre chose qu'une interruption d'exécution.

La deuxième est le REVERT, déclenché par une instruction revert, l'échec d'un require ou un revert d'assemblage inline. Toutes les modifications d'état du cadre courant sont annulées, le gaz restant est rendu à la couche supérieure et la part déjà consommée reste due ; le compteur de remboursement est lui aussi ramené à son état d'avant l'entrée dans le cadre. Le REVERT est un « échec motivé », capable de renvoyer des données d'erreur, adapté aux cas où l'appelant doit distinguer la cause de l'échec.

La troisième est l'arrêt exceptionnel (exceptional halt) : out-of-gas, opcode invalide, débordement de pile, écriture d'état dans un appel statique, initcode hors limite, etc. L'état est annulé de la même façon, mais tout le gaz restant dans le cadre courant est détruit. Si l'exception survient dans le cadre de plus haut niveau, le gas_used de la transaction égale son gas_limit et les frais sont débités en totalité, sans part restituée. Telle est la signification exacte de « après un OOG, tout le gaz est consommé » : le gaz restant du cadre courant tombe à zéro, indépendamment du solde de la chaîne entière.

// REVERT : annulation de l'état, restitution du gaz restant, paiement de ce qui a été consommé
function guarded(uint256 x) external pure returns (uint256) {
    require(x != 0, "zero");
    return 1e18 / x;
}

// Arrêt exceptionnel : une boucle infinie déclenche un out-of-gas, tout le gaz restant du cadre courant est détruit
function oog() external pure {
    while (true) {}
}

Savoir si l'échec d'un sous-appel entraîne le cadre parent dépend de la règle des « 1/64 réservés » introduite par l'EIP-150 (Tangerine Whistle). Lors d'un appel à un cadre enfant, le cadre parent ne peut transmettre au maximum que 63/64 de son gaz restant (soit gas - gas // 64) et doit en conserver au moins 1/64 ; CREATE et CREATE2 ne fournissent eux aussi que 63/64. Un OOG dans le cadre enfant n'entraîne donc pas d'OOG dans le parent, qui peut capturer l'échec avec le gaz réservé et poursuivre l'exécution. Cette règle a remplacé en 2016 l'ancienne limite de profondeur d'appel et a fait passer la « bombe de profondeur » du rang d'attaque structurelle à celui de simple problème de gaz.

// Transfère au maximum 63/64 de gasleft() au sous-appel, le cadre parent en conserve 1/64
(bool ok, ) = target.call{gas: gasleft()}("");

Un CALL porteur de value comporte deux postes supplémentaires (annexe G du Yellow Paper) : un transfert non nul coûte Gcallvalue 9 000 gaz, et si le compte cible n'existe pas, Gnewaccount 25 000 gaz de plus ; l'appelé reçoit en outre une allocation d'appel de 2 300 gaz (Gcallstipend), destinée à la logique de réception la plus simple. L'EIP-2200 (hard fork Istanbul, bloc 9 069 000, 8 décembre 2019) impose qu'un SSTORE échoue directement en OOG lorsque gasleft est inférieur ou égal à 2 300, précisément pour empêcher que cette allocation serve à écrire dans l'état.

Le remboursement (refund) est réglé après la fin de l'exécution de la transaction et reste invisible pendant celle-ci. L'EIP-3529 (hard fork London, bloc 12 965 000, 5 août 2021) fait passer le remboursement pour réécriture d'une valeur non nulle vers zéro de 15 000 à 4 800, supprime le remboursement de SELFDESTRUCT et ramène le plafond de remboursement total d'une transaction à gas_used // 5. Le remboursement n'étant pas disponible pendant l'exécution, un contrat ne peut pas compter sur lui pour avancer le gaz nécessaire en cours de transaction.

EIP-1559 : base fee, tip et frontière de la couche d'exécution

L'EIP-1559 (hard fork London, bloc 12 965 000, 5 août 2021) décompose les frais de transaction en deux segments. Le base fee est calculé par le protocole à partir du gas_used du bloc parent et d'une valeur cible (la moitié du gas_limit), avec un ajustement maximal de 12,5 % d'un bloc à l'autre, et il est détruit. Le priority fee (tip) est le prix unitaire supplémentaire offert par l'utilisateur au validateur pour obtenir un empaquetage plus rapide. La signature de la transaction porte deux plafonds, max_fee_per_gas et max_priority_fee_per_gas ; le prix unitaire effectif s'obtient ainsi : le priority fee est le minimum entre max_priority_fee_per_gas et (max_fee_per_gas - base fee), et effective_gas_price vaut priority fee plus base fee. Le gaz non utilisé est remboursé à ce prix unitaire.

La frontière avec la couche d'exécution mérite elle aussi d'être précisée. Après l'EIP-1559, l'opcode GASPRICE renvoie effective_gas_price, c'est-à-dire le prix unitaire réellement payé par l'expéditeur ; la part effectivement perçue par le validateur n'est pas directement lisible depuis l'environnement d'exécution. Autrement dit, toute logique ancienne qui s'appuierait sur GASPRICE pour estimer un « revenu de mineur » n'est plus valable.

Les deux segments de frais répondent à des questions différentes : le base fee fixe le seuil minimal d'entrée dans un bloc, le tip détermine la priorité au sein d'un même bloc. La quantité totale d'espace de bloc ne change pas ; lorsque l'usage durable dépasse la valeur cible, le base fee monte bloc après bloc pour évincer la demande — mécanisme de file d'attente, sans rapport avec une expansion de capacité. Prendre l'EIP-1559 pour une solution de réduction de gas_used est un contresens courant : elle ne modifie que la formation du prix.

Une dernière frontière prête à confusion : les frais de blob ne relèvent pas du gaz de la couche d'exécution. L'EIP-4844 (hard fork Cancun, bloc 19 426 587, 13 mars 2024) a introduit pour les données blob un base fee et une unité de compte distincts (le blob gas), et l'EIP-7516 a ajouté un opcode renvoyant le blob base fee. Le coût de publication des données d'un rollup se discute sur le marché des blobs, qui constitue une comptabilité distincte du gaz consommé par l'exécution des contrats.

« Tarifable » ne signifie pas « correctement tarifé » pour un DoS

La propriété de sécurité centrale du gaz est de convertir l'occupation de ressources en coût. Pour saturer un bloc de transactions indésirables, un attaquant doit payer le montant correspondant à la totalité du gaz du bloc : c'est ce que signifie « tarifable ». Par rapport à un réseau gratuit, le coût marginal d'une attaque passe de zéro à une valeur proportionnelle à l'occupation.

Mais cela ne tient que si la tarification correspond au coût réel. Les attaques DoS de septembre et octobre 2016 exploitaient précisément des opcodes de lecture d'état et d'appel sous-évalués, et ont directement provoqué le hard fork Tangerine Whistle ; par la suite, l'EIP-1884 (hard fork Istanbul, bloc 9 069 000, 8 décembre 2019) a fait passer SLOAD de 200 à 800 gaz, BALANCE et EXTCODEHASH de 400 à 700, puis l'EIP-2929 a scindé l'accès à l'état en deux paliers froid et chaud en relevant fortement le prix de l'accès froid, toujours pour la même raison : le même schéma peut porter le temps de traitement d'un bloc à plusieurs dizaines de secondes. L'EIP-3860 régit l'analyse des cibles de saut de l'initcode, un travail jusque-là totalement non mesuré. Il existe un décalage structurel entre les règles de tarification et le coût réel des implémentations : la disposition des bases de données et les moteurs d'exécution des clients s'optimisent en continu, tandis que les constantes de gaz doivent attendre le hard fork suivant pour être réévaluées.

Le mécanisme de remboursement fournit l'exemple inverse. Il devait encourager les contrats à nettoyer l'état devenu inutile, mais a en pratique donné naissance à des schémas comme GasToken, qui traitent les slots d'état comme des batteries : accumuler du gaz quand les tarifs sont bas, le libérer quand ils sont hauts, d'où un gonflement de l'état et une variance supplémentaire de l'usage de gaz par bloc. Si l'EIP-3529 réduit et plafonne les remboursements, c'est précisément pour fermer cette voie.

Plusieurs conditions de défaillance du mécanisme méritent d'être signalées séparément. La tarification est un produit de la gouvernance et ses constantes sont généralement choisies d'après le pire cas de chaque implémentation (l'EIP-3860 précise ainsi que ses 2 gaz par mot proviennent des benchmarks du pire cas de différentes implémentations) ; or les clients ne mettent pas le même temps sur un même lot d'opérations, si bien qu'un même prix de gaz ne correspond pas à un coût réel en ressources identique. Il s'agit là d'un jugement qualitatif ; la preuve quantitative avancée par l'EIP-2929 pour justifier sa hausse de prix est une mesure ponctuelle de 2019 sur une configuration matérielle donnée, qui ne peut servir de référence continue. La valeur du marché d'ordonnancement ne repose pas entièrement sur le tip : les enchères MEV et les stratégies des clients influencent aussi l'ordre d'empaquetage, et un tip élevé n'est qu'un des stimulants qui augmentent la probabilité d'entrer dans le bloc suivant. Le plafond de gaz par bloc est lui-même un compromis entre débit et coût de vérification, et le relever relève d'autant le seuil matériel des nœuds complets.

Ce passage vise à montrer qu'il s'agit d'un mécanisme à recalibrer régulièrement : « la tarification du gaz est fiable » et « la tarification du gaz n'est pas fiable » sont l'une comme l'autre des conclusions trop fortes. EIP-150, EIP-1884, EIP-2929 et EIP-3860 sont autant d'actes de recalibrage. Quant à savoir ce qui déclenchera le prochain, on ne peut avancer qu'une conjecture et non une conclusion : les quatre recalibrages ayant tous eu pour cause directe une attaque par amplification de ressources observée publiquement, on peut conjecturer que le prochain relèvera probablement du même type d'événement. Cette conjecture n'a pas de fondement public, et l'on ne peut exclure une réévaluation anticipée motivée par d'autres considérations, comme la croissance de l'état ou la capacité des blocs.

Frontières et zones d'incertitude

Les références citées sont la table des frais de l'annexe G du Yellow Paper et ses formules (64) et (328) (la version téléchargée portant la mention Shanghai en pied de page), ainsi que les textes normatifs des EIP-150, EIP-1884, EIP-2028, EIP-2200, EIP-1559, EIP-2929, EIP-2930, EIP-3529 et EIP-3860. Les chiffres précis varient selon les forks ; les forks et hauteurs de bloc indiqués dans le corps de l'article sont : Istanbul (8 décembre 2019, bloc 9 069 000), Berlin (15 avril 2021, bloc 12 244 000), London (5 août 2021, bloc 12 965 000), Shanghai (12 avril 2023, bloc 17 034 870), Cancun (13 mars 2024, bloc 19 426 587). Avant de parler de gaz sur une chaîne compatible EVM, il faut vérifier quels forks cette chaîne a activés, car les constantes de tarification peuvent différer de celles du réseau principal Ethereum. La hauteur de bloc 2 463 000 et la date du 18 octobre 2016 pour Tangerine Whistle proviennent également de l'historique des mises à niveau d'ethereum.org.

Sur l'ampleur du « retard de tarification », on ne peut produire que des indices indirects, pas de conclusion quantitative : les documents publics ne contiennent aucune série temporelle suivant dans la durée le rapport entre les constantes de gaz du protocole et les temps d'exécution réels, ce qui interdit de dire si le retard se creuse ou se résorbe. Ce point doit être conservé comme incertitude, sans en tirer des conclusions du type « la situation se dégrade » ou « la situation s'est stabilisée ».

Par ailleurs, le comportement du marché des frais subit l'influence du MEV et des stratégies des clients ; les détails de mécanique du marché d'ordonnancement ne sont pas développés ici, pas plus que n'est menée une comparaison, dans un même cadre, entre le marché des frais de blob et le gaz de la couche d'exécution — depuis l'EIP-4844, ce sont deux systèmes de tarification séparés. Pour bâtir un modèle de coûts à partir de ces chiffres, il faut d'abord en vérifier la base et la version.

Sources

• EIP-1559, Fee market change for ETH 1.0 chain : https://eips.ethereum.org/EIPS/eip-1559
• EIP-2929, Gas cost increases for state access opcodes : https://eips.ethereum.org/EIPS/eip-2929
• EIP-3529, Reduction in refunds : https://eips.ethereum.org/EIPS/eip-3529
• EIP-150, Gas cost changes for IO-heavy operations : https://eips.ethereum.org/EIPS/eip-150
• EIP-1884, Repricing for trie-size-dependent opcodes : https://eips.ethereum.org/EIPS/eip-1884
• EIP-2028, Transaction data gas cost reduction : https://eips.ethereum.org/EIPS/eip-2028
• EIP-2200, Structured Definitions for Net Gas Metering : https://eips.ethereum.org/EIPS/eip-2200
• EIP-2930, Optional access lists : https://eips.ethereum.org/EIPS/eip-2930
• EIP-3860, Limit and meter initcode : https://eips.ethereum.org/EIPS/eip-3860
• EIP-4844, Shard Blob Transactions : https://eips.ethereum.org/EIPS/eip-4844
• EIP-7516, BLOBBASEFEE opcode : https://eips.ethereum.org/EIPS/eip-7516
• Ethereum Yellow Paper, table des frais de l'annexe G, formule (64) du coût intrinsèque et formule (328) de tarification de la mémoire : https://ethereum.github.io/yellowpaper/paper.pdf
• ethereum.org, documentation développeur sur le gaz et les frais : https://ethereum.org/en/developers/docs/gas/
• ethereum.org, référence des opcodes : https://ethereum.org/en/developers/docs/evm/opcodes/
• ethereum.org, historique des mises à niveau du réseau (hauteur de bloc et date de chaque fork) : https://ethereum.org/en/history/
• arXiv:1909.07220, mesure des temps d'accès à l'état citée par l'EIP-2929 : https://arxiv.org/abs/1909.07220

Pour aller plus loin

Cet article fait partie de la série sur les fondamentaux de l'EVM ; le précédent est 0.5 « Ne pas confondre les trois types de stockage : Memory, Storage et Transient Storage ».