L'Ethereum Foundation a publié cette nouvelle hiérarchie de priorités le 7 septembre 2026.

La résistance post-quantique n'est plus présentée comme un sujet de recherche à très long terme.

Elle devient l'un des éléments qui doivent directement influencer la conception des prochains hard forks.

L'objectif affiché est une Ethereum L1 résistante au quantique sur les couches d'exécution, de consensus et de données avant décembre 2029.

2030 est une hypothèse de planification, pas une date de catastrophe

L'Ethereum Foundation emploie une hypothèse volontairement agressive : planifier comme si le « Q-Day » pouvait arriver dès 2030.

Q-Day désigne ici le moment où un ordinateur quantique suffisamment puissant pourrait casser en pratique certaines primitives cryptographiques utilisées aujourd'hui.

La Fondation précise elle-même que la plupart des estimations crédibles placent cet événement plus tard, parfois beaucoup plus tard, et qu'il pourrait même ne jamais se produire sous la forme imaginée.

Le choix de 2030 sert donc surtout à empêcher le protocole de repousser indéfiniment sa migration.

La pertinence de cette hypothèse doit être réévaluée en janvier 2027 avec des experts externes.

Un ordinateur quantique actuel ne peut pas voler vos ETH

La conséquence la plus importante pour les utilisateurs est aussi la plus simple : il n'existe aujourd'hui aucun ordinateur quantique capable de casser la cryptographie d'Ethereum.

La Fondation ne demande donc aucune migration urgente de portefeuille.

Le travail commence tôt parce qu'une migration cryptographique à l'échelle d'un réseau décentralisé prend des années.

Il faut définir les nouveaux algorithmes, modifier plusieurs clients, construire des devnets, vérifier leur interopérabilité, auditer le code, tester les performances puis organiser la transition de millions de comptes.

Ethereum doit remplacer plusieurs systèmes, pas seulement une signature

Le problème quantique touche plusieurs couches du protocole.

Les comptes classiques utilisent aujourd'hui des signatures basées sur secp256k1 et ECDSA.

Les validateurs reposent sur des signatures BLS.

Les blobs et certaines fonctions de disponibilité des données utilisent des engagements KZG.

Une partie de l'écosystème ZK repose également sur des constructions utilisant des courbes elliptiques.

Un seul nouvel algorithme ne suffit donc pas à rendre Ethereum entièrement post-quantique.

Les comptes ayant déjà envoyé une transaction ont une particularité

Dans un compte Ethereum classique, l'adresse visible avant toute dépense est dérivée d'un hash de la clé publique.

Lorsqu'une transaction est signée et publiée, suffisamment d'informations deviennent disponibles pour reconstruire la clé publique.

Un futur ordinateur quantique capable d'exécuter l'algorithme de Shor à l'échelle nécessaire pourrait théoriquement utiliser cette clé publique pour retrouver la clé privée.

Les comptes qui n'ont jamais émis de transaction disposent donc d'une couche de protection supplémentaire tant que leur clé publique reste cachée derrière son hash.

Cela ne signifie pas qu'ils pourront ignorer éternellement une future migration.

EIP-8141 doit éviter une migration de tous les comptes le même jour

Ethereum ne veut pas organiser un gigantesque « flag day » où tous les portefeuilles changeraient simultanément de signature.

Une partie essentielle de la stratégie repose sur l'abstraction de compte native.

EIP-8141, aussi appelée Frame Transactions, permet de rendre la validation d'une transaction beaucoup plus programmable au niveau du protocole.

Un compte pourrait alors choisir une nouvelle méthode de signature sans qu'un nouveau hard fork soit nécessaire pour chaque algorithme ajouté.

Cette agilité cryptographique permettrait aux portefeuilles de migrer progressivement vers des signatures résistantes au quantique.

Hegotá n'est pas le fork post-quantique, mais il prépare la migration

Le prochain jalon important après Glamsterdam est Hegotá.

L'Ethereum Foundation insiste sur une distinction : Hegotá ne rendra pas Ethereum entièrement post-quantique.

Son rôle est de mettre en place des fondations suffisamment solides pour que les forks suivants puissent respecter le calendrier.

Frame Transactions fait partie de ces fondations côté exécution.

La Fondation veut également commencer à retirer certaines credentials BLS encore liées à des primitives vulnérables.

I* doit enregistrer les clés post-quantiques

Après Hegotá, la feuille de route utilise pour l'instant des noms temporaires comme I*, J*, K* et L*.

I* doit introduire un registre permettant aux validateurs d'enregistrer une clé publique post-quantique en parallèle de leurs clés existantes.

L'idée est de préparer la migration avant de rendre immédiatement obligatoire la nouvelle cryptographie.

Un réseau de cette taille ne peut pas remplacer des centaines de milliers de validateurs en une seule opération.

J* doit fournir un Ethereum « minimum viable post-quantum »

Le fork J* joue un rôle particulier dans la stratégie publiée en septembre.

La Fondation veut y atteindre un niveau baptisé MV-PQ, pour minimum viable post-quantum.

Ce mode doit permettre à Ethereum de continuer à fonctionner si le Q-Day se produit plus tôt que prévu.

Il pourrait toutefois fonctionner avec des garanties réduites par rapport au protocole final.

La nature exacte de ces garanties dégradées reste encore en cours de recherche.

Le plan complet reste plus ambitieux que ce mode d'urgence

MV-PQ n'est pas présenté comme l'état final.

La cible de décembre 2029 reste une résistance complète des trois couches.

Cela implique notamment des attestations post-quantiques côté consensus et des mécanismes de données ne dépendant plus des primitives vulnérables actuelles.

L'ordre de certains forks K* et L* peut encore changer pour rapprocher les éléments les plus importants de la résistance quantique.

La feuille de route reste donc structurée mais pas figée.

Les signatures BLS sont particulièrement difficiles à remplacer

Le consensus Ethereum utilise BLS parce que des milliers de signatures peuvent être agrégées efficacement.

C'est une propriété extrêmement utile lorsqu'une quantité massive de validateurs vote en permanence.

Les signatures post-quantiques candidates sont généralement beaucoup plus grosses et ne possèdent pas nécessairement le même mécanisme d'agrégation.

Une substitution naïve pourrait donc augmenter énormément la quantité de données diffusées sur le réseau.

leanXMSS mise sur des signatures basées sur les fonctions de hash

Ethereum expérimente notamment leanXMSS pour ses validateurs.

XMSS appartient à une famille de signatures basées sur les fonctions de hash plutôt que sur le problème mathématique des courbes elliptiques.

Ces constructions sont considérées comme résistantes aux attaques quantiques connues lorsqu'elles utilisent des paramètres adaptés.

Le prix à payer est la taille.

La documentation Ethereum évoque des signatures de l'ordre de 3 000 octets dans certains scénarios, contre 96 octets pour une signature BLS actuelle.

leanVM doit compresser ce flot de signatures

C'est là qu'intervient leanVM.

Cette machine virtuelle minimale doit servir à prouver et agréger efficacement de nombreuses opérations cryptographiques post-quantiques.

Ethereum cherche ainsi à retrouver par la preuve cryptographique une partie de l'efficacité que BLS fournit aujourd'hui directement par son mécanisme d'agrégation.

La Fondation décrit un objectif de compression très important du volume de données nécessaire.

Sans ce type de mécanisme, remplacer BLS par des signatures beaucoup plus lourdes pourrait dégrader sévèrement la bande passante et les délais de consensus.

Plus de dix équipes clientes testent déjà l'interopérabilité

Cette recherche n'existe plus uniquement sur papier.

Des devnets post-quantiques d'interopérabilité sont organisés régulièrement.

La documentation Ethereum mentionne plus de dix équipes clientes impliquées, dont Lighthouse, Grandine, Zeam, Ream Labs et PierTwo.

leanXMSS, leanVM, leanSpec, leanSig et leanMultisig disposent également d'implémentations open source.

La Fondation a aussi créé en janvier 2026 une équipe dédiée à la sécurité post-quantique.

KZG doit lui aussi disparaître à terme

La disponibilité des données constitue un autre chantier.

Ethereum utilise des engagements KZG pour les blobs transportant notamment les données des rollups.

KZG repose lui aussi sur des hypothèses cryptographiques vulnérables à un ordinateur quantique suffisamment puissant.

La feuille de route doit donc remplacer ou encapsuler ces engagements avec des mécanismes post-quantiques.

Les solutions précises sont moins matures que le chantier des signatures de comptes.

Certains systèmes ZK sont déjà mieux placés que d'autres

Toutes les preuves zero-knowledge ne présentent pas la même exposition.

Certaines familles de SNARKs reposent sur des courbes elliptiques et devront être adaptées.

Les STARKs reposent beaucoup plus fortement sur des fonctions de hash et sont généralement considérées comme compatibles avec un objectif post-quantique.

Une partie de la migration pourra donc se produire naturellement au fur et à mesure que l'écosystème adopte de nouvelles constructions.

Le calendrier impose presque un hard fork tous les sept mois

Le point le plus agressif du plan n'est peut-être pas la cryptographie.

C'est sa cadence.

Dans la version de la Strawmap où la résistance complète se trouve cinq forks après Glamsterdam, passer de décembre 2026 à décembre 2029 représente environ 7,2 mois par fork en moyenne.

La Fondation décrit elle-même ce rythme comme très agressif.

Un seul fork prenant plusieurs mois de retard peut réduire fortement la marge disponible pour les suivants.

Les forks devront donc être développés en parallèle

La stratégie ne consiste pas à terminer Hegotá avant de commencer I*, puis terminer I* avant de travailler sur J*.

Les spécifications, prototypes, devnets et audits devront se chevaucher.

Pendant que les équipes clientes implémenteront un fork, les chercheurs devront déjà stabiliser le suivant et tester les composants des étapes plus lointaines.

Cette organisation demande davantage de cryptographes, de développeurs clients, de reviewers sécurité et de capacité de test que les cycles précédents.

Le danger d'une migration trop rapide existe aussi

Se préparer au quantique réduit un risque futur.

Modifier trop rapidement le consensus d'un réseau qui sécurise des centaines de milliards de dollars peut créer un risque immédiat beaucoup plus classique : un bug.

C'est pourquoi l'Ethereum Foundation conserve la sécurité du mainnet comme priorité P0, devant le calendrier post-quantique.

Les composants doivent toujours franchir les étapes recherche, EIP, prototype, devnet et plusieurs niveaux de validation avant leur intégration au réseau principal.

Ethereum choisit de payer le coût avant de savoir exactement quand la menace arrivera

Cette stratégie contient nécessairement une part d'incertitude.

Si un ordinateur quantique cryptographiquement pertinent n'apparaît qu'en 2040 ou 2050, Ethereum aura consacré plusieurs années d'effort à une migration très anticipée.

L'alternative est beaucoup plus dangereuse pour une blockchain.

Attendre une démonstration publique de la capacité à casser secp256k1 laisserait potentiellement trop peu de temps pour migrer les comptes, les validateurs et les mécanismes de disponibilité des données.

Les détenteurs d'ETH n'ont rien à faire aujourd'hui

Aucun nouveau portefeuille n'est obligatoire en septembre 2026.

Aucune procédure officielle ne demande de déplacer ses ETH vers une nouvelle adresse post-quantique.

Les outils nécessaires ne sont de toute façon pas encore déployés sur le réseau principal.

Lorsque des schémas résistants au quantique seront réellement utilisables, les logiciels de portefeuille devront guider les utilisateurs dans leur migration.

Le traitement des comptes abandonnés ou dont les propriétaires ne migreraient jamais reste en revanche un sujet de gouvernance ouvert.

2029 est maintenant une deadline d'ingénierie

C'est ce qui change réellement avec l'annonce du 7 septembre.

Ethereum travaillait déjà sur la cryptographie post-quantique, leanXMSS, leanVM et l'abstraction de compte.

La nouveauté est d'attacher ces travaux à une cible temporelle commune et de laisser cette cible dicter la priorité des prochains forks.

Le réseau ne sait pas quand apparaîtra une machine capable de casser ses signatures.

Il sait en revanche combien de temps il veut se donner pour ne plus en dépendre : trois ans.