La Fondation Ethereum a confirmé que le prochain hard fork de Fusaka introduira un plafond au niveau du protocole sur la quantité de gaz qu’une seule transaction peut consommer, officiellement codifié sous le nom d’EIP-7825. Le plafond est fixé à 2²⁴ de gaz, soit 16 777 216 unités, ce qui marque la première fois qu’Ethereum applique une limite par transaction distincte de la limite de gaz de bloc. Le changement est déjà actif sur Holesky et Sepolia et sera mis en ligne sur le réseau principal lorsque Fusaka sera activé.
Dans un article publié le 21 octobre, Toni Wahrstätter a formulé le raisonnement en termes directs : « En commençant par le prochain hard fork de Fusaka, l’EIP-7825 introduit un plafond limite de gaz par transaction de 2²⁴ (≈ 16,78 millions de gaz). » La note de la Fondation souligne que si le plafond limite les transactions individuelles, il ne modifie pas la limite du bloc de gaz ; au lieu de cela, il est conçu pour atténuer les vecteurs de déni de service où un seul appel surdimensionné monopolise un bloc entier et pour améliorer la prévisibilité du regroupement des blocs à mesure que le réseau se prépare à une exécution parallèle.
EIP-7825 trace une ligne claire entre la complexité au niveau des transactions et le débit au niveau du système. Auparavant, des appels exceptionnellement importants pouvaient approcher l’objectif du bloc complet de gaz (environ 45 millions parfois), créant des pathologies de timing et de planification pour les constructeurs et les validateurs.
Le nouveau plafond oblige à diviser les charges de travail qui dépasseraient 16,78 millions de gaz en appels séquencés plus petits. Les orientations de la Fondation prennent soin de noter que « pour la plupart des utilisateurs, rien ne change », puisque la répartition statistique des transactions réelles se situe déjà bien en dessous du seuil ; la surface de risque concerne principalement les contrats lourds, les scripts de déploiement et les routeurs spécialisés.
Ce que cela signifie pour Ethereum et les utilisateurs
Du point de vue de la feuille de route, le plafond est explicitement positionné comme base pour une exécution parallèle. Le billet de blog relie ce changement aux efforts anticipés tels que l’EIP-7928 à l’ère du « Glamsterdam », où des transactions prévisibles et limitées sont une condition préalable à une concurrence significative dans la couche d’exécution. En garantissant qu’au moins plusieurs transactions indépendantes peuvent être compressées par bloc, même dans des conditions pathologiques de pool de mémoire, le plafond réduit les conflits dans le pire des cas et simplifie la conception du planificateur pour les constructeurs expérimentant des chemins d’exécution parallélisables.
La spécification elle-même est de rechange et mécanique. Le résumé de l’EIP-7825 indique l’intention de « atteindre 16 777 216 (2 ^ 24) gaz » par transaction, améliorant ainsi la résilience contre certains vecteurs DoS et rendant le traitement des transactions plus prévisible à mesure que les limites de bloc augmentent. Cette simplicité fait partie de son attrait dans les canaux de développement principaux : une petite contrainte bien étendue qui préserve la compatibilité ascendante avec un travail de mise à l’échelle plus ambitieux.
Le débat sur la façon de coder et de communiquer le plafond est actif depuis des mois, y compris des discussions sur la dénomination et le paramétrage sur Ethereum Magicians et lors des appels AllCoreDevs. Un fil de discussion a résumé la garantie principale ciblée par plusieurs contributeurs : aligner les cibles de bloc sur des multiples de 2²⁴ afin que les constructeurs puissent toujours inclure au moins n transactions si le pool de mémoire en a n éligibles – un argument en faveur de la prévisibilité plutôt que du débit brut.
Sur le plan opérationnel, la Fondation affirme que tous les principaux clients – Geth, Erigon, Reth, Nethermind et Besu – ont mis en œuvre le changement dans les versions prêtes pour Fusaka, réduisant ainsi le risque de divergence entre clients lors de l’activation. Le message souligne également que la sémantique eth_call n’est pas affectée et que les transactions pré-signées dont les limites de gaz dépassent 2²⁴ devront être re-signées en dessous du plafond. Le chemin de mise à niveau pour les développeurs est simple : tester avec Holesky ou Sepolia, réorganiser les opérations par lots qui flirtent avec la limite et ajuster la logique d’estimation des gaz et les alertes afin qu’elles échouent rapidement lorsque les constructions dépassent le nouveau plafond.
Le contexte politique mérite d’être analysé. L’histoire d’Ethereum a favorisé des contraintes minimales et générales, reportant la complexité aux couches supérieures. EIP-7825 correspond à ce modèle : il ne se prononce pas sur ce que les contrats devraient faire, mais seulement sur le fait qu’ils respectent une limite supérieure qui protège la vivacité et prépare la couche d’exécution à un avenir multithread.
Il évite également les modifications du marché des frais et laisse l’économie de l’espace blob et les cibles de blocage à d’autres EIP et forks. Comme le dit la Fondation, le plafond « établit une base plus sûre et plus prévisible pour un débit plus élevé dans les futures forks », une ligne qui résume succinctement le compromis.
Au moment de mettre sous presse, l’ETH s’échangeait à 3 835 $.
Image en vedette créée avec DALL.E, graphique de TradingView.com
