Ethereum : Glamsterdam retardé par des failles, les développeurs appellent les agents IA en renfort

Ce qu’il faut retenir :

• Ethereum a reporté le test de Glamsterdam sur le testnet Hoodi après la découverte de failles par ChainSecurity.
• Selon ChainSecurity, les EIP-8037 et 8038 pourraient rendre vulnérables au moins 13 protocoles DeFi existants.
• Des chercheurs d’Ethlabs et de l’Ethereum Foundation utilisent des agents IA coordonnés pour recenser les contrats touchés.

Ethereum appuie sur pause. Les développeurs du réseau ont reporté la répétition générale de Glamsterdam, sa prochaine grande mise à jour, sur le testnet Hoodi. En cause : des failles de sécurité identifiées par la société d’audit ChainSecurity dans deux propositions centrales du hard fork, l’EIP-8037 et l’EIP-8038. Le cabinet affirme avoir déjà trouvé 13 exemples concrets de contrats concernés et a engagé une divulgation responsable auprès des projets visés.

Glamsterdam devait être lancé en décembre sur le mainnet. Lors de la réunion des développeurs principaux (All Core Devs, ou ACD) de la semaine dernière, les équipes ont tranché : la sécurité passe avant le calendrier. Aucune nouvelle date ne sera fixée avant une analyse complète des effets de ces failles.

Que prévoient les EIP-8037 et 8038 ?

Les deux propositions doivent rendre plus chère la création et l’accès aux données d’état sur Ethereum. L’état désigne l’ensemble des informations que chaque validateur doit conserver : soldes des comptes, données des contrats, emplacements de stockage. Chaque nouveau compte ou nouvel emplacement de stockage alourdit cette base.

Aujourd’hui, l’état d’Ethereum grossit d’environ 116 Go par an. Or Glamsterdam doit faire passer la limite de gaz par bloc de 60 à 200 millions. Sans garde-fou, la croissance de l’état atteindrait environ 387 Go par an, de quoi dégrader la décentralisation et les performances du réseau, explique Derek Chiang, d’Ethlabs, dans un long billet publié sur X. Les EIP-8037 et 8038 renchérissent donc la création d’état quand celle-ci s'emballe.

Pourquoi ces EIP créent-elles des failles dans des contrats existants ?

Le problème tient au comportement du gaz, l’unité qui mesure le coût de calcul d’une transaction. Aujourd’hui, quand un contrat A appelle un contrat B et que B épuise son gaz, il ne reste qu’une petite fraction, 1/64, pour terminer l’exécution de A. Beaucoup de contrats reposent implicitement sur cette règle.

L’EIP-8037 introduit un mécanisme qui rend du gaz quand un emplacement de stockage est libéré. L’appel interne vers B peut alors échouer faute de gaz, alors que A dispose encore d’une réserve confortable. Un gestionnaire d’erreur qui échouait jusqu’ici, faute de gaz, pourrait désormais aller au bout. Le comportement du contrat change, et un attaquant pourrait en profiter. Des contrats sûrs aujourd’hui deviendraient vulnérables le jour du fork.

Derek Chiang retient une leçon : le protocole est devenu si complexe que chaque modification entraîne des effets secondaires imprévus. La faille a surgi moins de deux mois avant le lancement prévu. Selon lui, les concepteurs de futures mises à jour devront analyser les risques de casse bien plus tôt.

Des agents IA pour passer Ethereum au crible

Pour recenser tous les contrats touchés, les chercheurs ont misé sur l’IA. Juste après la réunion ACD, Francesco D’Amato, chercheur chez Ethlabs, a lancé pendant la nuit des agents IA chargés de scanner les contrats. Il a découvert que Toni Wahrstätter, de l’Ethereum Foundation, faisait la même chose de son côté.

Pour éviter les doublons, Francesco D’Amato a créé un dépôt GitHub qui sert de tableau de coordination aux agents. Chacun y déclare ses ressources, réserve une tâche en commentant un ticket, met à jour l’avancement et consigne ses résultats pour qu’un autre agent puisse les vérifier. D’autres chercheurs d’Ethlabs et de l’Ethereum Foundation ont rejoint l’effort, simplement en pointant leur agent, Codex ou Claude, vers le dépôt.

Derek Chiang fait lui-même le parallèle avec le piratage de Hugging Face par des agents d’OpenAI, qui s’étaient coordonnés via un forum. « Le même schéma fonctionne aussi pour les bons agents », écrit-il. Les résultats restent confidentiels pour des raisons de sécurité. Ils seront présentés lors de la réunion des développeurs consacrée aux tests (ACDT) la semaine prochaine.

Ce qu’il faut surveiller

La nouvelle date de Glamsterdam dépendra des conclusions de l’ACDT. Les chercheurs ont déjà ouvert un second dépôt pour l’EIP-8198, dite « Quick Slots », défendue par Barnabé Monnot pour le hard fork suivant, Hegotá. Elle ramènerait la durée d’un slot de 12 à 10 secondes. Les agents cherchent les projets qui ont codé en dur la durée actuelle.

D’autres chantiers avancent. Plusieurs fournisseurs RPC s’apprêtent à intégrer la règle de confirmation rapide (Fast Confirmation Rule), qui ramènerait le délai de confirmation sur le réseau principal de 13 minutes à 24 secondes. L’écosystème se retrouve ensuite à Mumbai pour Devcon.