Le cluster Protocol de la Fondation Ethereum a publié un classement unique et noté des 62 propositions d'amélioration d'Ethereum (EIP) soumises pour Hegotá, la mise à niveau du réseau prévue après Glamsterdam. C'est la première fois que le groupe s'exprime d'une seule voix sur un fork, au lieu de laisser chaque équipe publier ses propres opinions. Cette liste sert désormais de référence pour déterminer quelles fonctionnalités sont verrouillées et lesquelles risquent d'être écartées. Pour les observateurs extérieurs — équipes clientes, développeurs d'applications et opérateurs d'infrastructure qui planifient les mises à niveau des mois à l'avance — un signal consolidé unique marque un changement dans la manière dont le processus de développement décentralisé d'Ethereum communique sa feuille de route.

S signifie obligation de livrer, DFI signifie refus

La liste des niveaux, publiée le lundi 7 septembre en parallèle d'un article compagnon sur les priorités du cluster (blog.ethereum.org/2026/09/07/protocol-hegota-eips), classe chaque proposition dans des bandes assorties d'engagements de livraison fermes.

Une note S signifie qu'une fonctionnalité définit le fork et que le calendrier cède avant son périmètre. Une note A signifie que la fonctionnalité est censée être livrée et ne peut être retirée qu'après que chaque élément S est sécurisé. Les propositions de niveau B sont admises une par une, et la plupart comportent trois exigences : un prototype, une validation et une spécification finalisée. Les propositions de niveau C passent sous la ligne sans être disqualifiées, suivies du DFI, qui signifie « declined for inclusion » (refusée pour inclusion). Un DFI peut être attribué pour des raisons telles qu'un risque de sécurité ou une menace pour un jalon ultérieur. Une bande TBD distincte met les propositions en attente jusqu'à ce que les données du mainnet puissent répondre aux questions auxquelles le cluster ne peut pas répondre aujourd'hui.

Seule FOCIL, déposée sous le nom d'EIP-7805, a obtenu un S net. FOCIL — fork-choice enforced inclusion lists (listes d'inclusion appliquées par le choix de fork) — est discutée depuis des années dans les cercles de recherche d'Ethereum comme moyen de contrer l'influence d'un petit ensemble de constructeurs de blocs dominants. La proposition permet à tout utilisateur de faire inclure une transaction éligible sans dépendre de constructeurs de blocs centralisés. Elle a également obtenu à l'unanimité la note maximale avec une participation complète et est décrite comme la fonctionnalité phare verrouillée de la couche consensus.

Comment 60 chercheurs d'Ethereum ont-ils produit 397 notes ?

Environ 60 chercheurs et ingénieurs ont participé au processus de notation qui a déterminé les priorités. Ils ont été organisés en neuf équipes en plus d'experts individuels par domaine, et ont ensemble rempli 16 modèles de contribution. Douze d'entre eux ont fourni des notes de niveau effectives, et plusieurs n'ont été utilisés que sur les EIP où les contributeurs avaient une expertise approfondie.

Les équipes composant le cluster Protocol ont produit 397 notes sur les 62 propositions, soit une moyenne de 6,4 par EIP. Les éléments les plus contestés ont reçu jusqu'à neuf notes chacun. Les contributeurs ont effectué la notation de manière indépendante. Dans son article de blog, le cluster Protocol a indiqué que Geth, en tant que client de couche d'exécution, publiera toujours sa propre liste distincte. Cette exception reflète la manière dont les mises à niveau d'Ethereum sont réellement livrées : plusieurs équipes clientes indépendantes doivent chacune implémenter et s'accorder sur le contenu final avant qu'un fork ne soit déployé sur le mainnet.

L'ensemble vise la résistance quantique

Les notes s'inscrivent dans un objectif à plus long terme détaillé dans l'article sur les priorités du cluster (blog.ethereum.org/2026/09/07/protocol-priorities). Celui-ci inclut le rendement de la couche de base d'Ethereum résistante au quantique à travers l'exécution, le consensus et les données d'ici décembre 2029. Cette date correspond aux objectifs de migration fixés indépendamment par Google, Cloudflare et Microsoft. La préoccupation est précise : un ordinateur quantique suffisamment puissant pourrait casser la cryptographie à courbes elliptiques qui sécurise aujourd'hui les adresses et les signatures Ethereum, raison pour laquelle la conversation sur la migration à l'échelle de l'industrie importe autant aux blockchains qu'aux infrastructures web.

La Fondation Ethereum qualifie l'hypothèse d'un « Q-day » en 2030 de supposition délibérément agressive. Elle a indiqué que les estimations les plus crédibles situent l'arrivée d'ordinateurs quantiques capables de casser la cryptographie plus tard que cela, si de telles machines arrivent un jour. La Fondation a également déclaré qu'elle traitera l'échéance auto-imposée comme non négociable au moins jusqu'à une réévaluation en janvier 2027 avec des experts externes.

Pour atteindre cet objectif après le lancement de Glamsterdam en décembre 2026, la Fondation devrait avancer à un rythme moyen de 7,2 mois par fork à travers une cinquième mise à niveau appelée L*.

Le travail du cluster s'articule désormais autour de cinq axes de recherche imbriqués : finalité rapide, post-quantique, confidentialité, état et zkEVM.

Quand les travaux sur la confidentialité commenceront-ils ?

La confidentialité a été un axe majeur de la Fondation, et le cofondateur Vitalik Buterin a été l'une des voix les plus en pointe dans le plaidoyer pour la confidentialité sur Ethereum. Dans leur article, le cluster Protocol a déclaré : « Nous pensons que ce travail devrait commencer dans Hegota afin d'offrir des transactions privées natives, sans confiance et résistantes à la censure sur Ethereum L1. »

Le cluster a ajouté que la confidentialité post-quantique pourra ensuite arriver à grande échelle. Il a également précisé que Hegotá n'est pas le fork post-quantique ; c'est plutôt celui qui déterminera la rapidité de ce fork post-quantique. Le cluster Protocol indique que le travail d'implémentation par les équipes clientes peut réaliste débuter à la fin du T4 2026.