La séquence proposée comprend Glamsterdam, Hegotá et les forks provisoirement nommés I* et J*, selon le récit de la présentation du responsable des outils de développement d’Ethereum, 0xRahul. Bob Summerwill, participant à la conférence, a identifié J* comme le point final post-quantique proposé.
Chargement du message de X…
Voir l’article sur X
La précédente feuille de route de l’équipe post-quantique indique que les mises à niveau du protocole L1 pourraient être achevées d’ici 2029, la migration complète de la couche d’exécution prenant des années supplémentaires. Sa séquence publiée place un registre de clés de validateur en I, des preuves consensuelles et leanVM en L.
Le point final J* proposé par Drake apporterait donc une protection à l’échelle du protocole dans un fork antérieur. Il s’agit d’un objectif, pas d’un calendrier d’activation convenu : le Strawmap se décrit comme un travail en cours plutôt que comme une prédiction, et l’équipe post-quantique affirme que les mises à niveau finales sont déterminées par les processus de gouvernance ouverts d’Ethereum.
De la feuille de route au code en cours d’exécution
Un composant clé est leanVM, une machine virtuelle génératrice de preuves minimales destinée à rendre pratiques les signatures post-quantiques plus grandes en agrégeant leur vérification. Sa base de code publique comprend des implémentations et des références pour les signatures des validateurs, les signatures des utilisateurs et la disponibilité des données.
La Fondation a déclaré que leanVM avait été « formellement vérifié de bout en bout » au cours des jours précédents. Cependant, le référentiel de code qualifie toujours la vérification formelle de « en cours » et prévient que leanVM n’est pas encore prêt pour la production. Le projet de vérification liée indique également qu’aucune revendication de système de preuve n’a été formulée et répertorie les théorèmes de bout en bout parmi ses objectifs d’assurance.
Pour les titulaires, une mise à niveau du protocole et la migration d’un compte existant restent des étapes différentes. Comme The Defiant l’a signalé précédemment, la vérification des signatures alternatives dans un contrat intelligent ne supprime pas automatiquement l’autorité de la clé de signature originale d’un compte existant.
EIP-8141, une route native proposée vers l’autorisation de transaction programmable et les signatures post-quantiques, reste étiquetée Draft. Cela permettrait au code de compte de définir la validation plutôt que d’exiger l’authentification par courbe elliptique actuelle.
