La Fondation Ethereum fixe une échéance en 2029 pour les mises à niveau résistantes aux ordinateurs quantiques

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à marqué une date sur son calendrier : décembre 2029.

C'est le délai technique fixé par l'équipe de protocole de la Fondation Ethereum : se préparer à un scénario où les menaces quantiques pourraient apparaître plus tôt, et accomplir la migration du réseau Ethereum de première couche vers une résistance quantique avant que le risque ne devienne imminent.

Hegotá, actuellement en planification, bien qu'il ne transforme pas directement Ethereum en une blockchain entièrement résistante aux ordinateurs quantiques, déterminera si les plans ultérieurs pourront être réalisés selon le calendrier prévu.

Le « Q-day » désigne généralement un point temporel hypothétique : l'apparition d'un ordinateur quantique capable d'effectuer des attaques réelles, mettant ainsi en péril les systèmes de cryptographie à clé publique actuels.

Personne ne peut prédire avec précision quand il arrivera. La Fondation Ethereum reconnaît également explicitement que la plupart des prédictions fiables estiment que le Q-day se produira après 2030, voire bien plus tard, et qu’il est possible qu’il n’arrive jamais.

L'équipe de protocole de la Fondation Ethereum adopte une hypothèse d'ingénierie prudente : la couche 1 d'Ethereum doit être préparée à l'avance en supposant que le jour Q pourrait arriver le plus tôt en 2030.

À cet effet, l'équipe du protocole a fixé un objectif : assurer une résistance complète à l'informatique quantique pour les trois composantes d'Ethereum de couche 1 — exécution, consensus et données — d'ici décembre 2029.

Cet objectif n'est pas non plus fixe à jamais. L'équipe du protocole prévoit de réévaluer l'évolution de l'informatique quantique en janvier 2027, en tenant compte des avis d'experts externes. Avant cela, la date limite de 2029 sera considérée comme un objectif de travail non négociable.

La préparation de la migration quantique doit être entreprise plusieurs années à l'avance, car Ethereum n'utilise pas qu'une seule technologie cryptographique, et la migration ne se limite pas à remplacer un algorithme de signature. La manière dont les comptes utilisateurs prouvent l'autorisation des transactions, la façon dont les validateurs participent à la consensus, et la manière dont les données sont vérifiées impliquent toutes des structures cryptographiques différentes. Toute modification doit passer par une conception normative, une implémentation client, un audit de sécurité, des tests sur un réseau de développement et une coordination sur la chaîne principale ; il est impossible d'attendre que la menace soit déjà présente pour commencer à y répondre.

Selon la feuille de route de référence publiée actuellement par l'équipe du protocole de la Ethereum Foundation, le déploiement du réseau Glamsterdam sur la mainnet est prévu pour décembre 2026, tandis que la pleine résistance quantique est prévue pour la cinquième hard fork après Glamsterdam, nommée L*, avec une date cible de décembre 2029. Entre Glamsterdam et L*, il ne reste que trois ans ; pour accomplir successivement Hegotá, I*, J*, K* et L*, la durée moyenne entre chaque mise à jour ne serait que d'environ 7,2 mois.

Ceci est un calendrier assez agressif. Pour l'instant, la Fondation Ethereum n'a pas annoncé de dates de lancement sur la chaîne principale pour Hegotá, I*, J* et K*. Il est certain que les équipes de clients prévoient de commencer à implémenter Hegotá à la fin du quatrième trimestre 2026 au plus tôt, tandis que la recherche, les spécifications et les tests de plusieurs versions ultérieures doivent être menés en parallèle.

Selon le chemin actuel, les principales étapes sont les suivantes :

• Hegotá : situé au point de départ de cette route. L'officialisation de son rôle est très claire : Hegotá n'est pas lui-même une mise à niveau résistante aux ordinateurs quantiques, mais il déterminera si les mises à niveau résistantes aux ordinateurs quantiques suivantes peuvent avancer selon le planning prévu.
• I* : Déployer un registre de clés publiques résistantes aux ordinateurs quantiques pour établir une base protocolaire en matière d'enregistrement de comptes et d'utilisation de clés publiques résistantes aux ordinateurs quantiques ; en outre, le découplage du consensus est actuellement la direction principale en tête pour cette version, et des travaux importants de conception et de migration de structures d'état à grande échelle sont prévus à partir de I*.
• J* : Établir une couche « minimale viable anti-quantique », soit MV-PQ. Ses composants clés incluent le mécanisme anti-quantique heartbeat au niveau de la couche de consensus, l'échantillonnage post-quantique leanDA au niveau des données, et les transactions post-quantiques leanSPHINCS au niveau de l'exécution.
• K* : Selon l'ordre actuel de référence, introduire une preuve d'exécution obligatoire. À ce stade, la direction des validateurs sera de vérifier des preuves d'exécution succinctes, plutôt que de réexécuter chaque bloc complet.
• L* : En se basant sur l'ordre actuel, compléter les messages de preuve post-quantique, soit les post-quantum attestations, nécessaires pour atteindre une consensus entièrement post-quantique, et atteindre l'objectif complet post-quantique au niveau de la couche d'exécution, de la couche de consensus et de la couche de données d'ici décembre 2029.

Cependant, l'ordre des tâches K* et L* n'est pas encore définitif. L'équipe du protocole évalue une proposition d'échange : déplacer le message de preuve post-quantique de L* à K* afin d'atteindre plus tôt une capacité entièrement post-quantique, tout en reportant l'exécution forcée de la preuve de K* à L*. Si cette approche est adoptée, les responsabilités spécifiques de K* et L*, ainsi que le rythme des mises à jour, seront ajustés en conséquence. Ainsi, la déclaration la plus précise à ce jour est la suivante : décembre 2026 est l'objectif actuel pour le mainnet de Glamsterdam, et décembre 2029 est l'objectif de la trajectoire de référence pour L* et la capacité post-quantique complète ; l'ordre interne de K et L* peut encore être modifié.

Les chercheurs, les développeurs de clients, les responsables de sécurité et l'équipe de test doivent à la fois finaliser 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, non seulement son lancement pourrait être retardé, mais il risque également de monopoliser les ressources de l'équipe nécessaires aux travaux futurs anti-quantiques.

Ainsi, l'équipe de protocole de la Fondation Ethereum a classé les 62 propositions candidates en catégories S (2), A (15), B (8), C (7), DFI (28) et TBD (2). La catégorie S indique des livrables obligatoires ; la catégorie A désigne des propositions de haute priorité, prévues comme livrables ; la catégorie B nécessite encore la satisfaction de conditions telles que la spécification, le prototype ou la confirmation du responsable ; la catégorie C est temporairement en dessous de la ligne d'admission ; DFI signifie qu'il n'est pas recommandé d'inclure la proposition dans cette mise à jour ; et TBD indique que la décision est en attente.

Dans le classement Hegotá publié par l'équipe du protocole, seuls deux EIP atteignent la catégorie S : EIP-7805 FOCIL au niveau de la couche de consensus et EIP-8141 Frame Transaction au niveau de la couche d'exécution.

Ils traitent deux problèmes clés du cycle de vie des transactions : une transaction éligible peut-elle être incluse dans un bloc, et un compte peut-il valider et exécuter une transaction par quel moyen ?

FOCIL (EIP-7805) signifie « Inclusion Lists enforced by Fork-choice ». Son objectif est d'améliorer les garanties d'inclusion des transactions sur Ethereum.

Actuellement, les constructeurs de blocs professionnels dominent la génération des blocs. Cette répartition des tâches améliore l'efficacité de la construction des blocs, mais si la production de blocs reste à long terme concentrée entre les mains de quelques constructeurs, ceux-ci pourraient acquérir une forte capacité de sélection des transactions. FOCIL ajoute donc, en plus du processus normal de construction de blocs, une couche de contraintes d'inclusion imposées par les validateurs.

Conformément à la conception de FOCIL, chaque Slot sélectionne un groupe de validateurs pour former un « comité de liste d'inclusion » (IL committee). Les membres du comité établissent et diffusent chacun leur propre liste d'inclusion en fonction des transactions en attente qu'ils observent. Le constructeur de bloc du Slot suivant regroupe ces listes et intègre dans le bloc les transactions satisfaisant les conditions d'exécution. Les validateurs chargés de prouver le nouveau bloc conservent également les listes d'inclusion qu'ils ont reçues en temps voulu et vérifient que le bloc répond aux exigences correspondantes.

Si un bloc omet sans raison valable les transactions enregistrées par les validateurs, les proveurs ne voteront pas pour ce bloc. Même si ce bloc reste valide au niveau de l'exécution, il ne recevra pas le soutien de consensus nécessaire pour entrer dans la chaîne canonique. C'est précisément le rôle de FOCIL : il ne permet pas aux membres du comité de modifier directement les blocs, mais contraint les constructeurs de blocs par le biais du vote des validateurs.

L'EIP-8369 décrit en détail quelles transactions sont admissibles à la garantie d'inclusion obligatoire FOCIL. Les raisons de l'omission des transactions ordinaires sont relativement faciles à vérifier ; les transactions Frames permettent une vérification programmable, mais le coût de cette vérification est plus élevé, ce qui nécessite de limiter supplémentairement les états accessibles et le budget de vérification.

En termes simples, FOCIL ne consiste pas à faire en sorte que les validateurs prennent le travail de construction de blocs aux constructeurs, mais à ajouter une règle de la couche de consensus aux constructeurs : vous pouvez toujours organiser la majorité des transactions dans le bloc, mais vous ne pouvez pas ignorer de manière persistante les transactions qualifiées listées par le comité sans raison valable.

Frame Transactions (EIP-8141) traite les problèmes au niveau du compte. Il vise à rendre la validation des transactions, l'exécution des transactions et le paiement du gaz plus programmables au niveau du protocole, en fournissant une base pour l'abstraction de compte native. Vitalik est l'un des co-auteurs de l'EIP-8141.

Actuellement, la plupart des comptes Ethereum ordinaires dépendent de signatures de clés privées de type fixe. Frames souhaite permettre aux comptes d'utiliser des logiques de vérification plus flexibles, telles que l'adoption de nouveaux schémas de signature, la combinaison de plusieurs conditions d'autorisation ou le fait de permettre à d'autres comptes de payer les frais de transaction. Il peut également prendre en charge l'agrégation des signatures et permettre l'introduction future de nouveaux schémas de signature sans nécessiter une hard fork distincte pour chaque schéma.

Cependant, Frames n'est pas lui-même un schéma de signature résistant aux ordinateurs quantiques, et il n'éliminera pas immédiatement les clés existantes après le lancement de Hegotá. Il offre une « agilité cryptographique » : à l'avenir, si un changement de schéma de signature est nécessaire, les comptes pourront effectuer une migration via une vérification programmable, au lieu d'être définitivement verrouillés dans un seul système de clés.

Frames nécessite deux propositions de niveau A comme composants essentiels. L'EIP-8250 Keyed Nonces permet à un même expéditeur d'utiliser des canaux de nonce indépendants, afin que différentes transactions ne se bloquent pas mutuellement en raison d'une séquence stricte partagée ; l'EIP-8272 permet aux transactions d'utiliser un état récent sur chaîne vérifiable par les validateurs, garantissant ainsi aux transactions privées associées la même protection d'inclusion fournie par FOCIL.

Ainsi, FOCIL et Frames ne sont pas deux fonctions indépendantes. La première détermine quelles transactions éligibles doivent être incluses dans un bloc, tandis que la seconde modifie la structure de validation des transactions elles-mêmes. Leur capacité à fonctionner ensemble en toute sécurité constitue l'une des tâches de test les plus importantes de Hegotá.

La proposition de niveau S définit la ligne directrice de Hegotá, mais plusieurs propositions de niveau A affectent également la sécurité des comptes futurs d'Ethereum, la migration résistante aux ordinateurs quantiques, la preuve d'exécution et la tarification des ressources.

Tout d'abord, EIP-8365. Il prévoit de lancer un retrait progressif pour certains identifiants de retrait BLS, car ces derniers dépendent encore de technologies cryptographiques qui pourraient perdre leur sécurité face à des attaques quantiques suffisamment puissantes. L'équipe du protocole estime que ce transfert peut commencer plus tôt, sans attendre la finalisation d'une conception de consensus résistante aux quantiques.

En matière de sécurité de compte, EIP-7906, EIP-8298 et EIP-8151 sont considérés comme une combinaison d'extensions pour Frames.

EIP-7906 introduit le mécanisme d'assertions de transaction, permettant de vérifier si un résultat spécifique s'est produit avant la soumission finale de la transaction. Ce mécanisme vise à réduire les pertes causées par des contrats malveillants qui vidangent les actifs des portefeuilles et par certaines pratiques de MEV. Toutefois, la portée exacte de lecture de cette proposition est encore en cours d'étude et de précision ; il ne faut donc pas considérer la conception actuelle comme une spécification finale et figée.

EIP-8298 permet la réutilisation du code de contrat existant par les comptes, transformant ainsi les comptes délégués en comptes de contrat intelligent avec code complet. EIP-8151 limite la dépendance des adresses de comptes existants à l'authentification traditionnelle ecRecover.

Lorsque ces deux propositions sont combinées, le compte pourra véritablement cesser d'utiliser l'ancienne clé secp256k1 comme certificat de contrôle principal, établissant ainsi un chemin complet pour quitter l'ancien système de clés.

EIP-8025 (Optional Execution Proofs) est lié à la future feuille de route zkEVM. Il prévoit d'intégrer les modifications nécessaires pour les preuves d'exécution optionnelles dans la spécification d'exécution unifiée, réduisant ainsi les problèmes de maintenance à long terme de versions forkées distinctes par différents projets zkVM.

EIP-8279 (Byte Layer for Block Access Lists) et EIP-8131 (Unified Transaction Content Layer) constituent un ensemble de propositions de sécurité d'exécution. Ces deux normes établissent des seuils minimaux de tarification pour les listes d'accès aux blocs et le contenu des transactions, dans le but de limiter la capacité des attaquants à créer une charge extrême sur les ressources en exploitant des contenus mal tarifés. Elles visent d'abord à résoudre le coût de traitement des blocs dans le pire des cas, et non à déclarer directement une augmentation de la capacité du réseau. L'utilisation de la marge de sécurité ainsi générée pour augmenter la capacité devra être décidée séparément ultérieurement.

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

En parallèle, certaines propositions notables restent à la catégorie B.

Par exemple, l'EIP-8198 (Quick Slots) vise à réduire la durée des slots, mais l'équipe du protocole exige qu'elle complète d'abord la spécification, le prototype complet et l'évaluation des impacts en aval des modifications du protocole central, tout en démontrant qu'elle n'interférera pas avec la conception ultérieure de la consensualité découplée. La raison en est que la durée des slots affecte non seulement la vitesse de production des blocs, mais aussi la propagation réseau, les jugements de consensus et les hypothèses des applications concernant le temps.

En outre, les EIP-8368 et EIP-8372 sont listés comme « TBD » (à déterminer). Ces deux propositions concernent les limites de Gas et la tarification des ressources d'état ; l'équipe du protocole a décidé d'attendre les données de la chaîne principale après le déploiement de Glamsterdam en décembre 2026 avant de déterminer si un recalibrage est nécessaire.

Le nombre d'EIP finalement intégrés par Hegotá n'est pas le seul critère pour mesurer le succès de cette mise à jour.

Plus important encore, peut-il livrer FOCIL, Frames et leurs composants principaux sans compromettre la sécurité ni la qualité des tests, tout en laissant suffisamment de ressources de recherche et développement pour l'enregistrement de la clé publique de I*, le découplage du consensus, la capacité minimale viable de résistance quantique de J*, ainsi que les preuves d'exécution et le consensus entièrement résistant aux ordinateurs quantiques pour K* et L*.

Selon l'objectif actuel, Glamsterdam lancera cette période d'upgrade intensive en décembre 2026, tandis que L* dans la feuille de route de référence atteindra son point final en décembre 2029. Chaque mise à niveau intermédiaire ne doit pas seulement se concentrer sur l'accomplissement de ses propres fonctionnalités, mais aussi garantir que la phase suivante puisse continuer à progresser.

Personne ne peut donner de réponse certaine quant à savoir si la menace quantique deviendra une réalité avant 2030. Toutefois, le choix actuel d’Ethereum est clair : établir d’abord un délai pour les risques, puis laisser chaque proposition prouver, par des spécifications, des prototypes et des tests, qu’elle répond aux critères nécessaires pour intégrer la chaîne principale.

Article de référence :

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