Grande refonte d'Ethereum 2026 : cette fois, abandonner le « progressisme »

作者： Chloe， ChainCatcher

Pendant les deux dernières semaines, le fondateur d’Ethereum Vitalik Buterin a publié de nombreux articles techniques sur X, abordant des sujets clés tels que la scalabilité, la résistance aux attaques quantiques, l’abstraction des comptes, la reconstruction de la couche d’exécution, et l’accélération du développement par l’IA. Ces publications sont qualifiées de « Plan de refonte majeure d’Ethereum 2026 ». Derrière cette série de textes, se trouve le cadre esquissé par la feuille de route Strawmap, un document visant à porter le débit d’Ethereum L1 à 10 000 TPS d’ici 2029.

Cependant, plus la vision est ambitieuse, plus les doutes sur sa faisabilité surgissent, car historiquement, la livraison d’Ethereum a toujours été plus lente que prévu. Ethereum est-il vraiment prêt à abandonner le « gradualisme » pour une refonte radicale ?

Strawmap : Ethereum vise 10 000 TPS en 2029

Le chercheur de la Fondation Ethereum Justin Drake a publié le 25 février une esquisse de la feuille de route nommée Strawmap, qui dévoile la vision et le calendrier des futures mises à jour d’Ethereum L1. La feuille de route fixe cinq grands objectifs : performance ultra-rapide du L1, débit en gigas, scalabilité en teragas via L2, sécurité post-quantique du L1, et transferts privés natifs. L’objectif final est de traiter 10 000 transactions par seconde sur le L1 et 10 millions sur le L2.

Ce plan prévoit sept forks, avec une mise à jour tous les six mois, touchant la couche de consensus, la couche de données et la couche d’exécution. Vitalik Buterin, le créateur d’Ethereum, a exprimé son soutien, en publiant également ces deux semaines des articles techniques détaillant les axes principaux de la feuille de route.

Focus stratégique : scalabilité du L1 et reconstruction de la couche d’exécution

Selon Vitalik, contrairement aux stratégies passées axées sur les rollups L2 et le L1 léger, la vision actuelle consiste à augmenter massivement la capacité du L1 tout en maintenant une transition à long terme.

1. Court terme : mise à niveau Glamsterdam

Dans l’immédiat, la mise à jour Glamsterdam introduira des « listes d’accès au niveau des blocs (BALs) » pour permettre la validation parallèle, brisant le goulot d’étranglement de la validation séquentielle, tout en séparant le proposer et le constructeur (Enshrined Proposer-Builder Separation, ePBS), optimisant l’utilisation des slots de 12 secondes.

2. Long terme : ZK-EVM et évolution de Blob

Les deux piliers pour la scalabilité à long terme sont ZK-EVM et Blob. Sur la voie ZK-EVM, on prévoit que fin 2026, quelques validateurs adopteront en premier des clients ZK-EVM, puis en 2027, l’adoption s’étendra avec une sécurité renforcée. L’objectif ultime est d’atteindre un mécanisme de preuve multi-système « 3 sur 5 », où un bloc doit être validé par au moins trois des cinq systèmes de preuve.

Pour Blob, PeerDAS (échantillonnage de disponibilité des données) continuera d’évoluer, visant une capacité de traitement d’environ 8 MB/s. La technologie permet aux nœuds de valider en ne téléchargeant qu’un petit fragment de données, augmentant le débit tout en réduisant la barrière matérielle pour les nœuds. Par ailleurs, pour répondre à la demande de déploiement massif, le réseau principal d’Ethereum migrera vers le stockage direct des données de blocs dans Blob, remplaçant le modèle coûteux et permanent de calldata. Ce changement vise à optimiser la structure de transport des données et à redéfinir la scalabilité d’Ethereum.

3. Reconstruction de la couche d’exécution : passage à un arbre d’états binaire, remplacement de l’EVM

Vitalik souligne que 80 % des inefficacités de preuve d’Ethereum proviennent d’architectures obsolètes. Selon l’EIP-7864, le passage du « MPT d’état en hexadécimal Keccak » à un « arbre d’états binaire » pourrait réduire la longueur des branches par un facteur de 4. Cette transformation apportera des gains significatifs :

• Bande passante : réduction d’environ 4 fois, un saut qualitatif pour les clients légers comme Helios.

• Vitesse de preuve : avec BLAKE3, accélération d’environ 3 fois ; avec Poseidon, jusqu’à 100 fois.

• Optimisation d’accès : la conception de « pages » (64–256 slots) pour les stockages permet d’économiser plus de 10 000 Gas par transaction lors de lectures ou écritures de données adjacentes.

Une proposition encore plus ambitieuse concerne la migration de la machine virtuelle (VM). Actuellement, les ZK-proofs sont souvent écrits en RISC-V. Si l’EVM pouvait fonctionner directement en RISC-V, cela éliminerait la traduction entre deux VM, améliorant considérablement la vérifiabilité globale. La feuille de route prévoit trois étapes :

1. Faire en sorte que la nouvelle VM héberge les contrats précompilés existants

2. Permettre aux utilisateurs de déployer de nouveaux contrats sur cette VM

3. Finalement, réécrire l’EVM comme un contrat intelligent tournant sur la nouvelle VM

Ce processus garantit la compatibilité descendante, avec un coût de transition limité à une simple re-calibration des frais de Gas.

Feuille de route contre la menace quantique : combler les faiblesses techniques d’Ethereum

Vitalik identifie quatre vulnérabilités quantiques majeures dans Ethereum :

1. Couche de consensus : signatures BLS

Une voie de remplacement est en cours d’élaboration : Vitalik propose un « consensus allégé » utilisant des signatures basées sur le hash (Hash-based), combinées à des STARKs pour l’agrégation, afin d’assurer la résistance quantique. Avant la mise en œuvre complète, une version « allégée » de la chaîne sera déployée, traitant entre 256 et 1024 signatures par slot, sans nécessiter encore l’agrégation STARK, ce qui réduit la complexité.

2. Disponibilité des données : KZG et preuves

Pour la disponibilité des données, Vitalik suggère de remplacer la « promesse KZG » par des STARKs résistants aux attaques quantiques, mais cela implique deux compromis : l’absence de propriété linéaire dans STARKs limite la prise en charge efficace du sampling 2D, ce qui conduit Ethereum à privilégier une approche conservatrice avec DAS 1D (PeerDAS). De plus, la taille des preuves STARK étant grande, leur utilisation nécessite des techniques complexes comme la preuve récursive pour éviter que la preuve ne dépasse la taille des données. En résumé, cette voie est réalisable mais demande un effort d’ingénierie considérable.

3. Comptes externes (EOA) : signatures ECDSA

Les comptes externes, protégés par ECDSA, sont vulnérables face aux ordinateurs quantiques. Vitalik privilégie une abstraction native des comptes (native AA), permettant aux utilisateurs de changer de schéma de signature quantique sans changer d’adresse.

4. Niveau application : preuves ZK basées sur KZG ou Groth16

Au niveau applicatif, le principal défi est le coût élevé des preuves STARK résistantes aux attaques quantiques, environ 20 fois celui des SNARKs actuels, ce qui est prohibitif pour la confidentialité et les L2. Vitalik propose d’introduire un « cadre de validation (Validation Frame) » via l’EIP-8141, permettant d’agréger hors chaîne de nombreuses signatures et preuves complexes. Grâce à la preuve récursive, la vérification, initialement volumineuse, peut être compressée en une petite preuve STARK sur la chaîne, économisant de l’espace et du coût, tout en permettant une vérification immédiate dans le mempool, assurant une opération efficace face à la menace quantique.

L’IA comme accélérateur : compléter la roadmap Ethereum 2030 en quelques semaines

Au-delà des avancées techniques, Vitalik insiste sur le rôle de l’IA dans l’accélération du développement d’Ethereum. Il a partagé une expérimentation où, en deux semaines, un prototype de la roadmap 2030 a été construit via vibe-coding, commentant : « Il y a six mois, cela semblait impossible, aujourd’hui c’est une tendance. »

Il a lui-même testé avec un modèle GPT-OSS:20B sur un ordinateur portable, générant en une heure le backend d’un blog ; avec un modèle plus puissant comme kimi-2.5, il prévoit même une seule étape pour tout faire. L’IA transforme la cadence de livraison d’Ethereum, rendant la réalisation plus rapide.

Il propose de partager les bénéfices de l’IA à parts égales entre vitesse et sécurité, en générant massivement des tests, en vérifiant formellement les modules critiques, et en produisant plusieurs implémentations indépendantes pour la validation croisée. Selon lui, dans un avenir proche, il sera difficile d’obtenir un code sécurisé à partir d’un simple prompt, mais ce processus pourra être amélioré par un facteur 5.

Enfin, il évoque la possibilité qu’Ethereum termine sa roadmap plus vite que prévu, avec des standards de sécurité supérieurs aux attentes. « Un code sans bug, longtemps considéré comme une utopie, pourrait devenir réalité », dit-il. Si cette phrase était prononcée il y a cinq ans, cela aurait été impensable dans le contexte du développement d’Ethereum.

Rythme de livraison lent et défis concrets

Cependant, dévoiler autant de contenus techniques complexes soulève toujours la question de la réalisation ponctuelle de ces promesses.

Historiquement, Ethereum a toujours été plus lent que prévu. La transition The Merge, initialement prévue pour la fin 2020, n’a été achevée qu’en septembre 2022 ; la mise en œuvre de l’EIP-4844 (Proto-Danksharding) a aussi pris plusieurs années. Ces retards sont dus à des audits de sécurité, la coordination multi-clients, et la gouvernance décentralisée.

Mais cette fois, le temps presse pour Ethereum. La pression des concurrents, la menace quantique, et la révolution de productivité induite par l’IA obligent Ethereum à abandonner le « gradualisme » ; à ce tournant historique, les petites itérations passées ne suffiront plus pour réaliser la vision d’un Ethereum comme couche de règlement mondiale.

Vitalik a récemment appelé la communauté à ne pas se limiter à la technique, mais à repenser l’application en abandonnant les dépendances de trajectoire, en protégeant la résistance à la censure, l’open source, la vie privée et la sécurité (CROPS), en repartant de zéro dans la conception.

Une feuille de route technique existe, mais la véritable évolution de la mentalité, sans calendrier précis, pourrait être la étape la plus difficile pour abandonner le « gradualisme ».