Les développeurs Ethereum sollicitent l'avis des dApps sur les changements de comptabilisation du gas dans la mise à jour Glamsterdam
Les développeurs principaux demandent aux équipes dApps de revoir huit hypothèses de gas après que l'EIP‑8037 menace la logique de facturation et d'autorisation, retardant le déploiement de Glamsterdam.
Traduit de l'anglais. Lire l'original
À retenir
- La mise à jour Glamsterdam d’Ethereum introduit une nouvelle comptabilisation du state‑gas qui pourrait rompre les remboursements des relais et les autorisations de portefeuille.
- Les développeurs ont demandé aux équipes dApps de confirmer que huit invariants liés au gas peuvent être respectés avant de poursuivre la mise à jour.
- Ce retard repousse l’activation du testnet Hoodi et laisse la date de déploiement sur le mainnet indéterminée jusqu’à réception des retours du projet.
Le 6 novembre, la Fondation Ethereum a publié une demande aux développeurs d’applications et aux auditeurs pour qu’ils évaluent huit hypothèses liées au gas associées à la prochaine mise à jour Glamsterdam. Cette requête fait suite à un report de l’activation prévue du testnet Hoodi le 26 octobre et à une augmentation de 200 millions du plafond de gas, reportée le 22 octobre en attendant la résolution des problèmes identifiés. Les développeurs principaux expliquent qu’ils ne peuvent pas auditer chaque contrat et service hors‑chaîne eux‑mêmes, d’où la nécessité d’obtenir des retours de l’ensemble de l’écosystème pour décider si les changements proposés par les EIP‑8037 et EIP‑8038 nécessitent d’autres révisions.
ETH / USD
Nouveau modèle de state‑gas et ses risques
L’EIP‑8037 séparerait le coût de création de données persistantes de la blockchain du gas d’exécution, en introduisant un « réservoir de state‑gas » qui finance les écritures d’état lorsqu’une transaction dépasse une limite de gas de 16 777 216. Selon la sémantique actuelle de Solidity gasleft(), ce réservoir est invisible aux contrats, ce qui signifie qu’un relais mesurant le gas avant et après l’exécution pourrait mal calculer les remboursements. Si la lecture ultérieure du gas est supérieure, une soustraction contrôlée provoquerait un revert, bloquant potentiellement la transaction ; une soustraction non contrôlée pourrait s’enrouler et entraîner un sur‑remboursement. La proposition modifie également la gestion des délégations échouées (EIP‑7702), permettant à une transaction qui manque de gas pendant la pré‑exécution de laisser une autorisation exposée et réutilisable, ouvrant ainsi une voie d’attaque de front‑running.
Atténuations proposées et recommandations aux développeurs
L’équipe Ethereum suggère plusieurs garde‑fous : signer une estimation des frais conforme aux nouvelles règles de comptabilisation, contraindre les résultats de soustraction et plafonner les paiements à un maximum signé par l’utilisateur. Une pull request de spécification ouverte (PR #12581) vise à empêcher les lectures de gas d’augmenter, ce qui résoudrait le problème de soustraction mais pas le point aveugle créé par le réservoir. Pour les risques de délégation, les portefeuilles pourraient lier l’initialisation à la signature du compte ou invalider les autorisations exposées, tandis que facturer les coûts au pire‑cas à l’avance reste une modification de protocole non adoptée.
À suivre
Le dépôt créé par la Fondation recueille désormais les réponses des projets concernés concernant les réglages, mises à jour ou migrations nécessaires, ainsi que leurs calendriers. Ces contributions orienteront la prochaine série de discussions de spécification et détermineront si la mise à jour Glamsterdam se déroulera comme prévu ou nécessitera d’autres ajustements. La date d’activation sur le mainnet reste à définir, et le résultat dépendra du nombre de dApps capables d’intégrer le nouveau modèle de gas sans compromettre la sécurité ou l’utilisabilité.

Discussion 0