Le point le plus intéressant de la nouvelle feuille de route Ethereum n'est pas qu'elle parle d'ordinateurs quantiques. Le sujet traîne dans la cryptographie depuis des années. Ce qui change est la date inscrite à côté : décembre 2029.

Le Protocol cluster de l'Ethereum Foundation veut qu'à cette échéance le L1 soit résistant au quantique sur trois plans à la fois : exécution, consensus et données. Il demande pour l'instant aux équipes de travailler comme si un ordinateur quantique suffisamment puissant pour menacer la cryptographie actuelle pouvait exister dès 2030.

La Fondation précise elle-même que cette hypothèse est volontairement agressive. La plupart des estimations jugées crédibles placent le fameux « Q-day » plus tard, parfois beaucoup plus tard, et il pourrait même ne jamais arriver sous la forme redoutée. Attendre que le calendrier devienne certain serait néanmoins assez peu pratique pour modifier un protocole distribué mondial.

Le problème ne se résume pas à changer la clé d'un wallet

Ethereum utilise plusieurs briques cryptographiques différentes selon ce qu'il protège. Les comptes historiques reposent notamment sur secp256k1, tandis que le consensus utilise d'autres signatures et mécanismes d'agrégation. La couche de disponibilité des données possède encore ses propres contraintes.

Une migration post-quantique doit donc permettre aux utilisateurs de changer de schéma de signature, mais aussi faire évoluer les validateurs et leur façon de produire des attestations. C'est cette dernière partie qui complique sérieusement le calendrier : contrairement aux comptes programmables, la cryptographie du consensus ne peut pas être remplacée librement par chaque utilisateur.

Elle doit passer par un hard fork.

Hegotá ne sera pas le fork post-quantique

L'Ethereum Foundation insiste sur ce point. Hegotá n'est pas censé rendre Ethereum résistant au quantique. Il doit construire les fondations qui permettront aux forks suivants de le faire à temps.

Son élément majeur côté exécution est EIP-8141, Frame Transactions. Le principe consiste à rendre programmables au niveau du protocole plusieurs étapes d'une transaction : validation, paiement du gas et exécution. Pour les comptes, cette architecture apporte surtout de l'agilité cryptographique.

Un wallet pourrait adopter un nouveau schéma de signature sans attendre qu'un hard fork ajoute explicitement cet algorithme au modèle de compte. C'est une différence considérable lorsqu'on prépare une migration dont on ignore encore quelles primitives post-quantiques seront les meilleures au moment du déploiement.

Frames fournit également une voie permettant de sortir progressivement de secp256k1 comme clé maîtresse. EIP-8298 et EIP-8151 font partie des extensions étudiées pour transformer des comptes délégués en véritables comptes programmables puis bloquer l'ancienne authentification lorsqu'elle n'est plus nécessaire.

Le consensus n'a pas droit à la même souplesse

Pour les validateurs, impossible de laisser chacun choisir son algorithme dans son coin. Le réseau doit agréger et vérifier les signatures de façon cohérente, à grande échelle et avec des coûts prévisibles.

La stratégie est donc presque inverse : les futures primitives de consensus doivent être testées et stabilisées avant leur activation, puis introduites par hard fork. EIP-8365 commence déjà à préparer la retraite de credentials de retrait encore liés à une cryptographie vulnérable, sans attendre que l'ensemble du nouveau consensus post-quantique soit terminé.

L'objectif complet nécessite également des attestations post-quantiques. Elles sont indispensables pour conserver la finalité économique avec les nouvelles primitives et font partie des morceaux que la Fondation considère encore comme nécessaires après le premier jalon minimal.

Ethereum prépare aussi un mode de survie intermédiaire

La roadmap distingue désormais la résistance complète d'un niveau appelé « minimum viable post-quantum », ou MV-PQ. L'idée est moins élégante : maintenir Ethereum opérationnel si une rupture quantique arrivait avant la fin de toute la migration, quitte à fonctionner temporairement avec des garanties réduites.

Le registre de clés publiques post-quantiques est actuellement placé dans le fork provisoirement nommé I*. J* doit ensuite regrouper plusieurs briques beaucoup plus lourdes : un heartbeat post-quantique pour le consensus, du leanDA sampling côté données et des transactions leanSPHINCS côté exécution.

La configuration exacte du mode dégradé reste encore un sujet de recherche. Ce n'est donc pas un bouton « quantum safe » déjà spécifié et prêt à être activé.

Cinq forks et très peu de marge

Le calendrier explique l'urgence. Dans l'ordre actuel de la Strawmap, la résistance complète arrive avec L*, cinq hard forks après Glamsterdam. Si Glamsterdam arrive en décembre 2026 et L* en décembre 2029, Ethereum doit tenir une moyenne d'environ 7,2 mois entre les forks.

C'est rapide pour un protocole où chaque modification traverse recherche, EIP, prototype, devnet puis plusieurs niveaux de validation avant le mainnet.

Une autre trajectoire permettrait d'atteindre seulement MV-PQ avec un rythme d'environ douze mois par fork. Elle donnerait au réseau une solution de secours avant de terminer la migration complète.

Les équipes n'ont donc pas prévu de travailler séquentiellement. Pendant qu'Hegotá sera implémenté, les spécifications de I* devront déjà mûrir et la recherche sur J*, K* et L* continuer en parallèle.

Le quantique commence déjà à décider quelles fonctions peuvent attendre

C'est probablement la conséquence la plus immédiate. La menace n'a pas besoin d'être concrète aujourd'hui pour consommer du temps de développement.

Après Glamsterdam, l'Ethereum Foundation place la livraison des composants nécessaires à Hegotá, I* et J* juste derrière la sécurité du mainnet dans son ordre de priorité. Les autres travaux de long terme — finalité rapide, confidentialité, état et zkEVM — continuent, mais doivent partager ressources de recherche, équipes clientes et capacité de test avec la migration post-quantique.

Même l'ordre de K* et L* peut changer. Une option actuellement étudiée consiste à avancer les attestations post-quantiques d'un fork et à repousser les preuves d'exécution zkEVM obligatoires afin de terminer plus tôt la partie consensus de la migration.

La date de décembre 2029 doit être réévaluée avec des experts externes en janvier 2027. Jusqu'à cette révision, le Protocol cluster la traite comme non négociable.