• Le 6 novembre, la Fondation Ethereum a demandé aux développeurs et aux auditeurs de vérifier les effets des changements de spécification de Glamsterdam.

• L’EIP-8037 introduit un compteur de gaz distinct pour la création d’état ; l’EIP-8038 revoit le prix de l’accès aux états existants.

• L’analyse de ChainSecurity du 13 octobre a recensé plusieurs projets vulnérables aux spécifications modifiées.

EIP-8037, EIP-8038 et la séparation du gaz

Le 6 novembre, les développeurs et auditeurs de contrats intelligents à l’origine de déploiements sur Ethereum ont reçu une demande directe de la Fondation Ethereum : vérifier comment les modifications prévues de la spécification pour la prochaine mise à niveau majeure du réseau, Glamsterdam, affecteraient leurs projets. Pour faciliter cette vérification, la Fondation a publié des documents de référence recensant huit invariants — des conditions que le code en cours d’exécution peut supposer implicitement — que les modifications proposées invalideraient. Chaque entrée nomme la condition, explique pourquoi elle ne tient plus et montre où cette hypothèse se manifeste en pratique. La demande porte sur deux propositions d’amélioration d’Ethereum : l’EIP-8037 modifie le coût en gaz de la création de nouveaux états sur la chaîne, et l’EIP-8038 revoit le coût d’accès aux états déjà existants. L’état comprend les informations des comptes ainsi que les données contenues dans un contrat enregistré. Sur Ethereum, les frais de gaz mesurent les ressources de calcul consommées par une transaction ou l’exécution d’un contrat. Toute opération sur le réseau, d’un simple transfert à un appel de contrat imbriqué, puise dans cette réserve. L’EIP-8037 va au-delà d’une révision tarifaire : elle introduit un compteur de gaz distinct pour le gaz dépensé à créer de l’état, séparé du gaz consacré au traitement ordinaire, qui puise aujourd’hui dans une réserve commune. En pratique, la mise à niveau établirait un prix distinct pour deux ressources actuellement couvertes par une seule valeur. Les modifications peuvent donc changer à la fois la quantité de gaz nécessaire à une opération et celle qui reste disponible après l’échec d’une opération en cours d’exécution. C’est ce deuxième effet qui expose le code en cours d’exécution à un risque. Les documents concernent les contrats déjà déployés, pour lesquels une règle modifiée s’applique à du code actif plutôt qu’à un brouillon. Les développeurs et auditeurs qui découvrent une dépendance à l’une des huit conditions sont invités à contacter directement la Fondation. La demande a été formulée alors que le cours de l’Ethereum (ETH) reculait de 5,1 % au cours des dernières 24 heures, même si la démarche était motivée par le calendrier de la mise à niveau, et non par l’évolution du marché.

La société de sécurité ChainSecurity avait déjà repéré le danger. Une analyse technique publiée le 13 octobre recensait plusieurs projets susceptibles d’être vulnérables avec les spécifications modifiées, car ils partent du principe que certains invariants restent toujours valables : des conditions qu’un contrat doit respecter pour fonctionner comme prévu. Le mode de défaillance concret concerne les appels externes, le mécanisme sur lequel les systèmes composables s’appuient pour interagir. Aujourd’hui, lorsqu’un appel à un contrat externe échoue faute de gaz, l’opération suivante ne peut pas aboutir et la transaction dans son ensemble est annulée. Avec les spécifications proposées, l’opération suivante pourrait aboutir alors que celle qui a échoué ne peut pas être retentée, laissant le contrat dans un état que son auteur n’avait jamais prévu. Le nouveau dépôt de la Fondation répertorie les huit invariants que Glamsterdam romprait, avec pour chacun une explication, un exemple détaillé et des questions que les développeurs peuvent se poser en passant en revue leurs propres projets. Le report de Glamsterdam sur le testnet Hoodi n’est pas une nouveauté : le 22 octobre, la Fondation a repoussé une activation initialement prévue le 26 octobre, invoquant la nécessité d’étudier plus avant les interactions entre EIP-8037 et les contrats du réseau principal. Aucune nouvelle date n’a été fixée, et la mise à niveau reste en suspens jusqu’à ce que les questions en suspens soient éclaircies. L’examen des répercussions est mené avec le soutien de ChainSecurity et de la société d’audit Dedaub, qui étudient toutes deux la manière dont les règles modifiées s’appliquent aux déploiements existants, en parallèle de l’audit interne de la Fondation. Celle-ci reconnaît toutefois qu’elle ne peut pas examiner tous les projets, et encore moins le code hors chaîne associé aux contrats sur chaîne. La décision revient à l’appel des développeurs AllCoreDevs, qui doit d’abord disposer d’un inventaire de ce qui cesserait de fonctionner après l’activation et des options de spécification susceptibles de l’éviter. Tant que cet appel n’aura pas rendu son verdict, a souligné la Fondation, rien n’est décidé concernant la spécification. Les travaux sur Hegota, la mise à niveau qui succédera à Glamsterdam, se poursuivent en parallèle et ne sont pas affectés.

Le point d’étape d’AllCoreDevs

La séparation des coûts de gaz au cœur d’EIP-8037 constitue un changement comptable qui touche la machine virtuelle elle-même. Voilà pourquoi la Fondation y voit un risque au niveau du protocole plutôt qu’un simple ajustement de paramètre. Pour les équipes chargées des déploiements, le dépôt consacré aux huit invariants transforme un débat abstrait en liste de contrôle : elles peuvent vérifier leurs hypothèses à l’aune de huit conditions clairement définies au lieu d’attendre une décision. Le facteur limitant est la couverture, et la Fondation le reconnaît elle-même, puisqu’un examen exhaustif du code sur chaîne et hors chaîne est impossible. La prochaine échéance est la réunion d’AllCoreDevs, où la décision devra s’appuyer à la fois sur l’inventaire des problèmes et sur les différentes options de spécification.