Compte à rebours 2029 : la course anti-quantique d'Ethereum démarre avec Hegotá

Auteur original : KarenZ, Foresight News

Les ordinateurs quantiques n'ont pas encore frappé à la porte de la blockchain, mais la Fondation Ethereum a déjà encerclé une date sur le calendrier : décembre 2029.

C'est l'échéance technique que l'équipe protocole de la Fondation Ethereum s'est fixée : se préparer selon un scénario où la menace quantique pourrait survenir plus tôt, afin d'achever la migration anti-quantique de la couche 1 d'Ethereum avant que le risque ne devienne réel.

Hegotá, en cours de planification, ne transformera pas directement Ethereum en une blockchain entièrement résistante aux quantiques, mais déterminera si les plans suivants pourront avancer dans les temps.

La Fondation Ethereum fixe une échéance 2029 pour le « Q-day »

Le « Q-day » désigne généralement un moment hypothétique où des ordinateurs quantiques capables d'attaques réelles apparaîtraient, menaçant ainsi les systèmes cryptographiques à clé publique actuels.

Personne ne peut prédire avec précision quand il surviendra. La Fondation Ethereum reconnaît d'ailleurs explicitement que la plupart des prévisions crédibles situent le Q-day après 2030, voire beaucoup plus tard, et qu'il est possible qu'il ne survienne jamais.

L'équipe protocole de la Fondation Ethereum adopte une hypothèse d'ingénierie prudente : la couche 1 d'Ethereum doit se préparer à un Q-day pouvant survenir dès 2030.

À cette fin, l'équipe protocole s'est fixé un objectif : rendre la couche 1 d'Ethereum entièrement résistante aux quantiques d'ici décembre 2029, sur ses trois composantes : exécution, consensus et données.

Cet objectif n'est pas gravé dans le marbre. L'équipe protocole prévoit de réévaluer l'évolution de l'informatique quantique en janvier 2027, en s'appuyant sur des avis d'experts externes. D'ici là, l'échéance de 2029 sera traitée comme un objectif de travail difficilement négociable.

La migration anti-quantique doit être préparée des années à l'avance, car Ethereum n'utilise pas une seule technique cryptographique et ne peut pas migrer en remplaçant simplement un algorithme de signature. La manière dont les comptes utilisateurs prouvent l'autorisation des transactions, dont les validateurs participent au consensus et dont les données sont vérifiées repose sur des structures cryptographiques différentes. Toute modification exige une conception de spécification, une implémentation client, un audit de sécurité, des tests sur réseau de développement et une coordination sur le réseau principal. Il est impossible d'attendre que la menace se matérialise pour commencer à agir.

Hegotá n'est pas une « mise à niveau anti-quantique », mais c'est le premier test de tout le plan

Selon la feuille de route de référence publiée par l'équipe protocole de la Fondation Ethereum, la mise à niveau réseau Glamsterdam est prévue pour décembre 2026 sur le réseau principal, et la résistance quantique complète est programmée pour le cinquième hard fork après Glamsterdam, L*, avec une échéance cible de décembre 2029. Entre Glamsterdam et L*, il n'y a que trois ans. Pour enchaîner Hegotá, I*, J*, K* et L*, l'intervalle moyen entre chaque mise à niveau serait d'environ 7,2 mois.

C'est un calendrier très ambitieux. Actuellement, la Fondation Ethereum n'a pas publié de dates précises de mise en ligne sur le réseau principal pour Hegotá, I*, J* et K*. Ce qui est certain, c'est que les équipes client prévoient de commencer l'implémentation de Hegotá au plus tôt fin du quatrième trimestre 2026, et que la recherche, les spécifications et les tests de plusieurs versions ultérieures devront avancer en parallèle.

Selon la feuille de route actuelle, les principales étapes sont les suivantes :

• Hegotá : le point de départ de cette feuille de route. Le positionnement officiel est très clair : Hegotá n'est pas en soi une mise à niveau anti-quantique, mais elle déterminera si les mises à niveau anti-quantiques suivantes pourront avancer dans les temps.
• I* : déploiement d'un registre de clés publiques anti-quantiques, établissant la base protocolaire pour l'enregistrement et l'utilisation de clés publiques anti-quantiques par les comptes ; parallèlement, le découplage du consensus est actuellement la direction candidate principale de cette version, et les travaux de conception et de migration de structures d'état à grande échelle devraient également commencer avec I*.
• J* : mise en place d'une couche 1 « anti-quantique minimale viable », ou MV-PQ. Ses composants clés incluent un mécanisme de heartbeat anti-quantique au niveau consensus, un échantillonnage leanDA post-quantique au niveau données, et des transactions leanSPHINCS post-quantiques au niveau exécution.
• K* : selon l'ordre de référence actuel, introduction des preuves d'exécution obligatoires. À ce stade, les validateurs évolueront vers la vérification de preuves d'exécution succinctes, plutôt que de réexécuter chaque bloc complet.
• L* : selon l'ordre de référence actuel, ajout des messages de preuve anti-quantiques nécessaires à un consensus anti-quantique complet, c'est-à-dire les attestations post-quantiques, et atteinte de l'objectif de résistance quantique complète des couches exécution, consensus et données en décembre 2029.

Toutefois, l'ordre des tâches de K* et L* n'est pas encore définitivement arrêté. L'équipe protocole évalue une permutation : avancer les messages de preuve anti-quantiques de L* à K*, afin d'atteindre plus tôt la résistance quantique complète, tout en reportant les preuves d'exécution obligatoires de K* à L*. Si cette option est retenue, les responsabilités précises de K* et L* ainsi que le rythme des mises à niveau changeront en conséquence. Par conséquent, la formulation la plus exacte à ce stade est la suivante : décembre 2026 est l'objectif actuel de Glamsterdam sur le réseau principal, décembre 2029 est l'objectif de L* et de la résistance quantique complète dans la feuille de route de référence ; l'ordre interne de K* et L* peut encore être ajusté.

Les chercheurs, développeurs clients, auditeurs de sécurité et équipes de test doivent à la fois terminer Hegotá et préparer à l'avance les spécifications et prototypes pour I*, J*, K* et L*. Si Hegotá intègre trop de fonctionnalités interdépendantes, elle risque non seulement de retarder sa propre mise en ligne, mais aussi d'accaparer les équipes nécessaires aux travaux anti-quantiques ultérieurs.

L'équipe protocole de la Fondation Ethereum a donc classé les propositions candidates de Hegotá en niveaux S (2), A (15), B (8), C (7), DFI (28) et TBD (2), soit 62 propositions candidates au total. Le niveau S signifie livraison obligatoire ; le niveau A signifie priorité élevée et livraison prévue ; le niveau B exige encore des conditions telles que spécification, prototype ou confirmation d'un responsable ; le niveau C est temporairement en dessous du seuil d'inclusion ; DFI signifie déconseillé pour cette mise à niveau ; TBD signifie à déterminer.

Les deux niveaux S de Hegotá : FOCIL et Frames

Dans le classement Hegotá publié par l'équipe protocole, seuls deux EIP atteignent le niveau S : EIP-7805 FOCIL au niveau consensus, et EIP-8141 Frame Transactions au niveau exécution.

Ils traitent respectivement deux questions clés du cycle de vie des transactions : une transaction éligible peut-elle entrer dans un bloc, et par quels moyens un compte peut-il vérifier et exécuter une transaction.

FOCIL (EIP-7805) signifie « Fork-choice enforced Inclusion Lists » (listes d'inclusion imposées par la règle de choix de fourche). Son objectif est d'améliorer la garantie d'inclusion des transactions sur Ethereum.

Actuellement, des constructeurs de blocs professionnels dominent la production de blocs. Cette division du travail améliore l'efficacité de la construction des blocs, mais si la production de blocs se concentre durablement entre les mains de quelques constructeurs, ceux-ci pourraient acquérir un fort pouvoir de filtrage des transactions. FOCIL ajoute donc, en dehors du processus normal de construction de blocs, une contrainte d'inclusion provenant des validateurs.

Selon la conception de FOCIL, à chaque slot, un ensemble de validateurs est sélectionné pour former un « comité de listes d'inclusion » (IL committee). Les membres du comité produisent et diffusent chacun une liste d'inclusion basée sur les transactions en attente qu'ils observent. Le constructeur de blocs du slot suivant collecte ces listes et inclut dans son bloc les transactions qui satisfont aux conditions d'exécution. Les validateurs chargés d'attester le nouveau bloc conservent également les listes d'inclusion reçues à temps et vérifient si le bloc satisfait aux exigences correspondantes.

Si un bloc omet sans raison valable des transactions figurant dans les listes conservées par les validateurs, les attestants ne voteront pas pour ce bloc. Un tel bloc, même s'il reste valide au niveau exécution, ne pourra pas obtenir le soutien du consensus nécessaire pour entrer dans la chaîne canonique. C'est là tout l'intérêt de FOCIL : il ne permet pas aux membres du comité de modifier directement le bloc, mais contraint les choix du constructeur de blocs par le vote des validateurs.

L'EIP-8369, qui l'accompagne, précise quelles transactions peuvent bénéficier de la garantie d'inclusion obligatoire de FOCIL. Pour les transactions ordinaires, les raisons d'une omission sont relativement faciles à vérifier ; les transactions Frames permettent une vérification programmable, dont le coût de jugement est plus élevé, ce qui exige de limiter davantage l'étendue des états lisibles et le budget de vérification.

En termes simples, FOCIL ne permet pas aux validateurs de s'emparer du travail des constructeurs de blocs, mais ajoute une règle de consensus pour les constructeurs : vous pouvez toujours organiser la plupart des transactions du bloc, mais vous ne pouvez pas, sans raison valable, ignorer en permanence les transactions éligibles listées par le comité.

Les Frame Transactions (EIP-8141) traitent du problème au niveau des comptes. Elles visent à rendre la vérification des transactions, l'exécution des transactions et le paiement du gaz plus programmables au niveau du protocole, jetant ainsi les bases d'une abstraction native des comptes. Vitalik est l'un des co-auteurs de l'EIP-8141.

Actuellement, la plupart des comptes Ethereum ordinaires reposent sur un type fixe de signature à clé privée. Frames souhaite permettre aux comptes d'utiliser une logique de vérification plus flexible, par exemple adopter de nouveaux schémas de signature, combiner plusieurs conditions d'autorisation, ou permettre à d'autres comptes de payer les frais de transaction. Il peut également prendre en charge l'agrégation de signatures et permettre l'introduction future de nouveaux schémas de signature sans qu'un hard fork soit nécessaire pour chacun d'eux.

Mais Frames n'est pas en soi un schéma de signature anti-quantique complet, et il n'éliminera pas immédiatement les clés existantes après la mise en ligne de Hegotá. Il offre une « agilité cryptographique » : si un changement de schéma de signature devient nécessaire à l'avenir, les comptes pourront migrer par vérification programmable, au lieu d'être enfermés à jamais dans un système de clés unique.

Frames nécessite également deux propositions de niveau A comme accompagnement essentiel. EIP-8250 Keyed Nonces permet à un même expéditeur d'utiliser des canaux de nonce indépendants, évitant que différentes transactions ne se bloquent mutuellement en raison d'un ordre strict partagé ; EIP-8272 permet aux transactions d'utiliser un état récent de la chaîne vérifiable par les validateurs, afin que les transactions privées concernées puissent également bénéficier de la garantie d'inclusion offerte par FOCIL.

FOCIL et Frames ne sont donc pas deux fonctionnalités sans rapport. Le premier modifie les transactions éligibles qu'un bloc doit inclure, le second modifie la structure de vérification des transactions elles-mêmes. Leur capacité à coopérer en toute sécurité est l'une des tâches de test les plus importantes de Hegotá.

Au-delà du niveau S, quels EIP méritent l'attention ?

Les propositions de niveau S définissent la ligne principale de Hegotá, mais plusieurs propositions de niveau A influenceront également la sécurité des comptes, la migration anti-quantique, les preuves d'exécution et la tarification des ressources d'Ethereum à l'avenir.

D'abord, EIP-8365. Il prévoit de lancer le retrait progressif de certaines informations d'identification de retrait BLS, car celles-ci reposent encore sur des techniques cryptographiques susceptibles de perdre leur sécurité face à une attaque quantique suffisamment puissante. L'équipe protocole estime que cette migration peut commencer plus tôt, sans attendre que la conception complète du consensus anti-quantique soit arrêtée.

En matière de sécurité des comptes, EIP-7906, EIP-8298 et EIP-8151 sont considérés comme un ensemble d'extensions de Frames.

EIP-7906 introduit un mécanisme d'assertions de transaction (Transaction Assertions), permettant à une transaction de vérifier, avant sa soumission finale, si un résultat spécifié s'est produit. Ce mécanisme vise à réduire les pertes causées par les contrats malveillants qui siphonnent les actifs des portefeuilles ainsi que par certains comportements MEV. Toutefois, la portée exacte de lecture de cette proposition est encore en cours de recherche et de réduction ; la conception actuelle ne doit donc pas être considérée comme une spécification finale verrouillée.

EIP-8298 permet aux comptes de réutiliser le code de contrats existants, transformant ainsi les comptes délégués en comptes de contrats intelligents dotés d'un code complet. EIP-8151 limite la possibilité pour les adresses disposant déjà d'un code de compte de continuer à dépendre de l'authentification traditionnelle ecRecover.

Ce n'est qu'en combinant ces deux propositions que les comptes pourront réellement cesser d'utiliser l'ancienne clé secp256k1 comme justificatif de contrôle suprême, ouvrant ainsi une voie complète vers l'abandon de l'ancien système de clés.

EIP-8025 (preuves d'exécution optionnelles) est lié à la future feuille de route zkEVM. Il prévoit d'intégrer les modifications nécessaires aux preuves d'exécution optionnelles dans une spécification d'exécution unifiée, afin de réduire les problèmes de maintenance de versions divergentes entre les différents projets zkVM.

EIP-8279 (couche Byte des listes d'accès aux blocs) et EIP-8131 (couche unifiée de contenu des transactions) forment un ensemble de propositions de sécurité d'exécution. Elles fixent respectivement des normes de tarification minimales pour les listes d'accès aux blocs et le contenu des transactions, afin de limiter la capacité des attaquants à créer des charges de ressources extrêmes en exploitant des contenus sous-tarifés. Elles s'attaquent d'abord au coût de traitement des blocs dans le pire des cas, et non à une augmentation directe de la capacité du réseau. La question de savoir s'il faut utiliser la marge de sécurité ainsi créée pour augmenter la capacité devra faire l'objet d'une décision séparée ultérieure.

EIP-3298 prévoit de supprimer complètement le mécanisme de remboursement de gaz, réduisant ainsi les cas particuliers dans le comptage, l'implémentation et les tests ; EIP-5920 (PAY Opcode) permet aux contrats de transférer de l'ETH sans exécuter le code du contrat destinataire, séparant clairement le « transfert de valeur » de l'« appel de contrat ».

Parallèlement, certaines propositions très suivies restent au niveau B.

Par exemple, EIP-8198 (Quick Slots) vise à raccourcir la durée des slots, mais l'équipe protocole exige qu'il complète d'abord une spécification couvrant les modifications du protocole de base, un prototype complet, une évaluation des impacts en aval, et qu'il démontre qu'il ne perturbera pas la future conception de découplage du consensus. La raison en est que la durée des slots n'affecte pas seulement la vitesse de production des blocs, mais aussi la propagation sur le réseau, les décisions de consensus et les hypothèses temporelles des applications.

En outre, EIP-8368 et EIP-8372 sont classés « TBD » (à déterminer). Ces deux propositions concernent la limite de gaz et la tarification des ressources d'état. L'équipe protocole a décidé d'attendre les données du réseau principal après la mise en ligne de Glamsterdam en décembre 2026 pour juger si un recalibrage est nécessaire.

Le nombre d'EIP finalement inclus dans Hegotá n'est pas le seul critère de succès de cette mise à niveau.

Plus important encore, il s'agit de savoir si elle peut livrer FOCIL, Frames et leurs accompagnements essentiels sans sacrifier la sécurité et la qualité des tests, tout en laissant suffisamment de ressources de R&D pour le registre de clés publiques et le découplage du consensus d'I*, la résistance quantique minimale viable de J*, ainsi que les preuves d'exécution et le consensus anti-quantique complet de K* et L*.

Selon les objectifs actuels, Glamsterdam lancera ce cycle de mises à niveau resserré en décembre 2026, et L*, dans la feuille de route de référence, atteindra son terme en décembre 2029. Chaque mise à niveau intermédiaire ne pourra pas se contenter de remplir ses propres fonctionnalités ; elle devra aussi garantir que l'étape suivante puisse continuer d'avancer.

Personne ne peut affirmer avec certitude si la menace quantique deviendra réalité avant 2030. Mais le choix actuel d'Ethereum est déjà clair : fixer d'abord une échéance pour le risque, puis laisser chaque proposition prouver, par ses spécifications, ses prototypes et ses tests, qu'elle remplit les conditions pour entrer sur le réseau principal.

Références de l'article :

https://blog.ethereum.org/2026/09/07/protocol-hegota-eips

https://blog.ethereum.org/2026/09/07/protocol-priorities

https://x.com/VitalikButerin/status/2073459000398463446