📝 Salut, je suis 10, Vitalik a récemment posté un long tweet, révélant qu'Ethereum s'apprête à subir une mise à niveau véritablement de niveau moteur.

Ce n'est pas une petite réparation, ce n'est pas une optimisation des performances, mais il faut complètement reconstruire l'EVM (machine virtuelle Ethereum), voire le remplacer.

Faisons une comparaison qui n'est pas tout à fait appropriée : vous avez utilisé un iPhone pendant sept ans, le système a toujours été mis à jour, mais le processeur n'a jamais été changé. Un jour, Apple annonce soudainement qu'ils vont changer complètement l'architecture du processeur pendant que vous l'utilisez normalement, l'impact est bien sûr énorme.

👇👇👇

1. Pourquoi il est enfin temps de s'attaquer à l'EVM

Dans la communauté Ethereum, les gens ont généralement tendance à ne pas toucher à l'EVM. Face à de nouveaux besoins, beaucoup pensent d'abord à accélérer au niveau du protocole (comme les contrats précompilés), en contournant la machine virtuelle.

La raison est très concrète : l'EVM traite certaines opérations complexes lentement. Ce que Vitalik veut dire est en fait très simple : si la cuisine n'est pas assez bonne, reconstruisez-en une, il n'est pas nécessaire de toujours compter sur des aides extérieures.

Deuxièmement, la première coupe consiste à remplacer cet arbre gras.

Il a proposé deux grands changements. Le premier concerne l'arbre d'état, que vous pouvez comprendre comme l'index du livre de comptes d'Ethereum.

Vous pouvez comprendre l'arbre d'état comme l'index du livre de comptes d'Ethereum. Actuellement, il utilise un arbre à six branches, chaque nœud ayant au maximum 16 sous-nœuds, ce qui rend le chemin de recherche long et l'efficacité faible. Vitalik propose de le remplacer par un arbre binaire, avec seulement deux directions gauche et droite, ce qui rend la recherche plus rapide et la consommation de bande passante également moindre.

C'est comme passer d'un épais annuaire téléphonique à une recherche directe dans le carnet d'adresses de votre téléphone. En même temps, la fonction de hachage doit également changer : introduire Blake3 pour améliorer la stabilité, tandis que Poseidon peut augmenter l'efficacité de plusieurs dizaines de fois.

Cette proposition remplace en fait l'arbre Verkle précédent. Étant donné que la cryptographie sur laquelle repose l'arbre Verkle pourrait ne pas résister à l'informatique quantique, il a progressivement été abandonné par la communauté depuis l'année dernière. La feuille de route technologique, après tout, peut changer rapidement.

Troisièmement, la deuxième coupe transforme l'EVM en histoire.

La deuxième coupe est plus audacieuse, remplaçant l'EVM par l'architecture RISC-V. RISC-V n'avait à l'origine rien à voir avec la blockchain, mais maintenant de nombreux systèmes de preuve ZK l'utilisent.

La pensée de Vitalik est très simple : puisque RISC-V est déjà utilisé comme prouveur, pourquoi la machine virtuelle devrait-elle encore utiliser un langage différent et ajouter une traduction supplémentaire ? Enlever ce niveau de traduction augmentera naturellement l'efficacité.

Un interpréteur RISC-V n'a que quelques centaines de lignes de code, et Vitalik pense que c'est ainsi que la machine virtuelle de la blockchain devrait être.

Son plan en trois étapes :

D'abord, faire fonctionner la nouvelle machine virtuelle avec des contrats précompilés pour vérifier sa faisabilité.

Permettre aux développeurs de déployer de nouveaux contrats de machine virtuelle, l'EVM et la nouvelle machine virtuelle fonctionnant en parallèle.

L'EVM sera retiré, mais les anciens contrats pourront toujours fonctionner car l'EVM sera transformé en contrats intelligents sur la nouvelle machine virtuelle.

Les anciens utilisateurs n'ont pas besoin de changer de voiture, mais le moteur a discrètement été mis à niveau. Vitalik a calculé : l'arbre d'état et la machine virtuelle représentent plus de 80 % du goulot d'étranglement de la preuve d'Ethereum. Sans toucher à ces deux éléments, l'extension ZK sera difficile à réaliser.

Quatre, la réponse d'Arbitrum : la direction est correcte, le chemin peut encore être repensé.

L'équipe d'Arbitrum a répondu à la proposition RISC-V en novembre dernier. Ils reconnaissent l'avantage de RISC-V en matière de preuves ZK, mais estiment qu'il n'est pas adapté comme format de livraison de contrats.

Ils ont fait une analogie : un chariot élévateur est très efficace pour transporter des marchandises dans un entrepôt, mais un livreur ne peut pas livrer des colis avec un chariot élévateur, n'est-ce pas ?

Ainsi, ils suggèrent d'utiliser WASM (WebAssembly) comme couche de contrat. WASM peut s'exécuter rapidement, dispose d'un mécanisme de sécurité des types mature, et la chaîne d'outils a également été vérifiée dans un environnement de navigateur. Arbitrum a déjà réalisé un prototype avec WASM : les contrats sont livrés via WASM, puis des preuves ZK sont effectuées via RISC-V, chacun jouant son rôle sans interférer.

Ils craignent également un point : les progrès de la technologie ZK sont trop rapides, RISC-V vient juste d'entrer dans le 64 bits, que se passera-t-il si une meilleure architecture émerge dans deux ans ?

Cinq, les L2 d'Ethereum sont confrontés à un moment de sevrage.

Il y a un mois, Vitalik a remis en question la nécessité d'une feuille de route L2 distincte, suscitant une réponse collective du camp L2. Certains ont souligné que L2 était à l'origine destiné à l'extension, mais qu'Ethereum devient maintenant plus rapide, le rôle de L2 doit naturellement être ajusté.

Les L2 n'ont pas paniqué, mais ont plutôt commencé à se désolidariser d'Ethereum, certains comparant L2 à des sites indépendants, Ethereum étant la norme de règlement de base ; d'autres pensant que le vrai défi réside dans la création d'un espace de bloc unique pour des scénarios spécifiques.

Les modifications apportées par Vitalik à la couche d'exécution envoient un message : Ethereum ne se contente plus de servir de couche de règlement, mais veut reprendre le contrôle de ses capacités fondamentales. Et les L2, elles, trouvent progressivement leur position indépendante.

Six, la question est de savoir si cela peut réussir.

Vitalik admet lui-même : le remplacement de la machine virtuelle n'a pas encore formé un consensus large. Actuellement, la réforme de l'arbre d'état est relativement mature, l'EIP-7864 a déjà un projet concret, mais le remplacement de l'EVM par RISC-V en est encore au stade de la feuille de route.

Les deux prochaines étapes clés sont : la mise à niveau Glamsterdam (prévue pour le premier semestre 2026) et la mise à niveau Hegota. La réforme de l'arbre d'état et l'optimisation de la couche d'exécution sont des lignes directrices confirmées, le remplacement de la machine virtuelle ne devrait pas arriver avant 2027.

Cependant, Vitalik a une phrase particulièrement intéressante : Ethereum a déjà changé de moteur en plein vol (en référence à The Merge), et il pourrait encore en changer quatre fois. Bien que cela puisse sembler léger, réfléchissez-y - un réseau d'une valeur marchande de plusieurs centaines de milliards peut changer de mécanisme de consensus, de machine virtuelle et d'arbre d'état sans temps d'arrêt ni impact sur les utilisateurs, ce qui était inimaginable à l'époque de l'Internet traditionnel.

Sept, mes impressions.

Ethereum a fonctionné sur l'EVM pendant sept ans, et le problème d'accumulation des contrats précompilés existe depuis longtemps. Pourquoi vouloir maintenant effectuer des ajustements à grande échelle ? Je pense que c'est en raison des changements dans les exigences de l'ère ZK.

Dans le passé, Ethereum devait simplement s'assurer qu'il pouvait fonctionner sur du matériel ordinaire, tandis que maintenant, les preuves ZK exigent que chaque opération puisse générer une preuve de vérification. L'EVM n'avait pas pris en compte les preuves ZK à l'origine, de nombreuses opérations ne fonctionnent pas dans les circuits ZK, donc les contrats précompilés sont devenus une solution temporaire, mais cette solution provisoire a trop accumulé, il est temps d'opérer un changement.

L'attitude de Vitalik cette fois-ci est également plus ferme, ce n'est plus quelque chose à considérer, mais un problème à résoudre directement. Cela signifie peut-être que la communauté est parvenue à un consensus interne, et qu'il ne peut plus être retardé.

Savoir si cela réussira, nous en aurons le cœur net en 2027, mais au moins, il est certain qu'Ethereum ne veut pas rester un système de patch à l'ère ZK.

Quant à la manière concrète de procéder, cette discussion est plus précieuse que le résultat. Après tout, il n'y a pas beaucoup d'endroits où l'on peut discuter des projets futurs.