Auteur original : ChandlerZ, Foresight News
Le cofondateur d’Ethereum, Vitalik Buterin, a publié le 10 août une comparaison superposée entre sa feuille de route technique 2023 et la Strawmap actuelle. Il indique que la correspondance globale est relativement élevée, mais que certaines priorités ont été rehaussées (comme la sécurité quantique), d’autres abaissées (comme le VDF, plusieurs améliorations de l’EVM), et que certaines solutions ont été remplacées par des constructions plus optimales (comme l’arbre Verkle, d’abord remplacé par un arbre binaire unifié, puis par le PBT ; le mécanisme d’expiration de l’état laissant place à de nouveaux types d’état).

La feuille de route actuelle présente plusieurs nouvelles directions totalement absentes en 2023, reflétant un changement de priorités. Cela inclut : la protection forte de la confidentialité élevée pour la première fois au rang de préoccupation primaire ; l’avancement d’un scaling radical dans un contexte post-quantique ; la simplification du protocole pour faciliter la vérification formelle (Buterin souligne que l’IA rend désormais possible une vérification formelle complète de l’ensemble du protocole) ; l’introduction des concepts de blocs et de gas futures ; l’introduction du Rollup natif (les technologies SNARK n’étaient pas assez matures auparavant) ; et l’ouverture d’un espace de conception plus large pour « l’avenir de l’EVM », le protocole pouvant à l’avenir offrir aux utilisateurs des architectures d’ensemble d’instructions non-EVM.

Trois propositions pour compléter les capacités du protocole en matière de transferts privés
La protection forte de la confidentialité est le changement le plus marquant. La feuille de route 2023 ne couvrait pas ce groupe de conceptions au niveau du protocole, tandis que la Strawmap actuelle a élevé la confidentialité L1 au rang de question protocolaire. Vitalik cite les « keyed nonces », les « recent roots », les « privacy pools » simplifiés et les « wormholes » comme solutions respectives aux problèmes de concurrence des transactions privées, de vérification des preuves, d’ensemble anonyme commun et de lien des fonds.
L’EIP-8250, soumis en avril, permet à une adresse d’envoi partagée d’utiliser plusieurs ensembles indépendants de nonces, évitant qu’une transaction en attente d’un utilisateur ne bloque les autres utilisateurs du même protocole de confidentialité. L’EIP-8272, soumis en mai, permet aux preuves de dépense privée de référencer des racines récentes de l’arbre des engagements, sans avoir à lire l’état d’application en constante évolution pendant la vérification. L’EIP-8182 propose, quant à lui, d’établir un pool de confidentialité intra-protocole pour l’ETH et les ERC-20 via un contrat système, un pool de masquage partagé et une architecture de preuve séparée. L’EIP-8250 et l’EIP-8272 sont actuellement au stade Draft, l’EIP-8182 est en Review, et aucun des trois n’a de fork d’activation déterminé.
Actuellement, chaque application de confidentialité entretient son propre pool de fonds. Les utilisateurs et la liquidité étant fragmentés, l’ensemble anonyme d’un pool individuel peut devenir trop faible. L’EIP-8182 vise à regrouper divers actifs dans un même ensemble anonyme intra-protocole et à ajouter de nouvelles méthodes de vérification via un mécanisme d’autorisation extensible, réduisant ainsi le besoin de re-fragmenter les utilisateurs lors des mises à niveau.
Les « Wormholes » correspondent à la preuve de destruction à connaissance nulle (zero-knowledge burn proof) de l’EIP-7503. Les utilisateurs transfèrent d’abord de l’ETH vers une adresse cryptographiquement impossible à dépenser, puis frappent à nouveau une quantité équivalente d’ETH en utilisant une preuve à connaissance nulle, rendant difficile la connexion sur la chaîne publique entre le transfert d’origine et la nouvelle adresse. Cette proposition est actuellement au stade Stagnant ; sa spécification et son implémentation de référence nécessitent encore des améliorations, et elle présente des risques d’erreur d’implémentation et de frappe double. L’intégration de la confidentialité comme objectif prioritaire dans la feuille de route signifie qu’Ethereum commence à transformer simultanément les comptes, la validation des transactions et les transferts de la couche de base. Le chemin vers des comptes par défaut privés nécessite encore plusieurs travaux au niveau du protocole et des portefeuilles.
La migration quantique couvre quatre domaines cryptographiques
Vitalik a rehaussé la priorité de la sécurité quantique et propose de poursuivre le scaling dans des conditions post-quantiques. Les risques se répartissent sur : la signature ECDSA utilisée par les comptes ordinaires, la signature BLS utilisée par les validateurs, l’engagement KZG utilisé pour la disponibilité des données des blobs (Blob data availability), et les systèmes de preuve à connaissance nulle utilisés par certains Rollups et applications de confidentialité. Les ordinateurs quantiques actuels ne sont pas encore capables de briser ces cryptographies, mais le remplacement des clés des comptes et des validateurs dans un réseau mondial nécessitera des années de préparation.
La dernière feuille de route énumère des orientations telles que l’agrégation de signatures leanSPHINCS et les « zkzk frames », et place le STARK récursif pour une utilisation commune aux couches d’exécution, de consensus et de données. Le STARK repose principalement sur des fonctions de hachage, ce qui lui permet d’éviter certains risques quantiques liés à la cryptographie sur courbes elliptiques, et peut également compresser de gros calculs en preuves plus faciles à vérifier. La Fondation Ethereum a déjà mis en place une équipe dédiée au post-quantique. Le calendrier actuel indique qu’une mise à niveau du protocole L1 pourrait être achevée en 2029, tandis que la migration complète de la couche d’exécution pourrait prendre encore plusieurs années, sans date de fin fixe.
Le STARK est également lié à la simplification du protocole et à la vérification formelle. L’idée d’« Extremely Lean Chain » proposée par Vitalik en juillet envisage de compresser l’état d’un validateur individuel en phase 1 à 6 octets, puis à 1 octet en phase 2, et de permettre aux validateurs de mettre à jour leurs soldes et de faire tourner leurs clés publiques quotidiennement via des preuves à connaissance nulle. Vitalik estime que les outils d’IA modernes rendent la vérification formelle complète du protocole faisable. Ici, l’IA est utilisée pour écrire et vérifier des preuves mathématiques vérifiables par machine, sans participer à la production de blocs, au vote ou aux décisions de consensus.
Le Rollup natif permet aux L2 de réutiliser la validation du mainnet, le calendrier reste ajustable
L’EIP-8079, soumis en novembre 2025, fournit déjà un projet pour le Rollup natif. Ethereum ouvrirait la fonction de transition d’état du mainnet à la couche d’exécution via une précompilation EXECUTE, permettant aux Rollups équivalents à l’EVM de réutiliser l’infrastructure de validation du L1. Les Rollups actuels doivent maintenir eux-mêmes leur système de preuve, leurs contrats de pont et leurs mécanismes de mise à niveau. La « nativisation » pourrait réduire le code de validation personnalisé et offrir la possibilité de supprimer les comités de sécurité. Dans l’EIP-8079, la preuve par transaction (proof-carrying transaction), la vérification ZK et certains éléments de conception de sécurité sont encore marqués comme « à faire », et cette EIP n’est pas non plus incluse dans les mises à niveau du mainnet déjà confirmées.
La Fondation Ethereum a précisé en mars la répartition des tâches entre L1 et L2 : les L2 souhaitant hériter au maximum de la sécurité du mainnet pourraient évoluer vers le Rollup natif, le Stage 2 et la composabilité synchrone ; les L2 offrant de la confidentialité, une efficacité dédiée à une application ou d’autres fonctionnalités différenciées continueront d’exister. L’ajustement de la feuille de route pour le Rollup natif modifie la relation de validation entre L2 et le mainnet, mais n’abolit pas la structure de scaling multi-chaînes.
La conception de l’état est également en cours de changement. Vitalik indique que l’arbre Verkle a d’abord été remplacé par un arbre binaire unifié, puis par un arbre binaire partitionné (PBT), tandis que l’expiration de l’état cède la place à de nouveaux types d’état. L’EIP-8347, soumis en juillet, propose déjà une migration hors ligne vers le PBT, mais le fork d’activation et le bloc d’ancrage ne sont pas encore déterminés. Les Blob et Gas Futures, ainsi que des ensembles d’instructions non-EVM comme le leanISA ou RISC-V, entrent également dans les discussions à long terme, les transformations plus profondes de l’EVM n’étant pas encore assez matures pour être inscrites dans la Strawmap.
La Strawmap esquisse temporairement sept mises à niveau potentielles jusqu’en 2029, organisées selon un rythme de fork d’environ six mois. La Fondation Ethereum a révélé en mai que les développeurs principaux considèrent déjà que l’annotation d’années spécifiques pour chaque fork post-2026 est trop précise, et qu’elle pourrait être atténuée par la suite.
Conclusion
Cette mise à jour de Vitalik présente de manière concentrée les changements de priorités techniques d’Ethereum. La confidentialité, la sécurité post-quantique et la vérification formelle entrent dans la conception du protocole de base, tandis que le Rollup natif et les nouveaux types d’état font progresser les discussions sur le scaling vers les mécanismes de validation et la structure de l’état. De nombreuses propositions sont encore au stade Draft, Review ou de recherche précoce. La Strawmap fournit des dépendances et des orientations à long terme, et ne peut être considérée comme un engagement direct de déploiement.
Il reste à voir quelles EIP pourront entrer dans des hard forks spécifiques, si les schémas de migration des comptes et validateurs post-quantiques pourront former des spécifications complètes, et si la conception de la preuve par transaction et de la vérification ZK pour le Rollup natif pourra être finalisée. Les points d’observation à court terme restent Glamsterdam au quatrième trimestre 2026, et Hegotá en 2027, dont l’étendue des propositions est encore en cours de détermination.







