Sous la vague Rollup, la machine virtuelle a encore une histoire à raconter
TechFlow SélectionTechFlow Sélection
Sous la vague Rollup, la machine virtuelle a encore une histoire à raconter
L'écosystème utilisateur immense de l'EVM détermine que toute blockchain qui y renonce aura du mal à rivaliser avec elle à court terme.
Dédié à des analyses Web3 approfondiesRédaction : PSE Trading Analyst @cryptohawk
TL;DR
1. Une machine virtuelle (VM) est un système informatique simulé par logiciel, fournissant un environnement d'exécution pour les programmes. Elle peut simuler divers périphériques matériels, permettant aux programmes de s'exécuter dans un environnement contrôlé et compatible.
2. La Machine Virtuelle Ethereum (EVM) est une VM basée sur une pile utilisée pour exécuter des contrats intelligents sur Ethereum ; zkEVM apporte des optimisations d'efficacité dans la génération de preuves zk tout en maintenant l'équivalence ou compatibilité avec EVM ;
zkVM, quant à lui, abandonne l’équivalence / compatibilité avec EVM afin de privilégier la compatibilité avec les preuves zk ;
Un privacy zkVM ajoute aux capacités du zkVM des fonctionnalités natives de confidentialité ;
SVM, FuelVM et MoveVM partagent une conception axée sur l’exécution parallèle pour maximiser les performances, mais présentent chacun des spécificités techniques distinctes ;
ESC VM et BitVM expérimentent de manière innovante au niveau de la couche de calcul respectivement sur ETH et BTC, mais leur besoin réel de déploiement reste faible dans le contexte actuel.
3. L’immense écosystème utilisateur d’EVM fait qu’à court terme, toute blockchain y renonçant peine à rivaliser. Ainsi, pour les écosystèmes non-EVM, attirer les utilisateurs EVM via des outils tels que des transpileurs, compilateurs, interpréteurs de bytecode ou encore des couches de compatibilité VM, puis tirer parti des caractéristiques propres à leur VM pour construire une nouvelle narration écologique, semble être une voie incontournable vers le succès.
1.1 Qu’est-ce qu’une VM ?
La machine virtuelle (VM) est un composant fondamental de la virtualisation des ressources informatiques, offrant presque toutes les fonctions d’un ordinateur, notamment l’exécution d’applications et de systèmes d’exploitation. Ce concept n’est pas nouveau et cette technologie est largement utilisée dans de nombreux écosystèmes technologiques.
Dans le contexte de la blockchain, une machine virtuelle (VM) est un logiciel qui exécute des programmes, souvent appelé environnement d’exécution responsable de l’exécution des contrats intelligents. La VM fournit un environnement informatique virtuel en simulant différents dispositifs matériels. Bien que les dispositifs simulés puissent varier selon les VM, ils incluent généralement le processeur (CPU), la mémoire, le disque dur et l’interface réseau. Lorsqu’une transaction est soumise sur la chaîne, la VM traite cette transaction et met à jour l’état de la blockchain affecté par son exécution (l’état global courant du réseau). Les règles précises modifiant l’état du réseau sont définies par la VM. Pendant le traitement d’une transaction, la VM convertit le code du contrat intelligent en un format exécutable par le matériel des nœuds/validateurs.
Le noyau central le plus important d’une VM est LLVM (low-level virtual machine), qui peut être considéré comme le cœur même du compilateur. L’image ci-dessous illustre le fonctionnement initial de l’EVM : le contrat intelligent est converti via un code intermédiaire LLVM IR en Bytecode. Ce Bytecode est stocké sur la blockchain. Lorsque le contrat intelligent est invoqué, le Bytecode est transformé en Opcode correspondant, puis exécuté par l’EVM et le matériel des nœuds.
1.2 Les principales VM
1.2.1 EVM —— Parmi les VM de la blockchain, EVM domine à elle seule huit parts sur dix, les autres se partageant les deux restantes
Projets représentatifs : Optimism, Arbitrum
Étant donné qu'Ethereum possède actuellement l'écosystème blockchain le plus actif en termes de développeurs et d'utilisateurs, la Machine Virtuelle Ethereum (EVM) est une machine virtuelle basée sur une pile. Elle fournit un environnement informatique virtuel en simulant des composants matériels tels que le CPU, la mémoire, le stockage et la pile, afin d'exécuter les instructions des contrats intelligents et de stocker leurs états et données. Le jeu d'instructions de l'EVM comprend divers opcodes, tels que les opérations arithmétiques, logiques, de stockage et de saut.
La mémoire et le stockage simulés par l'EVM servent à stocker les états et données des contrats intelligents. L'EVM traite la mémoire et le stockage comme deux zones distinctes et peut accéder aux états et données des contrats intelligents en lisant ou écrivant dans ces zones.
La pile simulée par l'EVM est utilisée pour stocker les opérandes et résultats des instructions. La plupart des instructions du jeu d'instructions de l'EVM sont basées sur la pile : elles lisent les opérandes depuis la pile et y empilent les résultats.
La conception de l’EVM a clairement suivi une approche ascendante : après avoir défini l’environnement matériel simulé (pile, mémoire), un jeu d’instructions assembleur (Opcode) et un bytecode ont été conçus en conséquence. Pour améliorer l’efficacité d’exécution de l’EVM, la communauté Ethereum a développé deux langages de haut niveau compilés : Solidity et Vyper. Inutile de présenter Solidity ; Vyper est un langage de haut niveau pour l’EVM conçu par Vitalik pour corriger certains défauts de Solidity, mais il n’a jamais connu une adoption significative au sein de la communauté et a progressivement disparu.
1.2.2 zkEVM —— J’ai tout : compatibilité avec l’environnement EVM + prise en charge de la génération de preuves zk pour la transition d’état global
Projets représentatifs : Taiko, Scroll, Polygon zkEVM
Lors de sa création, l’EVM n’a pas pris en compte le calcul de preuve zk, ce qui lui confère des caractéristiques incompatibles avec les circuits de preuve, notamment en ce qui concerne certains opcodes spéciaux, son architecture basée sur la pile, ses frais de stockage élevés et le coût des preuves. En revanche, zkEVM est une machine virtuelle qui exécute des contrats intelligents d'une manière compatible avec les preuves zk, permettant ainsi de vérifier plus efficacement et à moindre coût l'exécution d'un contrat EVM via une preuve zk (ou preuve de validité). Contrairement aux rollups optimistes dont la couche d’exécution peut simplement reprendre l’EVM, rendre EVM compatible avec zk constitue un défi supplémentaire pour les rollups ZK.
Les rollups ZK ne sont pas facilement compatibles avec la Machine Virtuelle Ethereum (EVM). Prouver des calculs EVM génériques dans un circuit est plus difficile et coûteux en ressources que de prouver des calculs simples (comme le transfert de jetons décrit précédemment).
Cependant, les progrès récents dans les technologies de type zéro-connaissance (zero-knowledge) ont ravivé l'intérêt pour l'idée d'encapsuler les calculs EVM dans des preuves zero-knowledge. Ces efforts visent à créer une implémentation d'EVM zero-knowledge (zkEVM) capable de valider efficacement la correction de l'exécution d'un programme.
Comme l’EVM, le zkEVM effectue des transitions d’état après l’exécution d’un calcul sur certaines entrées. La différence est que le zkEVM produit également des preuves zero-knowledge pour valider la justesse de chaque étape de l’exécution du programme. Ces preuves de validité peuvent vérifier la correction des opérations concernant l’état de la machine virtuelle (mémoire, pile, stockage) et le calcul lui-même (par exemple, l’opcode correct a-t-il été appelé et correctement exécuté ?).
L’idée est belle, mais la réalité est rude : actuellement, les rollups ont du mal à concilier compatibilité ZK et compatibilité (voire équivalence) EVM. Autrement dit, soit on copie aussi fidèlement que possible la couche d’exécution Ethereum L1, y compris le hachage, les arbres d’état, les arbres de transactions, les précompilations, etc., afin que les clients d’exécution Ethereum L1 puissent traiter directement les blocs rollup sans modification ; soit on abandonne la compatibilité EVM, on recrée de nouveaux opcodes destinés à être prouvés/vérifiés dans un circuit, permettant ainsi l’exécution de contrats intelligents.
1.2.3 zkVM —— On ne peut pas tout avoir : une machine virtuelle non-EVM orientée efficacité des preuves zk
Projets représentatifs : Starknet, Zksync, RISC ZERO
zkVM abandonne la compatibilité avec EVM, en plaçant au centre les objectifs de preuve de données et de mise à jour d’état. Il trouve un terrain d’entente entre la cryptographie et les langages de haut niveau pour fournir un cadre généralisé à diverses applications.
Starkware, pionnier dans le domaine ZK avec une solide accumulation technique, dispose d’un avantage technologique notable. C’est une architecture typiquement centrée sur ZK, ayant construit autour de cette technologie la Cairo VM et le langage Cairo. Son principal inconvénient réside dans la courbe d’apprentissage élevée de Cairo.
L’architecture de ZKsync intègre à la fois les caractéristiques de l’EVM et du ZK, fusionnant Solidity et Zinc, son propre langage de circuits, en unifiant les deux au niveau IR dans le compilateur. Son avantage principal est que le noyau du compilateur, LLVM, peut supporter plusieurs langages.
RISC Zero utilise l’architecture RISC-V pour construire un simulateur permettant aux programmeurs d’écrire des programmes pour zkVM en langages généraux comme Rust, C/C++ ou Go. Cela signifie que la logique applicative n’est plus limitée à ce qui peut être exprimé en Solidity, permettant d’écrire du code indépendant de la chaîne.
1.2.4 Privacy zkVM —— Compatibilité zk + support natif de la confidentialité : une étincelle pour relancer l’écosystème
Projets représentatifs : Aleo, Ola, Polygon Miden
En tant que registre public, toutes les transactions sur la blockchain sont publiques, ce qui signifie que les changements d'état liés aux adresses ou comptes – y compris les informations d'actifs – sont transparents. Par conséquent, au-delà des solutions de mise à l'échelle, certaines équipes de blockchain croient que la prochaine fonction clé à réaliser est la confidentialité.
Outre la prise en charge de la mise à l’échelle grâce à la compatibilité zk, Privacy zkVM permet aux développeurs d’applications de créer des dApps axées sur la confidentialité, grâce aux fonctionnalités de confidentialité intégrées à son langage de programmation. Cela ouvre la porte à de nouveaux cas d’utilisation et à de grands récits narratifs, comme résoudre complètement le problème du MEV ou garantir la propriété des données utilisateur. Bien sûr, la complexité de conception d’un Privacy zkVM nécessite des équipes techniques plus importantes pour le concrétiser, et cela pourrait prendre encore quelques années avant qu’il ne devienne opérationnel.
1.2.5 SVM —— Après la marée basse, il reste encore des braises : un environnement d’exécution poussé à l’extrême en performance
Projets représentatifs : Eclipse Mainnet, Nitro, MakerDAO Chain (peut-être)
SVM, ou Solana Virtual Machine, vise un environnement d’exécution haute performance, où les contrats intelligents sont principalement écrits en Rust. Comparé aux environnements d’exécution EVM et EOS WASM, qui sont mono-thread, SVM permet l’exécution simultanée de transactions non chevauchantes et de celles qui ne font que lire le même état, en exigeant que les transactions Solana déclarent tous les états qu’elles liront ou modifieront lors de l’exécution.
De plus, afin de permettre une validation et une diffusion rapides d’un grand nombre de blocs de transactions, le réseau Solana utilise largement l’optimisation par pipeline, une technique courante dans la conception des processeurs. Cette méthode traite un flux de données d’entrée via une série d’étapes, chacune gérée par un matériel différent. Une analogie classique est celle du lave-linge, du sèche-linge et du plieur automatique, qui lavent, sèchent et plient plusieurs lots de vêtements successivement. Le lavage doit précéder le séchage, qui précède le pliage, mais chacune de ces trois opérations est exécutée par une unité distincte.
Par ailleurs, SVM est basée sur des registres et possède un jeu d’instructions beaucoup plus petit que celui de l’EVM, ce qui facilite la preuve en environnement ZK. Pour les rollups optimistes, une conception basée sur des registres permet de configurer plus facilement des points de contrôle.
1.2.6 Fuel VM —— Buffs cumulés : une machine virtuelle parallèle dans le cadre UTXO
Projet représentatif : Fuel
Fuel VM est une amélioration inspirée des cadres techniques EVM, Solana, WASM, BTC et Cosmos. Comparée à l’EVM, elle présente les caractéristiques suivantes :
Ce qui la distingue particulièrement, c’est que Fuel, comme SVM, utilise des listes d’accès (access lists), permettant l’exécution parallèle de transactions non chevauchantes, et adopte en outre le modèle UTXO, divisé en UTXO de jetons et UTXO de contrats, améliorant ainsi davantage l’efficacité d’accès et le débit de calcul.
En outre, Fuel VM offre une expérience de développement puissante et fluide grâce à son langage spécifique Sway et à sa suite d’outils Forc. Son environnement de développement conserve les avantages des langages de contrats intelligents comme Solidity, tout en intégrant des paradigmes issus de l’écosystème d’outils Rust.
À l’avenir, Fuel VM implémentera des mises à jour du langage Sway, notamment des optimisations du compilateur en termes de taille de bytecode, le support de Sway par davantage de backends (le backend EVM est déjà en cours de développement), une abstraction plus économique, davantage d’applications migreront de Solidity/Vyper vers Sway, et des améliorations seront apportées à l’analyse de la réentrance au niveau du compilateur.
1.2.7 ESC VM —— Héritière d’Ordinal/Smartweave : une couche de calcul au-dessus d’Ethereum
Projet représentatif : Ethscriptions Protocol
ESC VM, ou Ethscriptions Virtual Machine, est une proposition de contrat intelligent formulée par le protocole Ethscriptions. Ce dernier est un protocole sur Ethereum similaire à BTC Ordinal, qui explore des alternatives peu coûteuses aux contrats intelligents et aux L2.
Ethscriptions permet aux utilisateurs, à très faible coût, de contourner le stockage et l’exécution par contrat intelligent, en réalisant des calculs dans le calldata des transactions conformément à des règles protocolaires préétablies. En termes simples, toute transaction Ethereum réussie dont le calldata respecte une norme de données valide, unique, et dont l’adresse « to » n’est pas nulle, est considérée comme la création légale d’un Ethscription, l’adresse « from » étant celle du créateur et l’adresse « to » celle du propriétaire.
Initialement, chaque Ethscription était plutôt conçu sous forme de NFT, par exemple un NFT image, où le contenu de l'image est directement inscrit en Base64 dans le calldata :
Récemment, les eths populaires sont des Ethscriptions créés selon la spécification du protocole brc-20 :
Le contrat intelligent introduit par ESC VM est appelé « contrat muet » (Dumb Contract), une sorte de contrat logique rendu public, mais qui n’interagit pas directement sur la chaîne sous forme EVM. De plus, ESC VM ajoute un format spécial « commande informatique », et les ethscriptions créées avec ce format sont reconnues par ESC VM comme interagissant avec un contrat muet, par exemple Deploy - déployer un contrat muet, Call - appeler un contrat muet.
Cette solution présente certaines limitations : premièrement, les fonctions des « contrats muets » ne sont pas payables, donc si vous souhaitez envoyer des ETH via un contrat muet, vous devez passer par un « contrat pont », qui comporte lui-même des risques d’abus de contrôle et de vol d’actifs ; deuxièmement, l’écosystème a un seuil d’entrée, car la création arbitraire de contrats muets n’est pas autorisée ; leur code doit être défini par une proposition de gouvernance du protocole Ethscriptions.
En résumé, ESC VM utilise la couche L1 d’Ethereum comme couche de stockage de données, et construit par-dessus une couche de calcul. En plaçant la logique du contrat, les appels de contrat, etc., dans le calldata des transactions Ethereum, l’état global d’ESC VM repose sur le consensus des clients ESC VM, similaire à la logique de mise en œuvre de SmartWeave d’Arweave, sauf que la couche de stockage de données de SmartWeave est Arweave.
1.2.8 Bit VM —— Une expérience de recherche intéressante : un canal d’exécution point à point au-dessus de BTC
Projet représentatif : ZeroSync
Le 9 octobre, Robin Linus, fondateur de ZeroSync, a publié un livre blanc intitulé « BitVM : Compute Anything On Bitcoin ». À strictement parler, il ne s’agit pas d’une VM, mais d’une tentative de créer un espace de calcul Turing-complet, dont les contrats sont stockés sur la blockchain Bitcoin, mais dont la logique d’exécution se déroule hors chaîne. Si l’une des parties pense que l’autre a violé le contrat, elle peut lancer un défi sur chaîne, et si l’autre partie ne peut pas répondre correctement, la première peut récupérer tous les fonds du contrat.
Son avantage réside dans le fait qu’il peut conférer à Bitcoin la complétude de Turing sans aucune modification du protocole Bitcoin, sans nouveaux opcodes, sans fork soft, et peut être appliqué immédiatement.
Ses défauts sont également évidents : premièrement, il ne prend en charge que les transactions entre deux parties (une partie prouve, l’autre vérifie) ; deuxièmement, la création d’un contrat nécessite la création d’une grande quantité de données et la signature préalable de nombreuses transactions, entraînant un coût élevé de stockage hors chaîne.
Voici une brève introduction à la logique technique :
(1) Engagement de point d’entrée
L’engagement de point d’entrée permet au prouveur de fixer la valeur d’entrée d’une porte logique à 0 ou 1. Dans cet engagement, deux valeurs de hachage H(A0) et H(A1) existent. Le prouveur doit révéler un antécédent de hachage, par exemple A0, pour fixer la valeur d’entrée à 0, ou A1 pour la fixer à 1.
(2) Engagement de porte logique
Une fois les valeurs d’entrée définies, en combinant les opcodes ET, NON, etc. de Bitcoin, on peut composer n’importe quelle porte logique dans un script Bitcoin.
(3) Engagement de circuit binaire
En combinant des centaines de millions de portes logiques en un circuit binaire, on peut atteindre la complétude de Turing. Pour engager ce circuit binaire sur le réseau Bitcoin, toutes les portes logiques doivent être placées dans les nœuds feuilles d’une adresse Taproot.
(4) Phase de défi-réponse
Engager le circuit sur chaîne ne suffit pas ; les deux parties doivent disposer d’un moyen efficace pour vérifier que le résultat du calcul du contrat est correct. Dans un scénario idéal, le contrat s’exécute hors chaîne, les deux parties coopèrent et acceptent le résultat. Mais en cas de désaccord, une phase de défi-réponse est nécessaire pour valider le calcul, et le solde du canal est alors réparti de force via un script Bitcoin.
Ainsi, BitVM est loin d’être un Rollup Bitcoin ou une L2 complète, car il ne dispose ni d’un environnement d’exécution VM complet, ni d’un état global, ni d’un langage de haut niveau permettant de publier des contrats intelligents complexes, ni ne permet à un nombre quelconque d’utilisateurs d’interagir facilement avec ces contrats. Pour illustrer simplement : BitVM est comme construire un ordinateur géant plus grand qu’une pièce, à une époque où tout le monde utilise des terminaux mobiles.
1.2.9 MoveVM —— Produit de l’héritage Web2 de Facebook
Projets représentatifs : Aptos, Sui
Move est un langage de programmation destiné à écrire des contrats intelligents sécurisés, initialement développé par Facebook pour soutenir la blockchain Diem. Après l’arrêt du projet Diem, des projets comme Aptos et Sui ont poursuivi l’utilisation du langage Move. La particularité majeure des blockchains Move est leur stockage de données global, constitué d’un arbre dont les racines sont des adresses de compte. Chaque adresse peut stocker des données de ressources et du code de modules.
Move distingue deux types de programmes : les modules et les scripts. Les modules sont des bibliothèques définissant des types structurés et des fonctions opérant sur ces types. Les types structurés définissent le schéma de stockage global de Move, tandis que les fonctions des modules définissent les règles de mise à jour du stockage. Les modules eux-mêmes sont également stockés dans le stockage global. Les scripts, quant à eux, sont des points d’entrée exécutables, similaires à la fonction main dans les langages traditionnels, et correspondent à des fragments de code temporaires non publiés dans le stockage global.
En résumé, les modules Move ressemblent à des modules de bibliothèques dynamiques chargés lors de l’exécution d’un programme système, tandis que les scripts sont comparables au programme principal. Les utilisateurs peuvent écrire leurs propres scripts pour accéder au stockage global, y compris appeler des modules, et la publication de modules ou l’exécution de scripts se fait via Move VM.
1.3 Tendances évolutives de l’écosystème
Avec l’effet de réseau aussi puissant d’EVM aujourd’hui, l’attraction des utilisateurs EVM vers les chaînes non-EVM est devenue le principal moteur de croissance pour les nouveaux projets blockchain. Cela favorisera davantage de composable Dapps et une connectivité accrue, pouvant déclencher une croissance plus rapide des utilisateurs dans les années à venir.
1.3.1 Compatibilité côté interface portefeuille
L’intégration des utilisateurs EVM vers des chaînes non-EVM a toujours été un obstacle majeur, mais la sortie récente de Metamask Snap va lever cet obstacle. Les utilisateurs EVM pourront continuer à utiliser MetaMask sans changer de portefeuille. Grâce à la contribution open source de Drift qui a réalisé une excellente implémentation de MetaMask Snap, l’expérience utilisateur sera équivalente à celle d’une interaction avec n’importe quelle chaîne EVM. Les utilisateurs du réseau principal Eclipse pourront interagir avec des applications natives dans MetaMask, ou utiliser un portefeuille natif Solana (comme Salmon).
1.3.2 Compatibilité côté backend VM
1.3.2.1 Transpileurs / Compilateurs
Projet représentatif : Warp
Warp est un transpileur Solidity-Cairo, désormais complété par l’équipe d’infrastructure renommée d’Ethereum, Nethermind. Warp peut transpiler du code Solidity en Cairo, mais le programme Cairo résultant nécessite souvent des modifications et l’ajout de fonctionnalités Cairo (comme appeler des fonctions intégrées, optimiser la mémoire, etc.) pour maximiser l’efficacité d’exécution.
1.3.2.2 Interpréteurs de bytecode / Couches de compatibilité VM
Projets représentatifs : Kakarot, Neon EVM
Kakarot est un interpréteur de bytecode EVM écrit en Cairo et déployé sur Starknet, implémenté sous forme de contrat intelligent. Il simule, sous forme de contrat Cairo, la pile, la mémoire et l’exécution de l’EVM. Comparé à la transpilation de code, Kakarot implémente opcode par opcode, ainsi que les précompilations, de l’EVM, et met en place des composants comme Account Registry et Blockhash Registry pour gérer le mappage des adresses de compte et la récupération d’informations de bloc, offrant ainsi une compatibilité plus native.
Neon EVM est une EVM fonctionnant comme un contrat intelligent, pouvant être déployée sur n’importe quelle chaîne SVM. Le réseau principal Eclipse utilise lui-même SVM comme environnement d’exécution, mais grâce à Neon EVM, il obtient une compatibilité EVM complète (support du bytecode EVM et du JSON-RPC Ethereum), avec un débit supérieur à celui d’une EVM mono-thread. De plus, chaque instance de Neon EVM possède son propre marché local des frais : il existe une limite supérieure au nombre d’unités de calcul liées aux interactions de compte de contrat dans un bloc (1/4 des unités de calcul du bloc), donc les utilisateurs ne doivent payer des frais prioritaires (priority fee) que lorsqu’ils interagissent avec des contrats très sollicités ou lorsque le bloc est saturé. En ce sens, un déploiement d’application avec son propre contrat bénéficie d’avantages proches de ceux d’une application-specific chain, réduisant ainsi les perturbations causées à l’expérience utilisateur, à la sécurité ou à la liquidité du réseau entier en cas de congestion due à une interaction intense sur un contrat spécifique.
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
@PSETrading
