Le Protocol cluster de l’Ethereum Foundation a détaillé le 7 septembre ses priorités pour Hegotá, le prochain grand chantier après Glamsterdam. Environ 60 chercheurs et ingénieurs ont participé au processus, avec 16 contributions formelles et 397 évaluations réparties sur 62 EIP.

L’exercice n’est pas une simple liste de souhaits. L’équipe veut réduire la quantité de changements qui entrent simultanément dans un fork afin de ne pas répéter un problème connu dans Ethereum : chaque petite fonction supplémentaire multiplie les interactions à implémenter, tester et auditer.

Deux propositions ressortent nettement. EIP-7805, FOCIL, devient la pièce maîtresse de la couche consensus. EIP-8141, Frame Transactions, joue le même rôle côté exécution.

FOCIL essaie de retirer aux builders le pouvoir de simplement ignorer une transaction

FOCIL signifie Fork-choice enforced Inclusion Lists. Le système permet à plusieurs validateurs de publier des listes de transactions que le bloc suivant doit intégrer lorsqu’elles sont valides et qu’il existe suffisamment de place.

Les attesters doivent ensuite vérifier que ces contraintes ont été respectées avant de considérer le bloc comme valide dans le fork choice.

L’idée ne cherche pas à supprimer les builders ni à décider dans quel ordre toutes les transactions doivent apparaître. Elle vise une propriété plus précise : empêcher qu’un constructeur de bloc puisse librement exclure une transaction pourtant admissible.

L’Ethereum Foundation traite donc FOCIL comme un mécanisme de résistance à la censure et à la capture de la production de blocs.

Frame Transactions change la manière dont un compte prouve qu’il a le droit de dépenser

EIP-8141 touche une autre fondation d’Ethereum : le format des transactions.

Les Frame Transactions rendent programmables plusieurs étapes aujourd’hui beaucoup plus rigides, notamment la validation, le paiement du gas et l’exécution. Un compte pourrait utiliser une logique d’authentification différente, agréger plusieurs signatures, faire payer les frais par un tiers ou regrouper plusieurs actions.

Cette flexibilité ouvre aussi une voie pour remplacer les clés secp256k1 utilisées par les comptes traditionnels.

Ce point explique pourquoi Frames est devenu beaucoup plus qu’un projet d’amélioration des wallets. Si un compte peut changer de schéma de signature sans que chaque nouvelle cryptographie exige un format de compte entièrement différent, la migration vers des signatures post-quantiques devient moins brutale.

Hegotá n’est pas le fork post-quantique

L’Ethereum Foundation insiste elle-même sur la distinction. Hegotá ne doit pas rendre Ethereum quantiquement sûr à lui seul.

Son rôle est plutôt de poser suffisamment de briques pour que les forks qui suivent puissent respecter un calendrier désormais très agressif.

Le Protocol cluster s’est fixé comme objectif une résistance post-quantique complète des trois couches de L1 — exécution, consensus et données — avant décembre 2029.

L’hypothèse de travail est volontairement prudente : Ethereum doit être préparé à un éventuel « Q-day » dès 2030, même si la Foundation reconnaît que la plupart des estimations crédibles placent l’arrivée d’un ordinateur quantique cryptographiquement dangereux plus tard, voire beaucoup plus tard.

Cette date n’est donc pas une prévision sur les ordinateurs quantiques. C’est une échéance interne de migration.

Un plan B post-quantique doit arriver avant la protection complète

La feuille de route distingue une résistance post-quantique complète d’un jalon intermédiaire appelé MV-PQ, pour Minimum Viable Post-Quantum.

L’idée est de disposer d’un mode capable de maintenir Ethereum opérationnel si les progrès quantiques surprennent le calendrier, même avec des garanties temporairement réduites.

Dans la Strawmap actuelle, un registre de clés publiques post-quantiques apparaît dans le fork I*. Le jalon J* doit ensuite rassembler un heartbeat post-quantique pour le consensus, leanDA côté données et des transactions leanSPHINCS sur la couche d’exécution.

Les attestations post-quantiques complètes restent un chantier ultérieur, nécessaire pour préserver toute la finalité économique du consensus.

Le calendrier oblige Ethereum à développer plusieurs forks à la fois

Avec Glamsterdam envisagé pour décembre 2026 dans la planification publiée par le Protocol cluster et une cible de décembre 2029 pour la résistance complète, cinq forks doivent tenir dans un intervalle assez court.

Une progression jusqu’à L* demanderait en moyenne environ 7,2 mois entre chaque fork. Une trajectoire plus prudente, visant d’abord le jalon MV-PQ de J*, peut fonctionner avec une cadence proche de douze mois.

Dans les deux cas, l’Ethereum Foundation considère qu’un développement strictement séquentiel n’est pas suffisant.

Les équipes devront implémenter Hegotá pendant que les spécifications d’I* mûrissent et que les travaux de recherche sur J*, K* et L* avancent déjà.

La plupart des 62 EIP ne passeront pas

Le classement publié par le Protocol cluster reflète cette contrainte.

Deux EIP sont considérés comme indispensables, quinze sont considérés comme susceptibles d’être intégrés et vingt-huit ont été refusés avec une justification. D’autres propositions restent conditionnées à du travail supplémentaire, à de nouvelles données ou à des décisions techniques non terminées.

L’Ethereum Foundation tire notamment des rétrospectives de Glamsterdam une leçon assez sèche : la complexité réelle d’un EIP ne correspond pas forcément à la taille de son diff de code.

Une modification minuscule peut toucher de nombreux clients, plusieurs couches du protocole et une grande surface de test.

Le pipeline retenu devient donc Research, EIP, Prototype, Devnet, puis les différents niveaux PFI, CFI et SFI avant le mainnet. Un mauvais résultat sur devnet peut renvoyer une proposition directement en recherche.

La confidentialité entre déjà dans Hegotá

Le programme ne se limite pas au quantique. Le Protocol cluster veut commencer à ajouter les briques nécessaires à des transactions privées natives et résistantes à la censure sur L1.

EIP-8250 introduit des nonces séparés qui permettent à plusieurs utilisateurs de partager un même sender sans que leurs transactions se bloquent mutuellement.

EIP-8272 fournit de son côté un accès aux racines récentes de l’état afin que des transactions privées puissent s’appuyer sur des données récentes tout en restant compatibles avec les garanties d’inclusion de FOCIL.

Ces propositions sont pensées avec Frames plutôt que comme trois fonctions isolées.

Même les anciennes clés de retrait des validateurs entrent dans le chantier

EIP-8365 propose de commencer à retirer les credentials de retrait BLS reposant encore sur une cryptographie considérée comme vulnérable face à un ordinateur quantique suffisamment puissant.

Cette partie peut commencer avant que toute l’architecture post-quantique du consensus soit finalisée.

À l’inverse, l’Ethereum Foundation estime que la couche consensus ne peut pas adopter la même agilité cryptographique que les comptes utilisateurs. Les signatures et mécanismes d’agrégation du consensus doivent être testés ensemble avant leur déploiement par hard fork.

Ethereum organise maintenant ses forks autour de ce qu’il refuse d’y mettre

C’est peut-être le changement le plus visible dans cette publication.

Pendant longtemps, la roadmap Ethereum a surtout été lue comme une accumulation de fonctions futures : statelessness, account abstraction, zkEVM, meilleure finalité, confidentialité, réduction du state.

La planification de Hegotá ressemble davantage à un exercice de budget technique.

FOCIL occupe presque tout l’espace supplémentaire que le Protocol cluster souhaite consacrer au consensus. Frames concentre une grande partie du travail d’exécution. Le reste doit démontrer qu’il contribue à ces trajectoires sans retarder les forks suivants.

Les équipes clients pourraient commencer l’implémentation de Hegotá vers la fin du quatrième trimestre 2026. Sa composition définitive dépendra encore des prototypes, devnets et décisions AllCoreDevs.

Soixante-deux propositions sont entrées dans le processus. Ethereum a maintenant surtout besoin de décider lesquelles il peut se permettre de ne pas livrer.