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

作者： Chloe， ChainCatcher

Depuis deux 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 par certains de « Plan de refonte majeure d’Ethereum 2026 ». Derrière cette série de textes, se trouve le cadre esquissé du Strawmap, une feuille de route visant à porter le débit de l’Ethereum L1 à 10 000 TPS d’ici 2029.

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

Strawmap : Objectif de 10 000 TPS pour Ethereum en 2029

Le 25 février, le chercheur de la Fondation Ethereum Justin Drake a publié une esquisse de feuille de route nommée Strawmap, visant à révéler la vision et le calendrier des futures mises à jour de l’Ethereum L1. La feuille de route fixe cinq grands « étoiles polaires » : 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 sur le L1. 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, fondateur d’Ethereum, a exprimé son soutien, en publiant également ces deux semaines des articles techniques détaillant les axes principaux de cette feuille de route.

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

Selon Vitalik, contrairement à la stratégie des dernières années centrée sur les rollups L2 et le L1 léger, la vision actuelle vise à augmenter massivement la capacité du L1 tout en maintenant une orientation à long terme.

1. Court terme : Mise à jour 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 avançant sur la séparation native des proposants et constructeurs (Enshrined Proposer-Builder Separation, ePBS), pour optimiser l’utilisation des slots de 12 secondes.

2. Long terme : Évolution ZK-EVM et Blob

Les deux piliers du scalabilité à long terme sont ZK-EVM et Blob. Sur la voie ZK-EVM, on prévoit qu’à la 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 multiple « 3 sur 5 » : 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’une petite partie des données, augmentant le débit tout en abaissant le seuil matériel requis. Par ailleurs, pour répondre à la demande de grande échelle, 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 stockage et à redéfinir la scalabilité d’Ethereum depuis la couche de données.

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

Vitalik souligne que 80 % des limitations de performance de la preuve proviennent d’une architecture obsolète. Selon l’EIP-7864, le passage du « MPT hexadécimal Keccak » à un « arbre d’états binaire » pourrait réduire la longueur des branches par un facteur de 4, améliorant considérablement l’efficacité des données :

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

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

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

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

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

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

3. Finalement, réécrire l’EVM en tant que 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 Gas.

Feuille de route contre les menaces quantiques : combler les faiblesses technologiques d’Ethereum

Vitalik identifie quatre vulnérabilités quantiques majeures dans l’état actuel d’Ethereum :

1. Couche de consensus : signatures BLS

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

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

Pour la disponibilité des données, Vitalik suggère de remplacer la « promesse KZG » par des STARKs résistants aux attaques quantiques, mais cela pose deux défis : l’absence de propriété linéaire dans STARKs, rendant difficile la réalisation d’échantillonnage 2D efficace, et la taille importante des preuves STARK, nécessitant des techniques comme la preuve récursive. La stratégie consiste à simplifier les objectifs techniques et à phaser l’implémentation, tout en restant réalisable.

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 anti-quantiques sans changer d’adresse.

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

Les preuves ZK résistantes aux attaques quantiques, notamment STARK, ont un coût en Gas environ 20 fois supérieur aux 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. La preuve récursive permettrait de compresser une validation de plusieurs centaines de Mo 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 ainsi une opération efficace face aux menaces quantiques.

L’IA comme accélérateur : finaliser 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 roadmap Ethereum 2030 a été construit via du « vibe-coding ». Il commente : « 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 son ordinateur portable, réalisant 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 : « moitié pour la vitesse, moitié pour la sécurité », en générant des tests massifs, 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’échanger une seule invite contre un code sécurisé, mais ce processus pourrait augmenter la sécurité 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 déclaration aurait été inconcevable il y a cinq ans, aujourd’hui, elle devient envisageable.

Rythme de livraison lent et défis concrets

Cependant, dévoiler autant de contenus techniques complexes soulève toujours la question de la capacité d’Ethereum à respecter ses promesses.

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

Mais cette fois, le temps pour Ethereum est compté. 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 de devenir la couche de règlement mondiale.

Vitalik a récemment appelé la communauté à ne pas se limiter à la technique, mais à repenser l’application en partant des principes fondamentaux : résister à la censure, ouvrir le code, garantir la confidentialité et la sécurité (CROPS). La refonte ne concerne pas seulement la technique, mais aussi la mentalité. La véritable étape difficile pour quitter le « gradualisme » pourrait être celle de la transformation de la pensée, sans calendrier précis.