Ethereum Imposera une Limite de Gas dans la Mise à niveau Fusaka

La Fondation Ethereum a confirmé que le prochain Hard Fork Fusaka introduira un plafond au niveau du protocole sur la quantité de gaz qu'une seule transaction peut consommer, formellement codifié comme EIP-7825. Le plafond est fixé à 2²⁴ gaz—16 777 216 unités—marquant la première fois qu'Ethereum impose une limite par transaction distincte de la limite de gaz par bloc. Le changement est déjà actif sur Holesky et Sepolia et sera déployé sur le mainnet lorsque Fusaka sera activé.

Dans un post publié le 21 octobre, Toni Wahrstätter a exposé la logique en termes directs : "À partir du prochain Hard Fork Fusaka, EIP-7825 introduit un plafond de 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 de gaz par bloc ; il est plutôt 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 remplissage des blocs alors que le réseau se prépare à l'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 volumineux pouvaient approcher la cible complète de gaz du bloc (environ 45 millions parfois), créant des pathologies de timing et de planification pour les constructeurs et les validateurs.

Le nouveau plafond oblige les charges de travail qui dépasseraient 16,78 millions de gaz à être divisées en appels plus petits et séquencés. Les directives de la Fondation précisent que "pour la plupart des utilisateurs, rien ne change", puisque la distribution statistique des transactions réelles se situe déjà bien en dessous du seuil ; la surface de risque concerne principalement les contrats à forte charge par lots, les scripts de déploiement et les routeurs spécialisés.

Ce que cela signifie pour Ethereum et ses utilisateurs

Du point de vue de la feuille de route, le plafond est explicitement positionné comme une base pour l'exécution parallèle. Le billet de blog relie ce changement aux efforts anticipés tels que EIP-7928 dans l'ère "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 empaquetées par bloc—même dans des conditions pathologiques du mempool—le plafond réduit les contentions 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 sobre et mécanique. L'abstrait de EIP-7825 indique l'intention "à 16 777 216 (2^24) gaz" par transaction, améliorant la résilience contre certains vecteurs de DoS et rendant le traitement des transactions plus prévisible à mesure que les limites de bloc augmentent. Cette simplicité a fait partie de son attrait dans les canaux de développement principaux : une contrainte petite et bien définie qui préserve la compatibilité avec des travaux 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 fondamentale 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 mempool en contient n éligibles—un argument en faveur de la prévisibilité plutôt que du débit brut.

Sur le plan opérationnel, la Fondation indique que tous les principaux clients—Geth, Erigon, Reth, Nethermind et Besu—ont implémenté le changement dans des versions prêtes pour Fusaka, réduisant le risque de divergence entre clients lors de l'activation. Le post 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 sur Holesky ou Sepolia, retravailler les opérations par lots qui flirtent avec la limite, et ajuster la logique d'estimation du gaz et les alertes pour 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 polyvalentes, reportant la complexité vers les couches supérieures. EIP-7825 s'inscrit dans ce modèle : il ne donne pas d'avis sur ce que les contrats devraient faire, mais seulement qu'ils respectent une limite supérieure qui protège la vivacité et prépare la couche d'exécution à un avenir multi-thread.

Il évite également les modifications du marché des frais et laisse l'économie de l'espace blob et les cibles de bloc à d'autres EIP et forks. Comme l'a dit la Fondation, le plafond "établit une base plus sûre et plus prévisible pour un débit plus élevé dans les forks futurs", une ligne qui résume succinctement le compromis.

Au moment de la publication, ETH s'échangeait à 3 835 $.