Interprétation de l'article de blog de Vitalik : Explorer la possibilité d'intégrer un ZK-EVM nativement dans Ethereum
TechFlow SélectionTechFlow Sélection
Interprétation de l'article de blog de Vitalik : Explorer la possibilité d'intégrer un ZK-EVM nativement dans Ethereum
Ethereum pourrait ultérieurement ne plus considérer le ZK-EVM uniquement comme un composant supplémentaire.
Dédié à des analyses Web3 approfondiesRédaction : TechFlow
Hier, Vitalik a publié sur son blog un article intitulé « À quoi pourrait ressembler un ZK-EVM "consacré" ? », dans lequel il expose de manière systématique la faisabilité, les méthodes et les effets attendus de l'intégration d'un ZK-EVM dans Ethereum.
L'évolution future de l'EVM est souvent liée à divers récits ou changements stratégiques concernant l'infrastructure, ce qui mérite que nous lisions et étudiions attentivement cet article.
Toutefois, étant donné que cet article contient de nombreux détails techniques, la plupart des médias chinois et de la communauté se contentent d'en faire une traduction simplifiée, ce qui rend difficile la compréhension du contexte général et des idées exprimées.
Par conséquent, TechFlow propose ici une analyse de l'article afin de restituer, de façon plus accessible, la logique et les points de vue de Vitalik, offrant ainsi une référence utile aux lecteurs.
Le mot du titre suggère : consacrer le ZK-EVM comme standard officiel
Si vous ne lisez qu'une traduction directe, vous risquez de manquer certaines nuances ou expressions naturelles du contexte anglais.
Dans le titre de l'article de Vitalik, apparaît un mot anglais peu courant : « enshrined ».
Une simple recherche via GPT ou un dictionnaire anglais permet de constater que :
Le mot « enshrined » signifie originellement « consacré » ou « placé dans un lieu sacré », souvent utilisé pour indiquer que quelque chose (objet, personne, principe) acquiert un statut très élevé, comme s’il était protégé ou honoré.
Dans les textes juridiques ou religieux, « enshrine » désigne généralement l’acte d’enregistrer formellement et avec respect certains principes, droits ou croyances.
Dans le domaine technologique ou logiciel, « enshrined » signifie intégrer officiellement et de manière significative une technologie, fonction ou principe au sein d’un système, cadre ou protocole. Cela implique que cette technologie ou fonction est considérée comme fondamentale, centrale ou essentielle, et donc intégrée de façon permanente et formelle.
Ainsi, dès le titre, on peut rapidement comprendre l’intention de Vitalik :
Explorer la possibilité d’intégrer une version à preuve de connaissance nulle (ZK)de la machine virtuelle Ethereum (EVM) comme composant central ou officiel du protocole Ethereum.
Autrement dit, à l’avenir, Ethereum pourrait ne plus voir le ZK-EVM simplement comme un module complémentaire.
Le passé du ZK-EVM : un composant externe de type L2, non natif
Pour les lecteurs peu familiers avec l’EVM d’Ethereum et les solutions L2 associées, le fait que Vitalik envisage d’intégrer le ZK-EVM au réseau principal soulève naturellement une question :
Quelle était la relation entre le ZK-EVM et Ethereum auparavant ? Le ZK-EVM n’était-il pas déjà une partie « officielle » d’Ethereum ?
Faisons un rapide tour d’horizon :
-
Machine Virtuelle Ethereum (EVM) : cœur du réseau Ethereum, chargée de l’exécution des contrats intelligents. Tous les contrats exécutés sur Ethereum passent par l’EVM.
-
Preuve de connaissance nulle (ZK) : une technique cryptographique permettant à une partie (le prouveur) de démontrer à une autre (le vérificateur) qu’une affirmation est vraie sans divulguer d’autre information. Cette technologie améliore la confidentialité et la sécurité des transactions dans les blockchains.
-
Rôle du ZK-EVM : combiner les fonctions de l’EVM avec les propriétés de confidentialité des preuves ZK. Il permet de vérifier la validité des transactions tout en gardant les données confidentielles — c’est-à-dire prouver qu’une transaction respecte les règles du contrat et de la blockchain sans en révéler le contenu.
-
Relation entre le ZK-EVM et le réseau principal d’Ethereum : le ZK-EVM peut être vu comme une solution qui, tout en conservant la compatibilité avec l’EVM, introduit les preuves ZK pour garantir la confidentialité des transactions. Dès le départ, le ZK-EVM est surtout apparu comme une solution de deuxième couche (Layer 2), construite au-dessus du réseau principal, apportant des fonctionnalités supplémentaires en termes de confidentialité et de scalabilité.
Ainsi, la majorité des ZK-EVM actuels existent sous forme de L2, et non comme une partie intégrante du design initial d’Ethereum L1. En langage simple, ce sont des modules externes.
Les solutions ZK-EVM bien connues incluent Starknet, zkSync, Polygon Hermez et Scroll, entre autres.
Avec ces connaissances préalables, la lecture du blog de Vitalik devient beaucoup plus claire.
Pourquoi intégrer un ZK-EVM natif dans Ethereum ?
Suivant cette logique, on peut se demander : si les solutions L2 ZK-EVM fonctionnent bien, pourquoi Vitalik envisage-t-il d’intégrer directement le ZK-EVM dans la conception centrale d’Ethereum ?
Vitalik répond de manière concise :
-
Dépendance à de grandes bases de code : les solutions actuelles de Layer 2, comme les Rollups optimistes et les ZK Rollups, dépendent de la vérification EVM. Cela signifie qu’elles doivent faire confiance à une vaste base de code. Si celle-ci comporte des vulnérabilités, ces machines virtuelles (VMs) pourraient être exposées à des attaques.
-
Problèmes de gouvernance : même les ZK-EVM souhaitant rester parfaitement équivalents à l’EVM L1 ont besoin d’un mécanisme de gouvernance pour refléter les modifications de l’EVM L1 dans leur propre implémentation. Cela ajoute de la complexité et un risque d’incohérence.
-
Duplication des fonctionnalités : les projets L2 dupliquent des fonctionnalités déjà présentes dans le protocole Ethereum. La gouvernance d’Ethereum gère déjà les mises à jour et corrections de bogues. Le travail effectué par le ZK-EVM est fondamentalement similaire à la validation des blocs L1 d’Ethereum.
-
Évolution future des clients légers : les clients légers deviennent de plus en plus puissants et seront bientôt capables d’utiliser des ZK-SNARKs pour valider entièrement l’exécution L1 EVM. Le réseau Ethereum aura alors, en effet, un ZK-EVM intégré. Cela pose la question suivante : Pourquoi ne pas offrir ce ZK-EVM natif également aux rollups ?
En explorant ces problèmes, Vitalik clarifie la motivation derrière l’intégration du ZK-EVM dans la conception centrale d’Ethereum : résoudre les risques liés à la dépendance à des codes externes, simplifier la gouvernance, réduire la duplication des fonctionnalités et tirer parti des capacités inhérentes au réseau Ethereum.
À quoi devrait ressembler un ZK-EVM intégré ?
Alors, si Ethereum intègre un ZK-EVM, quelles fonctionnalités et caractéristiques devrait-il avoir ? Vitalik propose les axes suivants :
-
Fonction de base : le rôle central du ZK-EVM est de vérifier les blocs Ethereum. Il doit pouvoir prendre en entrée une racine d’état initial (pre-state root), un bloc et une racine d’état final (post-state root), puis vérifier que cette dernière résulte bien de l’exécution du bloc.
-
Compatibilité avec la philosophie multi-clients d’Ethereum : le ZK-EVM devrait éviter d’adopter un seul système de preuve, permettant plutôt à différents clients d’utiliser leurs propres systèmes. Cela implique des exigences en matière de disponibilité des données, ainsi que la séparation des preuves par rapport à la structure des données EVM et des blocs.
-
Auditabilité : si une exécution est prouvée, les données sous-jacentes doivent être disponibles, permettant aux utilisateurs et développeurs de les consulter en cas de problème.
-
Capacité d’évolution : si une vulnérabilité est découverte dans une implémentation donnée du ZK-EVM, elle doit pouvoir être corrigée rapidement, sans nécessiter un hard fork.
-
Prise en charge des EVM quasi identiques (almost-EVMs) : le ZK-EVM devrait permettre l’innovation au niveau de l’exécution et l’extension de l’EVM. Si une VM L2 diffère légèrement de l’EVM, elle pourrait toujours utiliser le ZK-EVM natif pour la partie commune, et n’avoir recours à son propre code que pour les parties différentes.
Notez que certains lecteurs peuvent ne pas connaître le terme almost-EVMs. En réalité, Vitalik a déjà mentionné précédemment que certaines solutions ZK-EVM n’ont pas besoin de reproduire exactement l’EVM, mais peuvent être « proches » de l’EVM d’origine.
Dans le cadre proposé par Vitalik, la prise en charge des almost-EVMs signifie que le ZK-EVM peut s’adapter plus souplement à divers besoins et scénarios. Cela lui permet de servir à la fois les applications strictement conformes à l’EVM et les systèmes désirant apporter de légères modifications.
Comment un ZK-EVM intégré fonctionnerait-il sur différents clients Ethereum ?
En continuant la lecture, on peut facilement se perdre : pourquoi parler soudainement des clients ?
En reprenant le fil, on voit que la logique de Vitalik est claire :
« Je veux que le ZK-EVM devienne un composant intégré — Pourquoi ? — Quelles fonctions devrait-il remplir ? »
La question suivante devient donc : Concrètement, comment cela fonctionnerait-il sur les différents clients ?
Vitalik propose deux directions : un système ouvert ou un système fermé à plusieurs clients.
-
Système ouvert : plus conforme à l’esprit de décentralisation et d’innovation d’Ethereum, permettant à la communauté de développer et d’adopter librement de nouvelles technologies de preuve.
-
Système fermé : potentiellement plus facile à gérer, mais risquant de limiter l’adaptabilité et l’innovation à long terme.
De plus, Vitalik insiste sur l’importance de la rapidité de génération des preuves : un ZK-EVM rapide serait mieux adapté à l’intégration dans le protocole principal, car il répondrait mieux aux exigences de performance du réseau et aux attentes des utilisateurs.
Cependant, atteindre cet objectif nécessite de relever d’importants défis techniques et ingénieries. Vitalik identifie clairement ces obstacles et propose des pistes de solutions.
Comment implémenter concrètement un ZK-EVM sur Ethereum ?
Vitalik présente également des voies possibles d’implémentation du ZK-EVM.
Il propose un nouveau type de transaction — la transaction de déclaration ZK-EVM (ZKEVMClaimTransaction) — et explique comment celles-ci seraient traitées et vérifiées sur le réseau Ethereum.
Cette section étant très technique, les lecteurs sans base solide peuvent passer directement à l’essentiel :
-
Introduction d’un type de conteneur pour transmettre les déclarations liées au ZK-EVM dans le réseau.
-
Au niveau de la couche consensus, mise en place d’une nouvelle règle : un bloc n’est accepté que si chaque déclaration inclut une preuve valide.
-
Les utilisateurs peuvent remplacer leur client d’exécution dans la preuve ZK-EVM, mais celui-ci reste utilisé pour générer les preuves, construire les blocs, et stocker/indexer les données.
-
Différentes implémentations du ZK-EVM peuvent utiliser des méthodes de preuve variées, mais toutes doivent pouvoir se vérifier mutuellement.
En outre, Vitalik aborde la prise en charge des « almost-EVMs », un objectif souhaité pour le ZK-EVM.
Ces systèmes intègrent des fonctionnalités supplémentaires, telles que de nouveaux contrats précompilés, opcodes, options d’écriture de contrats (choix entre EVM standard ou machine virtuelle différente, comme Arbitrum Stylus), voire plusieurs EVM parallèles avec communication synchronisée.
Vitalik discute aussi de la prise en charge des vérificateurs avec état (stateful) dans le ZK-EVM, et des avantages de cette approche :
Pourquoi prendre en charge les vérificateurs avec état ?
-
Efficacité des données : les vérificateurs avec état améliorent la compression. Un système totalement sans état nécessite que toutes les données soient disponibles à chaque transaction, entraînant redondance et gaspillage. Les vérificateurs avec état conservent les informations d’état antérieures, réduisant ainsi les volumes à transmettre.
-
Réduction de la redondance : si un fragment de données a déjà été fourni par un bloc ou une transaction antérieure, il n’a pas besoin d’être répété dans les preuves ultérieures, car il est déjà « connu ».
-
Performance du système : les systèmes avec état permettent des calculs et vérifications plus efficaces, en s’appuyant sur des informations déjà connues plutôt que de repartir de zéro à chaque fois.
Quant à la mise en œuvre, les détails techniques sont trop nombreux pour être analysés ici. Retenons simplement que :
« Prendre en charge les vérificateurs avec état » signifie introduire dans le ZK-EVM un mécanisme qui permet au système de mémoriser et d’utiliser les états antérieurs, plutôt que d’être totalement sans état à chaque opération. Cela améliore les performances globales, réduit les transmissions de données et permet des calculs plus efficaces. Il s’agit d’une extension de conception visant à accroître la viabilité et l’efficacité du ZK-EVM dans des applications réelles.
Que deviennent les autres L2 qui font des choses similaires si le ZK-EVM est intégré ?
À la fin de l’article, Vitalik s’éloigne légèrement du ton technique pour réfléchir à une autre question : si le ZK-EVM devient une fonctionnalité intégrée à Ethereum L1, quel sera le rôle des autres L2 spécialisés dans le ZK ?
Selon la vision de Vitalik, si cela se réalise, les L2 auront davantage un rôle « d’appoint », en complément sur plusieurs aspects :
-
Pré-confirmation rapide : la finalité en un seul créneau (single-slot finality) pourrait ralentir le traitement sur Layer 1, tandis que les projets L2 peuvent offrir des services de pré-confirmation rapides, soutenus par leurs propres mécanismes de sécurité, avec des délais bien inférieurs à un créneau. Ce service restera une responsabilité exclusive des L2.
-
Mitigation de la valeur extractible minimale (MEV) : cela pourrait inclure des mempools chiffrés, des sélecteurs d’ordre basés sur la réputation, ou d’autres fonctions que L1 hésiterait à adopter. Les L2 peuvent mettre en œuvre ces stratégies pour réduire l’impact du MEV sur les transactions des utilisateurs.
-
Extensions de l’EVM : les projets L2 peuvent introduire des extensions importantes de l’EVM, apportant une valeur significative à leurs utilisateurs. Cela inclut des versions « quasi-EVM » ou des approches radicalement différentes, comme Arbitrum Stylus (support WASM) ou le langage Cairo (SNARK-friendly).
-
Facilité pour utilisateurs et développeurs : les équipes L2 travaillent activement à attirer les utilisateurs et projets dans leur écosystème, en les rendant bienvenus ; elles sont rémunérées via la capture du MEV et des frais de congestion. Même si le ZK-EVM est intégré au protocole Ethereum, ce modèle subsistera.
Notez que, pour l’instant, il ne s’agit que des idées personnelles de Vitalik, non encore mises en œuvre.
Mais cet article montre que Vitalik a réfléchi en profondeur à la motivation, la méthode, les fonctionnalités et les impacts collatéraux d’un ZK-EVM natif — ce n’est donc pas une idée improvisée.
De l’EVM classique, à une EVM plus performante, puis à une EVM intégrant le ZK, Vitalik, en tant que concepteur d’Ethereum, perfectionne progressivement son œuvre par étapes.
Bien sûr, il n’a jamais rejeté les idées des autres solutions L2, mais il n’a jamais renoncé non plus à améliorer Ethereum de manière native.
Quant à savoir si cette vision d’un ZK-EVM natif sera vraiment adoptée, il faudra attendre que ces idées se transforment en propositions concrètes pour en juger.
Mais une chose est sûre : quand l’innovation technologique arrive, tout l’écosystème sera bouleversé.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
深潮TechFlow
