Ethereum met en garde contre les abus de builders sur le testnet Glamsterdam

Le compte rendu de la réunion des développeurs du noyau Ethereum du 17 septembre montre que les participants ont accepté la date du 6 octobre après avoir examiné les résultats récents du devnet Glamsterdam, tout en exprimant des inquiétudes sur le comportement de la séparation proposant-constructeur inscrite (ePBS) sur un réseau public où l'ETH de test n'a pas de coût économique significatif.

Au cœur de l'avertissement se trouve l'EIP-7732, la conception ePBS de Glamsterdam. Ethereum.org décrit l'ePBS comme un changement de protocole qui sépare l'assemblage des charges utiles de transaction des tâches de consensus du validateur, intégrant ainsi une relation qui repose actuellement fortement sur une infrastructure externe dans les règles de consensus d'Ethereum.

Selon cette conception, les builders peuvent soumettre des offres pour le droit de fournir une charge utile d'exécution. Une fois qu'un proposeur s'engage sur l'offre gagnante, le builder est censé publier les transactions correspondantes. La spécification de consensus d'Ethereum définit les builders comme des acteurs jalonnés distincts qui soumettent des offres signées de charge utile d'exécution avant de diffuser l'enveloppe de charge utile correspondante.

Lors de l'appel des développeurs de jeudi, le développeur consensus Potuz a averti que l'économie change sur un testnet car les attaquants peuvent obtenir de l'ETH de test sans payer sa valeur de marché sur le réseau principal. Un opérateur malveillant pourrait créer de nombreuses identités de builders, soumettre des offres bien supérieures à celles des concurrents légitimes, puis refuser de fournir la charge utile promise après avoir gagné.

« Je peux simplement lancer un millier de builders », a déclaré Potuz, expliquant que l'attaquant pourrait les faire tourner, enchérir de manière agressive et retenir les charges utiles. Il a ajouté plus tard : « N'importe quel adolescent peut faire cela. »

Le développeur a présenté cette préoccupation comme un problème de disponibilité du testnet public, et non comme une nouvelle voie pour voler de l'ETH sur le réseau principal. Sur le réseau principal, un participant peut déjà payer pour produire un bloc vide, mais le coût économique d'obtention de l'espace de bloc limite ce comportement. L'ETH de test rend la perturbation persistante beaucoup moins chère.

Les clients pourraient avoir besoin de disjoncteurs au niveau des builders

Les protections existantes pourraient ne pas être suffisantes pour l'environnement Sepolia. Potuz a indiqué aux développeurs que certains disjoncteurs de clients ne basculent vers des blocs construits localement qu'après plusieurs charges utiles manquées, et qu'il n'avait pas connaissance de protections universelles capables de rejeter individuellement les builders abusifs.

Son inquiétude portait sur les attaquants revenant sous de nouvelles identités. Même si un client réagit aux charges utiles manquantes, des builders jetables pourraient continuer à enchérir à moins que la logique défensive n'identifie et ne limite le comportement assez rapidement.

Les développeurs n'ont pas présenté l'attaque des builders comme un exploit confirmé contre Sepolia. La discussion portait sur un scénario qu'ils s'attendent à voir exposé par les tests publics une fois que des participants externes pourront participer dans les conditions ePBS. Potuz a soutenu que les testnets d'Ethereum ont besoin de protections plus solides car les équipes d'applications et d'infrastructure comptent sur eux pour tester les logiciels avec des blocs fonctionnels.

Ethereum.org note que Sepolia utilise un ensemble de validateurs permissionné contrôlé par les équipes de clients et de tests, tandis que Hoodi dispose d'un ensemble de validateurs ouvert destiné au staking et aux tests de protocole. La structure de Sepolia donne aux développeurs d'Ethereum un contrôle opérationnel accru si le premier déploiement public de longue durée de Glamsterdam rencontre des problèmes.

Comme l'a précédemment rapporté crypto.news, les développeurs avaient provisoirement retenu le 6 octobre avant le dernier appel, la date dépendant encore d'une autre transition stable de devnet privé. L'appel de consensus du 17 septembre a avancé ce calendrier après que Devnet-11 a terminé sa répétition de fork prévue.

Devnet-11 a testé 200 millions de gaz avant Sepolia

Glamsterdam Devnet-11 a été créé comme une répétition contrôlée de type « chemin heureux » plutôt que comme un réseau d'attaque contradictoire. Sa spécification officielle prévoyait la genèse pour le 14 septembre, la transition Gloas pour le 16 septembre et une augmentation de la limite de gaz de bloc de 60 millions à 200 millions peu après.

Le réseau de test utilisait 84 000 validateurs dans une configuration multi-clients et portait le même ensemble d'EIP de base prévu pour les tests Glamsterdam. Ses organisateurs ont explicitement exclu les attaques délibérées du périmètre de Devnet-11, gardant les expériences contradictoires sur l'environnement Platåberget de plus longue durée.

CoinDesk a rapporté que Devnet-11 a terminé la transition et a porté la limite de gaz vers 200 millions sans perdre la finalité. Le paramètre de 200 millions est un paramètre de test, pas un engagement confirmé de limite de gaz sur le réseau principal.

La feuille de route Glamsterdam d'Ethereum indique que la mise à niveau est conçue pour augmenter la capacité de la couche 1 tout en modifiant la façon dont les blocs sont construits et vérifiés. L'EIP-7732 étend la fenêtre de propagation de la charge utile d'exécution d'environ deux secondes à environ neuf secondes, donnant aux nœuds plus de temps pour distribuer et valider des charges utiles plus volumineuses.

La mise à niveau comprend également des listes d'accès au niveau des blocs et une série de changements de tarification du gaz. Une couverture antérieure de compatibilité Glamsterdam a rapporté que les portefeuilles, les indexeurs et les estimateurs de gaz utilisant des hypothèses fixes peuvent nécessiter des modifications car la création de nouveaux comptes et certaines opérations à forte intensité d'état reçoivent un traitement de gaz différent dans le cadre du fork prévu.

Un examen distinct des risques des contrats intelligents a révélé que les contrats utilisant des allocations de gaz fixes ou des modèles d'exécution sensibles au gaz peuvent nécessiter des tests avant que la mise à niveau n'atteigne le réseau principal.

La fenêtre d'examen des clients Sepolia tombe à sept jours

Le calendrier du 6 octobre laisse aux équipes de clients moins de temps d'examen que ce que recommande le processus de mise à niveau normal d'Ethereum.

Lors de l'appel du 17 septembre, le développeur Fredrik Svantes a indiqué aux participants que le processus standard exige au moins 14 jours entre la disponibilité du logiciel client prêt pour la publication et la première activation sur le testnet public. Il a précisé que ces deux semaines sont normalement utilisées pour les examens de sécurité internes, l'exposition aux primes de bugs et d'éventuels travaux de sécurité externes.

Avec l'approche de Sepolia, les développeurs ont discuté d'une date limite au 29 septembre pour les versions des clients. Sept jours entre le 29 septembre et le 6 octobre ne représenteraient que la moitié de la période d'examen normale. Les participants ont accepté ce risque pour Sepolia en partie parce que son ensemble de validateurs est relativement centralisé et que le réseau peut être récupéré plus facilement en cas de panne logicielle.

Le développeur principal Alex Stokes a exhorté les équipes à publier les logiciels plus tôt lorsque cela est possible afin que davantage d'examinateurs puissent les examiner. Une fois que les clients prêts pour la publication sont disponibles, ils peuvent entrer immédiatement dans le processus de prime aux bugs d'Ethereum.

Ce calendrier compressé fait suite à plusieurs problèmes de test antérieurs. Un ordre du jour des développeurs du 3 septembre a enregistré une non-finalité lors de l'activation de Gloas sur Devnet-8 affectant plusieurs clients de consensus, tandis que les tests ultérieurs de Devnet ont examiné des correctifs et des cas limites supplémentaires.

Un autre appel de test a enregistré des problèmes lors desquels un scénario Platåberget a mis hors ligne 12 des 13 nœuds Besu et ralenti les nœuds Erigon et Ethrex. Devnet-9 a connu une non-finalité imprévue, poussant les équipes à d'autres itérations avant Devnet-11.

L'activation sur le réseau principal n'a toujours pas de date confirmée

La feuille de route publique d'Ethereum continue de prévoir Glamsterdam pour le quatrième trimestre 2026, mais indique que la date du réseau principal n'a pas été confirmée. La prochaine étape publiée est le fork Sepolia du 6 octobre.

Hoodi devrait suivre Sepolia car il fournit un environnement de validateurs ouvert pour le staking et les tests de mise à niveau. Les développeurs ont discuté de l'étape Hoodi lors de l'appel du 17 septembre, mais ont lié son calendrier aux progrès de Sepolia, ce qui signifie que des problèmes sur le premier testnet public pourraient décaler les dates suivantes.

Le projet de plan de réponse aux incidents du réseau principal d'Ethereum ne contient toujours pas d'époque ou d'horodatage d'activation. Le document laisse plutôt les champs d'information de mise à niveau vides tout en listant les rôles de client et de coordination qui seront remplis avant le déploiement sur le réseau principal.

Comme l'a rapporté la couverture antérieure de Glamsterdam par crypto.news, la mise à niveau est centrée sur l'ePBS, les listes d'accès au niveau des blocs et la retarification du gaz conçue pour un débit plus élevé de la couche 1. Les développeurs ont continué à considérer le succès des tests multi-clients comme un prérequis avant de fixer le fork du réseau principal.

Pour l'instant, les équipes de clients font face à l'échéance logicielle du 29 septembre discutée lors de l'appel, suivie de l'activation de Sepolia le 6 octobre. Les développeurs d'Ethereum n'ont pas publié d'époque de réseau principal ni d'horodatage d'activation final.