La limite de gas d’un bloc Ethereum désigne la quantité maximale de gas autorisée dans ce bloc. La limite de gas d’une transaction désigne le maximum que son émetteur accepte de consommer pour cette opération. Le gas utilisé correspond, lui, à la consommation effective. Séparer ces trois quantités permet de comprendre ce que signifie la capacité d’un bloc.
Cette distinction aide aussi à lire les données techniques : un plafond, une consommation mesurée et un prix répondent à des questions différentes. Ce guide explique leurs relations sans donner de capacité numérique actuelle ni prévoir les prix des transactions.
Trois quantités de gas, trois questions différentes
Le gas mesure l’effort de calcul nécessaire à l’exécution d’opérations sur Ethereum. Pour interpréter un nombre exprimé en gas, commencez par lui associer la bonne question :
- Limite de gas de la transaction : quel maximum l’émetteur fixe-t-il pour cette opération ?
- Gas utilisé par la transaction : quelle quantité cette opération a-t-elle effectivement consommée ?
- Limite de gas du bloc : quelle quantité maximale est autorisée pour l’ensemble de ce bloc ?
Le plafond d’une transaction ne promet ni une consommation égale à ce maximum ni la réussite de son exécution. La documentation Ethereum présente un exemple de transfert simple dont la consommation est inférieure à la limite définie. Cet exemple démontre qu’une consommation inférieure est possible ; il ne fixe pas une quantité universelle applicable aux autres opérations.
À l’échelle du bloc, la même distinction subsiste entre maximum et consommation. Le bloc possède son propre plafond et un total de gas utilisé. Ce total concerne toutes les transactions qu’il contient, tandis que la consommation d’une transaction ne concerne que cette opération.
La capacité du bloc est un plafond, distinct de la cible
La limite de gas du bloc constitue une borne supérieure. La cible de consommation décrite dans la documentation correspond à la moitié de la limite de gas du bloc. Ces deux repères restent distincts : la cible n’impose pas que chaque bloc consomme exactement cette quantité, et le maximum autorisé ne doit pas être présenté comme la cible.
Ainsi, dire qu’un bloc reste sous sa limite compare sa consommation au plafond. Cette seule information ne permet pas de déterminer si sa consommation se situe au-dessus ou au-dessous de la cible. Pour répondre à cette seconde question, il faut également effectuer la comparaison avec cette cible.
La limite de gas des blocs peut évoluer dans le temps par la signalisation des validateurs et lors de mises à niveau du réseau. Un chiffre de capacité doit donc rester associé au bloc ou à la période qu’il décrit. Aucune valeur numérique actuelle ni date de changement n’est avancée ici.
Il faut également distinguer les paramètres du réseau des réglages propres à une transaction. L’émetteur définit un plafond pour son opération ; le bloc possède un maximum distinct. De ces définitions et des mécanismes documentés de modification de la capacité, on déduit que modifier la limite d’une transaction ne modifie pas, en soi, celle du bloc.
Pourquoi une limite de gas n’est pas un prix
Une limite de gas répond à une question de quantité. Un prix par unité de gas répond à une question de coût monétaire. Les frais de gas d’exécution associent consommation et prix unitaire : ils correspondent au gas utilisé multiplié par le coût de chaque unité. Cette relation décrit les frais d’exécution sans prétendre recenser tous les frais possibles d’une opération.
La différence se déduit des unités : un maximum exprimé en gas et un prix exprimé en monnaie par unité de gas ne sont pas interchangeables. Cette déduction repose sur leurs définitions ; elle ne signifie pas que capacité des blocs et prix seraient économiquement sans rapport.
La méthode JSON-RPC eth_gasPrice, par exemple, renvoie une estimation du prix actuel par unité de gas, exprimé en wei. Son résultat est une estimation de prix, et non une mesure de capacité ou une garantie sur le prix d’une exécution future.
Pour approfondir la distinction entre coût d’exécution et valeur transférée, consultez notre article sur les frais de gas Ethereum et le montant envoyé. Ici, l’objectif reste de séparer capacité, plafond d’une transaction et consommation.
Un exemple hypothétique aux limites explicites
Imaginons un bloc fictif, créé uniquement pour cet exercice, dont la limite serait de 1 000 000 d’unités de gas. Posons qu’il contient seulement deux transactions, toutes deux déjà exécutées :
- La transaction A possède une limite de 100 000 unités de gas et en consomme 60 000.
- La transaction B possède une limite de 120 000 unités de gas et en consomme 90 000.
Ces valeurs sont des hypothèses pédagogiques inventées. Elles ne représentent ni des mesures actuelles d’Ethereum ni des réglages conseillés. Une consommation inférieure au plafond individuel est cohérente avec la possibilité illustrée dans la documentation.
Le gas utilisé par un bloc totalisant la consommation de ses transactions, on déduit des hypothèses que ce bloc consomme 150 000 unités : 60 000 plus 90 000. Ce total est inférieur à son plafond fictif de 1 000 000. Le résultat découle d’un calcul sur les données posées et de la définition de la consommation du bloc.
La comparaison s’arrête volontairement à la consommation par rapport à la capacité. Elle ne prédit pas l’inclusion. Pour être admissible à l’inclusion, le prix proposé par unité de gas doit aussi être au moins égal aux frais de base du bloc. Comme l’exercice ne fournit aucun prix proposé, on en déduit qu’il ne permet pas d’établir le respect de cette condition distincte. Satisfaire cette condition nécessaire ne garantit pas non plus l’inclusion.
L’exercice ne décrit pas davantage un algorithme complet de construction des blocs. Il ne permet donc pas d’établir une règle selon laquelle additionner les plafonds des transactions suffirait à décider lesquelles seront incluses.
Lire chaque champ dans le contexte de son objet
La documentation JSON-RPC d’Ethereum distingue les champs concernés. Dans un objet représentant un bloc, gasLimit désigne le maximum autorisé et gasUsed le total consommé par toutes ses transactions. Dans le reçu d’une transaction, gasUsed concerne uniquement cette transaction.
Le contexte de l’objet compte donc autant que le nom du champ. Avant de comparer une valeur à une limite, précisez si elle représente la consommation du bloc ou celle d’une transaction. Deux champs nommés gasUsed peuvent autrement sembler répondre à la même question alors qu’ils portent sur des ensembles différents.
Une liste de contrôle pour interpréter la capacité
- Identifier l’objet. Le nombre concerne-t-il une transaction, son reçu ou un bloc ?
- Identifier son rôle. S’agit-il d’un maximum, d’une consommation effective, d’une cible ou d’un prix unitaire ?
- Conserver le contexte du bloc. La capacité est un paramètre susceptible d’évoluer dans le temps.
- Limiter les déductions. Une consommation inférieure au plafond établit cette comparaison, sans démontrer l’admissibilité d’une transaction ni garantir son inclusion.
- Repérer les hypothèses fictives. Un exemple doit préciser sa capacité, les transactions qu’il contient et leur consommation.
Les définitions et la distinction entre cible et plafond proviennent de la documentation Ethereum sur le gas et les frais. Avec les descriptions des champs de l’API, elles permettent de lire séparément ces quantités ; elles ne transforment pas un exemple simplifié en modèle complet d’inclusion.
Article pédagogique préparé avec l’aide de l’IA. L’exemple fictif illustre des définitions techniques ; il ne constitue ni un conseil financier ni une recommandation d’effectuer une transaction.