Les développeurs d’Ethereum sollicitent les équipes d’applications pour évaluer les changements proposés aux frais de gaz de Glamsterdam

Les développeurs principaux d’Ethereum sollicitent les équipes d’applications afin de déterminer si les règles de gaz proposées pour Glamsterdam doivent être modifiées. Les audits internes des développeurs ne peuvent pas examiner les contrats et services hors chaîne de chaque projet. Dans un billet publié le 6 novembre sur le blog de la Fondation Ethereum, Marius van der Wijden a demandé de vérifier huit hypothèses relatives au gaz. ChainSecurity et Dedaub mènent des investigations en parallèle des audits internes, tandis que les projets sont invités à décrire les corrections possibles.

L’activation prévue de Hoodi le 26 octobre, ainsi que la hausse associée de la limite de gaz à 200 millions, a été reportée le 22 octobre. L’appel du 6 novembre maintient le report dans l’attente d’une résolution, et les avis ne fixent aucune date d’activation du mainnet. L’EIP-8037 augmenterait les frais de création de données persistantes sur la blockchain et comptabiliserait séparément la croissance de l’état et l’exécution. L’EIP-8038 modifierait les frais d’accès à l’état existant et d’écriture de celui-ci. Ces propositions visent à accroître le débit tout en limitant la quantité de données que les nœuds Ethereum doivent conserver. Le cadre d’évaluation porte sur trois hypothèses de tarification concernant les budgets fixes et les réserves, ainsi que sur cinq hypothèses comptables concernant le gaz restitué, les échecs, la facturation et la délégation.

L’entrée INV-5 du cadre examine les calculs de remboursement utilisés par les relayeurs, qui paient les coûts des transactions pour d’autres utilisateurs. L’EIP-8037 affecterait initialement du gaz à un réservoir distinct de gaz d’état pour les transactions dont la limite de gaz dépasse 16 777 216. La création d’état consommerait ce réservoir avant de puiser dans le gaz d’exécution. La fonction gasleft() de Solidity exclut le réservoir : comparer ses valeurs peut donc omettre des dépenses payées par les relayeurs. Si une valeur relevée ultérieurement était supérieure à la valeur initiale, une soustraction vérifiée provoquerait une révocation et empêcherait l’opération. Une soustraction non vérifiée pourrait au contraire déborder et produire une valeur élevée, ce qui pourrait entraîner un remboursement excessif selon les autres calculs et les protections de paiement. Les dépenses du réservoir non mesurées pourraient aussi conduire à facturer trop peu aux utilisateurs et laisser les opérateurs payer la différence.

Les recommandations de facturation préconisent d’estimer les coûts selon les règles proposées et d’obtenir un accord sur les frais signé par l’utilisateur. Pour les systèmes qui conservent la mesure des coûts, elles suggèrent de plafonner la soustraction et d’imposer un plafond de paiement signé, même si les dépenses financées par le réservoir resteraient non mesurées. La proposition de spécification PR #12581, encore ouverte, empêcherait les valeurs de gaz mesurées d’augmenter et réglerait le problème de soustraction sans éliminer les coûts non mesurés du réservoir.

L’entrée INV-8 examine l’EIP-7702, qui permet aux comptes d’autoriser du code de contrat délégué. Selon les règles proposées, un manque de gaz avant l’exécution pourrait laisser une transaction inscrite dans un bloc tout en annulant la délégation et la mise à jour du nonce liée à l’autorisation. Une autorisation exposée pourrait alors être réutilisée si elle satisfait toujours aux contrôles de validité, notamment à la vérification du nonce du compte qui l’a autorisée. Un attaquant pourrait appliquer cette autorisation et revendiquer la propriété en une seule transaction si la fonction d’initialisation du contrat délégué permet au premier appelant de choisir le propriétaire. La prise de contrôle anticipée d’autorisations se produit déjà dans les mempools publics, mais cet échec pourrait exposer une autorisation réutilisable après l’inscription d’une transaction dans un bloc, même après une soumission privée. Les délégations appliquées avant le cadre d’exécution de premier niveau survivraient à un échec dans ce cadre ultérieur ; les reçus d’échec nécessitent donc de vérifier le code et les nonces des comptes qui en résultent. Parmi les protections suggérées pour les portefeuilles figurent l’obligation d’une signature du compte ou d’un appel à soi-même pour l’initialisation, ainsi que l’invalidation des autorisations exposées. Une modification du protocole suggérée consisterait à facturer d’avance le coût maximal de l’autorisation, mais elle n’a pas été adoptée.

La création d’un emplacement de stockage à froid coûterait au total 110 020 unités de gaz selon la proposition, contre 22 100 avec Osaka. Le total proposé comprend 12 100 unités de gaz d’exécution et 97 920 unités de gaz d’état ; le réservoir détermine quel solde paie la composante de gaz d’état. Les recherches de ChainSecurity publiées le 13 octobre montrent que les changements de frais et le gaz restitué peuvent permettre à un contrat d’enregistrer définitivement comme échouée une opération sous-financée. Une opération valide pourrait devenir impossible à répéter si cet enregistrement empêche les nouvelles tentatives. La vérification des budgets, la propagation des échecs et le maintien de la possibilité de réessayer répondent à des aspects distincts du risque.

Le dépôt demande aux projets concernés si des changements de configuration, des mises à niveau ou des migrations pourraient résoudre les problèmes, et à quelle échéance environ les corrections pourraient être achevées. Les réponses des projets aideront les développeurs à évaluer l’ampleur des travaux de compatibilité que les applications peuvent absorber et à déterminer où des modifications de la spécification pourraient éviter des préjudices. Des descriptions précises des échecs et des corrections disponibles guideront les prochaines discussions sur la spécification.