Rénovation majeure d'Ethereum 2026 : cette fois, abandonnez le « progressisme »

Écrit par : Chloe, ChainCatcher

Au cours des deux dernières semaines, Vitalik Buterin, le fondateur d’Ethereum, a publié de nombreux articles techniques approfondis sur X, couvrant les 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, ainsi que le développement accéléré par l’IA. Ces publications sont qualifiées par certains de « Plan de refonte majeure d’Ethereum 2026 ». Derrière cette série de publications se trouve le cadre esquissé par la Fondation Ethereum, appelé Strawmap, un plan visant à porter le débit de l’Ethereum L1 à 10 000 TPS d’ici 2029.

Cependant, l’ambition de cette feuille de route soulève également des doutes quant à sa capacité de réalisation, car l’histoire montre que le rythme de livraison d’Ethereum a toujours été plus lent que prévu. La question est donc : Ethereum est-il réellement prêt à abandonner le « gradualisme » pour une reconstruction plus 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. Ce plan fixe cinq grands objectifs « Polaris » : performance ultra-rapide du L1, débit de gigas, expansion du L2 en teragas, 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 7 forks, avec une mise à jour tous les 6 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 dernières semaines plusieurs articles techniques pour décomposer les dimensions clés de cette feuille de route.

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

Les arguments de Vitalik montrent qu’à la différence des stratégies passées, centrées sur le L2 Rollup et le L1 léger, la vision actuelle vise à maintenir une orientation à long terme tout en augmentant considérablement la capacité d’expansion du L1 à court terme.

1. Progression à court terme : Mise à jour Glamsterdam

Dans cette phase, la mise à jour Glamsterdam introduira les « Block-Level Access Lists (BALs) » pour supporter la validation parallèle, brisant le goulot d’étranglement de l’efficacité basé sur le traitement séquentiel, tout en avançant sur la séparation native entre proposeurs et constructeurs (Enshrined Proposer-Builder Separation, ePBS), optimisant l’utilisation des slots de 12 secondes.

2. Progression à long terme : Évolution de ZK-EVM et Blob

Le développement à long terme repose sur deux piliers : 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 », où un bloc doit être validé par au moins trois des cinq systèmes de preuve.

Concernant Blob, PeerDAS (échantillonnage de disponibilité des données) continuera d’évoluer pour atteindre 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 ainsi le débit tout en réduisant les exigences matérielles. Par ailleurs, pour répondre à la demande de grande échelle future, le réseau principal 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 voie d’expansion 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 d’efficacité de la preuve d’Ethereum proviennent d’une architecture obsolète. Selon l’EIP-7864, le passage de l’actuel « arbre d’états Keccak en hexadécimal » à un « arbre d’états binaire » pourrait réduire la longueur des branches par un facteur de 4. Cette transformation apportera une amélioration significative de l’efficacité des données :

• Bande passante : réduction d’environ 4 fois des coûts, un saut qualitatif pour des clients légers comme Helios.
• Vitesse de preuve : avec BLAKE3, accélération d’environ 3 fois ; avec Poseidon, jusqu’à 100 fois.
• Optimisation de l’accès : la conception de « pages » de stockage (64–256 slots) permet aux DApps d’économiser plus de 10 000 Gas par transaction lors de la lecture/écriture de données adjacentes.

Une proposition encore plus ambitieuse concerne la migration de la machine virtuelle (VM). Actuellement, la plupart des ZK proviennent de RISC-V ; si l’EVM pouvait fonctionner directement sur RISC-V, cela éliminerait la double traduction entre VM, améliorant considérablement la vérifiabilité du système. 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 de nouveaux contrats sur cette VM.
3. Finalement, réécrire l’EVM en tant que contrat intelligent fonctionnant sur cette nouvelle VM.

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

Feuille de route contre la menace quantique : combler les vulnérabilités techniques 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’élaboration : Vitalik propose un « consensus allégé » (Lean consensus), utilisant des signatures basées sur le hash (Hash-based), combinées à STARKs pour la compression, afin de résister aux attaques quantiques. Il précise qu’avant la mise en œuvre complète de ce « consensus allégé », une version « chaîne allégée » sera déployée, traitant seulement 256 à 1024 signatures par slot, sans nécessiter encore l’agrégation STARK, ce qui réduit considérablement la complexité.

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

Pour la disponibilité des données, Vitalik suggère de remplacer la « promesse KZG » par des STARKs résistants aux attaques quantiques. Deux compromis majeurs existent :

• Les STARKs ne possèdent pas la propriété linéaire de KZG, rendant difficile le support d’un échantillonnage efficace en 2D. Ethereum privilégie donc une approche conservatrice avec DAS 1D (comme PeerDAS), pour assurer la robustesse plutôt que la scalabilité maximale.
• La taille des preuves STARK étant grande, leur utilisation nécessite des preuves récursives complexes, ce qui complique la gestion de preuves plus volumineuses que les données elles-mêmes. Vitalik estime qu’en simplifiant les objectifs techniques et en adoptant une approche par étapes, cette voie est réalisable, mais demande un effort d’ingénierie considérable.

3. Comptes externes (EOA) : signatures ECDSA

Concernant la protection des comptes externes, la faiblesse de l’ECDSA face aux ordinateurs quantiques est critique. Vitalik propose d’intégrer une abstraction native des comptes (native AA), permettant aux utilisateurs de changer de schéma de signature résistante aux attaques quantiques sans abandonner leur adresse actuelle.

4. Couche applicative : preuves ZK basées sur KZG ou Groth16

Enfin, au niveau applicatif, le défi principal 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 suggère d’introduire dans l’EIP-8141 un « cadre de validation » (Validation Frame), permettant d’agréger hors chaîne de nombreuses signatures et preuves complexes.

Grâce à la récursivité, la vérification initiale de plusieurs centaines de Mo de données peut être compressée en une seule 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. Ainsi, même face à la menace quantique, les utilisateurs pourront continuer à exploiter efficacement et à faible coût diverses applications décentralisées.

L’IA comme accélérateur : réalisation du roadmap Ethereum 2030 en quelques semaines

Au-delà des améliorations 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ù un développeur a construit un prototype de roadmap Ethereum 2030 en deux semaines via du « vibe-coding », commentant : « Il y a six mois, cela semblait impossible, aujourd’hui c’est une tendance. »

Il a lui-même testé cette approche, utilisant un modèle GPT-OSS 20B sur un ordinateur portable, pour générer en une heure le backend d’un blog ; avec un modèle plus puissant comme Kimi-2.5, il prévoit même de tout réaliser en une seule fois. L’IA ne se contente pas d’accélérer la productivité de façon non linéaire, elle change la cadence de livraison de la roadmap Ethereum.

Il propose de partager les bénéfices de l’IA « moitié pour la vitesse, moitié pour la sécurité », en générant massivement des cas de test, en vérifiant formellement les modules critiques, et en créant plusieurs implémentations indépendantes pour croiser les résultats. Selon lui, dans un avenir proche, il sera impossible d’échanger une seule invite (prompt) contre un code sécurisé, mais ce processus pourra être multiplié par cinq.

Enfin, il envisage que la roadmap Ethereum sera achevée plus rapidement 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 une réalité », une déclaration qui, il y a cinq ans, aurait été inimaginable dans le contexte du développement Ethereum.

Rythme de livraison lent et défis concrets

Cependant, dévoiler autant de contenus techniques complexes au public implique que la feuille de route d’Ethereum doit toujours faire face à la possibilité de ne pas respecter ses promesses.

Historiquement, le rythme de livraison d’Ethereum a toujours été plus lent que prévu. La transition The Merge, initialement prévue pour la fin 2020, a été repoussée à septembre 2022 ; la mise en œuvre de l’EIP-4844 (Proto-Danksharding) a également pris plusieurs années. Ces retards sont généralement dus à des audits de sécurité, la coordination entre multiples 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é impulsée par l’IA obligent Ethereum à abandonner le « gradualisme » ; à ce tournant historique, les petites itérations progressives ne suffisent plus pour réaliser la vision de devenir la couche de règlement mondiale.

Vitalik a récemment souligné que cette transformation ne concerne pas seulement la technique, mais aussi la mentalité. Il appelle la communauté à abandonner la dépendance aux chemins traditionnels, en défendant les principes fondamentaux d’anti-censure, d’open source, de confidentialité et de sécurité (CROPS), en repensant la conception des applications depuis la première étape.

Une feuille de route technique peut exister, mais une évolution de la pensée sans calendrier précis pourrait être la étape la plus difficile pour abandonner le « gradualisme ».