Une machine virtuelle est un système informatique émulé par logiciel qui fournit un environnement d’exécution pour un programme. Il peut émuler une variété de périphériques matériels pour permettre aux programmes de s’exécuter dans un environnement contrôlé et compatible.
La machine virtuelle Ethereum (EVM) est une machine virtuelle basée sur une pile qui exécute des contrats intelligents Ethereum ; zkEVM optimise l’efficacité de la génération à l’épreuve de zk sur l’équivalence/compatibilité EVM.
zkVM élimine l’équivalence/compatibilité EVM et augmente la priorité de la convivialité zk.
privacy zkVM superpose les fonctionnalités de confidentialité natives sur zkVM ;
SVM, FuelVM et MoveVM ont en commun de rechercher les performances ultimes grâce à l’exécution parallèle, mais ils ont leurs propres caractéristiques dans les détails de conception.
ESC VM et BitVM ont mené des expériences innovantes sur la couche de calcul sur les chaînes ETH et BTC respectivement, mais la demande de mise en œuvre réelle dans l’environnement actuel est faible.
L’énorme écosystème d’utilisateurs de l’EVM détermine qu’il sera difficile pour tout réseau blockchain qui l’abandonne de le concurrencer à court terme, de sorte que l’écosystème non-EVM introduit les utilisateurs de l’écosystème EVM par le biais de transpilateurs/compilateurs/interpréteurs de bytecode et même de couches de compatibilité VM, et utilise les fonctionnalités de la machine virtuelle non-EVM pour construire un nouveau récit écologique, ou un chemin nécessaire vers le succès.
1.1 Qu’est-ce qu’une VM ?
Une machine virtuelle (VM) est l’élément constitutif des ressources informatiques virtualisées qui a presque les mêmes fonctions qu’un ordinateur, y compris l’exécution d’applications et de systèmes d’exploitation. Le concept de machines virtuelles n’est pas nouveau, et la 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 qui exécute des contrats intelligents blockchain. Les machines virtuelles fournissent généralement un environnement informatique virtuel en émulant différents périphériques matériels. Différentes machines virtuelles peuvent émuler différents périphériques matériels, mais incluent généralement le processeur, la mémoire, les disques durs, les interfaces réseau, etc. Lorsqu’une transaction on-chain est soumise, la machine virtuelle est responsable du traitement de la transaction et de la mise à jour de l’état de la blockchain (l’état global actuel de l’ensemble du réseau) qui est affecté par l’exécution de cette transaction. Les règles spécifiques qui modifient l’état du réseau sont définies par la machine virtuelle. Lors du traitement d’une transaction, la machine virtuelle convertit le code du contrat intelligent dans un format qui peut être exécuté par le matériel du nœud/validateur.
Le noyau le plus important d’une machine virtuelle est LLVM (low-level-virtual-machine), qui peut être considéré comme le noyau le plus important du compilateur. La figure montre le schéma de fonctionnement de l’EVM d’origine, et le contrat intelligent est converti en Bytecode via le code intermédiaire de LLVM IR. Ces bytecodes sont stockés sur la blockchain, et lorsque le contrat intelligent est appelé, le bytecode est converti en l’Opcode correspondant, qui est ensuite exécuté par l’EVM et le matériel du nœud.
1.2 Machines virtuelles grand public
1.2.1 EVM - La VM blockchain a un total d’une pierre, l’EVM est exclusif à huit compartiments et le reste est divisé en deux compartiments
Projets représentatifs : Optimisme, Arbitrum
En tant qu’écosystème blockchain avec la plus grande activité de développeurs et d’utilisateurs du secteur, l’EVM de la machine virtuelle Ethereum est une machine virtuelle basée sur une pile qui fournit un environnement informatique virtuel en émulant des périphériques matériels tels que le processeur, la mémoire, la mémoire et les piles, afin d’exécuter des instructions de contrat intelligent et de stocker l’état et les données du contrat intelligent. Le jeu d’instructions de l’EVM comprend divers opcodes d’opcode, tels que les opérations arithmétiques, les opérations logiques, les opérations de stockage, les opérations de saut, etc.
La mémoire et la mémoire émulée par l’EVM sont des dispositifs utilisés pour stocker l’état et les données du contrat intelligent. L’EVM traite la mémoire et la mémoire comme deux zones distinctes qui peuvent accéder à l’état et aux données d’un contrat intelligent en lisant et en écrivant dans la mémoire et la mémoire.
La pile de simulations EVM est utilisée pour stocker les opérandes et les résultats des instructions. La plupart des instructions du jeu d’instructions de l’EVM sont basées sur une pile, elles lisent les opérandes de la pile et repoussent les résultats dans la pile.
Le processus de conception de l’EVM est évidemment ascendant, d’abord en finalisant l’environnement matériel simulé (pile, mémoire), puis en concevant son propre jeu d’instructions d’assemblage (Opcode) et bytecode (Bytecode) en fonction de l’environnement correspondant. La communauté Ethereum a conçu deux langages compilés de haut niveau - Solidity et Vyper - pour l’efficacité de l’exécution de l’EVM. Inutile de dire que Vyper est le langage EVM de haut niveau de Vitalik conçu pour remédier à certaines des failles de Solidity, mais il n’a pas reçu beaucoup d’adoption dans la communauté, il a donc progressivement disparu dans l’obscurité.
1.2.2 zkEVM - Je veux tout : compatible avec l’environnement EVM + prise en charge de la conversion racine de l’état global pour générer zk-proof
Parce que l’EVM n’est pas construit avec le calcul à l’épreuve zk, il n’est pas convivial pour les circuits de preuve, en particulier en termes d’opcodes spéciaux, d’architectures basées sur la pile, de surcharge de stockage et de coûts de preuve. zkEVM est une machine virtuelle qui exécute des contrats intelligents d’une manière compatible avec l’informatique à l’épreuve de zk, de sorte que le processus d’exécution d’EVM peut être vérifié de manière plus efficace et plus rentable grâce à zk-proof/validity-proof. Par rapport au cumul OP, la couche d’exécution n’a besoin que de copier l’EVM, et la construction conviviale de l’EVM est un défi supplémentaire pour ZK Rollup.
Les ZK-rollups ne sont pas facilement compatibles avec la machine virtuelle Ethereum (EVM). La preuve d’un calcul EVM à usage général dans un circuit est plus difficile et gourmande en ressources que la preuve d’un calcul simple tel que le transfert de jetons décrit précédemment.
Cependant, les progrès de la technologie à divulgation nulle de connaissance(s’ouvre dans un nouvel onglet) ont ravivé l’intérêt pour l’intégration du calcul EVM dans des preuves à divulgation nulle de connaissance. Ces efforts visent à créer une implémentation EVM à connaissance nulle (zkEVM) qui peut vérifier efficacement l’exactitude de l’exécution du programme.
Comme l’EVM, le zkEVM passe d’un état à l’autre après avoir effectué des calculs sur certaines entrées. La différence est que zkEVM crée également des preuves à divulgation nulle de connaissance pour vérifier l’exactitude de chaque étape de l’exécution du programme. Les preuves de validité peuvent vérifier l’exactitude des opérations impliquant l’état de la machine virtuelle (mémoire, pile, stockage) et le calcul lui-même (c’est-à-dire, l’opération a-t-elle appelé les bons opcodes et les a-t-elle exécutés correctement ?). ）。
À l’heure actuelle, il est difficile pour Rollup d’obtenir une compatibilité ZK-friendly et EVM (ou même équivalent), c’est-à-dire de répliquer la couche d’exécution Ethereum L1 aussi complètement que possible, y compris les hachages, les arbres d’état, les arbres de transaction, la précompilation, etc., afin que le client d’exécution Ethereum L1 puisse l’utiliser tel quel pour traiter les blocs Rollup ; Soit abandonner la compatibilité EVM et recréer l’Opcode existant pour la preuve/vérification dans le circuit, permettant l’exécution de contrats intelligents.
1.2.3 zkVM - Vous ne pouvez pas l’avoir dans les deux sens : des machines virtuelles non evm orientées vers l’efficacité à l’épreuve de zk
Projets représentatifs : Starknet, Zksync, RISC ZERO
Plutôt que la compatibilité EVM, zkVM a trouvé un diviseur commun entre la cryptographie et les langages de haut niveau avec les preuves de données et les mises à jour d’état comme objectifs principaux, fournissant un cadre commun pour un large éventail d’applications.
Starkware dispose d’un certain leadership technologique en raison de son démarrage précoce dans l’ensemble du domaine ZK et de son accumulation technologique relativement suffisante. Il est l’architecture technique représentative centrée sur ZK autour de laquelle Cairo VM et le langage du Caire sont construits. L’inconvénient est que le Caire est plus cher à apprendre.
Le framework de ZKsync est compatible à la fois avec EVM et ZK, et intègre Solidity avec son langage de circuit développé par ses soins, Zinc, unifiant les deux au niveau IR au sein du compilateur. L’avantage est que le LLVM du noyau du compilateur est compatible avec plusieurs langages.
RISC Zero utilise l’architecture RISC-V pour construire des simulateurs qui permettent aux programmeurs d’écrire des programmes pour zkVM dans des langages à usage général tels que Rust, C/C++ et Go, ce qui signifie que la logique d’application n’a pas besoin d’être limitée à ce qui peut être exprimé dans Solidity, ce qui permet d’écrire du code indépendant de la chaîne.
1.2.4 Confidentialité zkVM - zk-friendly + prise en charge native de la confidentialité, essayant d’allumer une nouvelle étincelle dans l’écosystème
Projets représentatifs : Aleo, Ola, Polygon Miden
La blockchain est un système de registre public où toutes les transactions sont effectuées sur la chaîne, ce qui signifie que les changements d’état contenant des informations sur les actifs liés aux adresses ou aux comptes sont ouverts et transparents. Par conséquent, en plus de travailler sur des solutions de mise à l’échelle, certaines équipes blockchain estiment que la prochaine fonctionnalité clé à mettre en œuvre est la confidentialité.
En plus de la prise en charge de la mise à l’échelle conviviale par zk, Privacy zkVM permet à ses développeurs d’applications de couche supérieure d’ouvrir des dapps liées à la confidentialité grâce aux fonctionnalités de confidentialité nativement prises en charge par son propre langage de programmation, ce qui apportera de nouveaux scénarios d’application et de grands récits, tels que la résolution complète du problème MEV et la garantie de la propriété des données des utilisateurs. Bien sûr, la complexité de la conception de Privacy zkVM nécessitera une équipe technique beaucoup plus importante pour la mettre en œuvre, et cela peut prendre plusieurs années à réaliser.
1.2.5 SVM - Après la marée descendante, il y a encore des braises : un environnement d’exécution qui a été conçu à l’extrême de la performance
SVM, ou Solana Virtual Machine, se concentre sur un environnement d’exécution haute performance, et les contrats intelligents sont principalement écrits en Rust. Contrairement aux environnements d’exécution EVM et EOS WASM à un seul thread, les SVM permettent des transactions qui ne se chevauchent pas et l’exécution simultanée de transactions qui ne lisent que le même état en exigeant que les transactions Solana décrivent tous les états qui leur seront lus ou écrits au moment de l’exécution.
De plus, afin de vérifier/diffuser rapidement un grand nombre de blocs de transactions, le processus de vérification des transactions sur le réseau Solana fait un usage intensif des optimisations de pipeline qui sont courantes dans la conception de processeurs. Pour répondre à la situation où une série d’étapes traitent le flux de données d’entrée, et chaque étape a une responsabilité matérielle différente. Une analogie typique est celle d’une laveuse et d’une sécheuse, qui lavent/sèche/plient plusieurs lots de linge en séquence. Le lavage doit être effectué avant le séchage, et le pliage doit être effectué avant le séchage, mais chacune de ces trois opérations est effectuée par une unité séparée.
De plus, les SVM sont basées sur des registres et ont un jeu d’instructions beaucoup plus petit que les EVM, ce qui rend l’exécution des SVM plus facile à prouver dans ZK. Pour les cumuls optimistes, les conceptions basées sur les registres facilitent la définition des points de contrôle.
1.2.6 Fuel VM - Buff Stack : Machine Virtuelle Parallèle sous le framework UTXO
Projet représentatif : Carburant
Fuel VM est basé sur le cadre technologique EVM, Solana, WASM, BTC et Cosmos, et possède les caractéristiques suivantes par rapport à EVM :
La chose la plus unique est que Fuel a non seulement la capacité d’exécuter des transactions en parallèle avec des transactions qui ne se chevauchent pas en définissant des listes d’accès comme les SVM, mais adopte également le modèle UTXO, qui est divisé en UTXO de jeton et UTXO contractuel, ce qui améliore encore l’efficacité de l’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 propre langage spécifique au domaine, Sway, et à la chaîne d’outils de support Fort, avec un environnement de développement qui conserve les avantages des langages de contrats intelligents tels que Solidity tout en adoptant les paradigmes introduits dans l’écosystème d’outils Rust.
À l’avenir, la machine virtuelle Fuel implémentera également des mises à niveau du langage Sway, y compris des optimisations du compilateur en termes de taille de bytecode, Sway prendra en charge plus de backends (les backends EVM sont déjà en développement), les abstractions seront plus économiques, plus d’applications seront migrées de Solidity/Vyper vers Sway, une meilleure analyse de réentrée au niveau du compilateur, etc.
1.2.7 ESC VM - Successeur d’Ordinal/Smartweave : La couche de calcul au-dessus d’Ethereum
Projet représentatif : Protocole Ethions
ESC VM, ou Ethions Virtual Machine, est une solution de smart contract proposée par Ethions Protocol. Le protocole Ethions lui-même est un protocole similaire à BTC Ordinal sur la chaîne Ethereum, se concentrant sur l’exploration d’alternatives à faible coût aux contrats intelligents et à la L2.
Ethions permet aux utilisateurs de contourner le stockage et l’exécution de contrats intelligents à une fraction du coût, et d’appliquer les données d’appel dans Tx pour calculer via des règles de protocole pré-convenues. Pour le dire simplement, tant qu’une transaction Ethereum réussie a une calldata qui répond à la spécification de données valide spécifiée et que l’adresse unique et « à » n’est pas 0, elle peut être considérée comme ayant légalement créé un Ethion, l’adresse « de » étant le créateur et l’adresse « à » étant le propriétaire.
Au début de la conception, chaque Ethion est plus enclin à la forme de NFT, comme l’image NFT, et écrit directement le contenu de l’image dans les calldata via le format Base64 :
L’eths le plus populaire récemment est Ethion, qui a été créé en référence à la spécification du protocole BRC-20 :
Le contrat intelligent introduit par ESC VM, connu sous le nom de « contrat muet », est annoncé comme un contrat logique, mais n’interagit pas sur la chaîne sous la forme d’EVM lui-même. En outre, la machine virtuelle ESC ajoute également un format spécial « Commande de l’ordinateur », qui sera reconnu par la machine virtuelle ESC pour interagir avec les contrats muets, tels que Déployer - déployer - déployer - appeler le contrat muet.
Il y a quelques limites à ce schéma, l’une est que la fonction du « contrat muet » n’est pas payable, c’est-à-dire que si vous voulez envoyer de l’ETH par le biais d’un contrat stupide, vous devez passer par un « contrat pont », et le « contrat pont » lui-même présente un risque d’abus de contrôle et de vol d’actifs ; Deuxièmement, il y a un seuil d’entrée dans l’écosystème, qui ne permet pas la création arbitraire de contrats stupides, et son code doit être défini par la proposition de gouvernance du Protocole d’Ethions.
Pour résumer, ESC VM est une couche de calcul construite sur Ethereum L1 en tant que couche de stockage de données, qui est mise en œuvre en plaçant la logique de contrat, les appels de contrat, les appels de contrat et d’autres contenus de données dans les calldata d’Ethereum tx, et le consensus d’état global de ESC VM est le consensus des clients ESC VM, qui est similaire à la logique d’implémentation SmartWeave d’Arweave, mais la couche de stockage de données de SmartWeave est Arweave.
VM 1.2.8 Bit - Une expérience de recherche intéressante : un canal d’exécution peer-to-peer au-dessus de BTC
Projet représentatif : ZeroSync
Robin Linus, le fondateur de ZeroSync, a publié un livre blanc le 9 octobre, « BitVM : Compute Anything On Bitcoin », qui n’est pas une VM pour être précis, mais une tentative de créer un espace informatique complet de Turing avec des contrats stockés sur la chaîne Bitcoin, mais la logique du contrat est exécutée hors chaîne. Si vous pensez que l’autre partie est en défaut, vous pouvez lancer une contestation sur la chaîne, et si l’autre partie ne peut pas répondre correctement, vous pouvez prendre tous les fonds du contrat.
L’avantage est qu’il peut donner à Bitcoin Turing l’exhaustivité sans aucune modification du protocole Bitcoin, sans nouveaux opcodes, sans soft forks, et prêt à être appliqué.
Ses inconvénients sont également évidents, l’un est qu’il ne prend en charge que les transactions entre deux parties (l’une prouve et l’autre vérifie), et l’autre est que la création d’un contrat nécessite la création d’une grande quantité de données et la pré-signature d’un grand nombre de transactions, et le coût du stockage d’informations hors chaîne est énorme.
Voici une brève introduction à la logique technique :
(1) Engagement d’entrée de points
L’engagement d’entrée de point permet au prouveur de définir une valeur d’entrée de 0 ou 1 pour la porte logique, et dans cette promesse, il y a deux valeurs de hachage H(A0) et H(A1), et le prouveur doit révéler un hachage précurseur, par exemple A0, puis définir la valeur d’entrée à 0, si A1 est révélé, définir la valeur d’entrée à 1.
(2) Engagement de porte logique
Une fois que vous avez les valeurs d’entrée, vous pouvez combiner n’importe quelle porte logique dans Bitcoin Script en combinant les opcodes amp et NAND de Bitcoin.
(3) Engagement de circuit binaire
La complétude de Turing peut être obtenue en combinant des centaines de millions de portes logiques dans un circuit binaire. Afin de valider ce circuit binaire sur le réseau Bitcoin, toutes les portes logiques doivent être placées dans un nœud feuille avec une adresse Taproot.
(4) Lien défi-réponse
Il ne suffit pas d’engager le circuit sur la chaîne, les deux parties de la transaction ont besoin d’un moyen efficace de vérifier que les calculs du contrat sont corrects. Idéalement, le contrat se déroule hors chaîne, et les deux parties sont heureuses lorsqu’elles sont coopératives et incontestées. Cependant, s’il y a un différend entre les deux parties à la transaction, il est nécessaire d’entrer dans l’étape Challenge-Response pour vérifier les résultats du calcul et forcer la distribution du solde du canal via Bitcoin Script.
En tant que tel, BitVM est loin d’être une sorte de Bitcoin Rollup ou L2 et ne dispose pas d’un environnement d’exécution de machine virtuelle complet, d’un état global, d’un langage de haut niveau pour la publication de contrats intelligents complexes et ne peut pas permettre à un nombre quelconque d’utilisateurs d’interagir facilement avec ces contrats. Pour illustrer cela avec un exemple profane, BitVM est comme construire un ordinateur géant plus grand qu’une pièce à l’époque où tout le monde peut utiliser des appareils mobiles.
1.2.9 MoveVM - un produit des gènes Web2 de Facebook
Projets représentatifs : Aptos, Sui
Move est un langage de programmation pour l’écriture de contrats intelligents sécurisés, qui a été développé à l’origine par Facebook pour prendre en charge la blockchain Diem, et après l’arrêt du projet de blockchain Diem, des projets tels que Aptos et Sui ont continué à utiliser le langage Move. La plus grande caractéristique de la blockchain Move est que le stockage des données adopte un stockage global, qui se compose d’une arborescence avec l’adresse du compte comme racine, et chaque adresse peut stocker des données de ressources et du code de module.
Il existe deux types de programmes différents pour Move : les modules et les scripts. Un module est une bibliothèque qui définit les types de structure et les fonctions qui opèrent sur ces types. Le type de structure définit le mode de stockage global pour le Move, et la fonction module définit les règles de mise à jour du stockage. Les modules eux-mêmes sont également stockés dans un stockage global. Les scripts, quant à eux, sont le point d’entrée de l’exécutable, similaire à la fonction principale dans les langages traditionnels, et sont des extraits de code temporaires qui ne sont pas publiés dans le magasin global.
En résumé, le module Move est similaire au module de bibliothèque dynamique qui est chargé lors de l’exécution de l’exécutable système, tandis que le script est similaire au programme principal. Les utilisateurs peuvent écrire leurs propres scripts pour accéder au stockage global, y compris les modules d’appel, tandis que la publication de modules ou l’exécution de scripts peuvent être manipulées via la machine virtuelle de déplacement.
1.3 Tendances du développement écologique
Maintenant que l’effet de réseau EVM est si fort, la migration des utilisateurs EVM vers des écosystèmes de chaînes non-EVM est devenue le plus grand point de croissance pour les projets de blockchain émergents, qui apporteront plus de composabilité Dapp, et une plus grande connectivité pourrait conduire à une croissance plus rapide des utilisateurs dans les années à venir.
1.3.1 Compatible avec le front-end du portefeuille
L’introduction des utilisateurs d’EVM dans les chaînes non-EVM a toujours été un obstacle majeur, mais le lancement récent de Metamask Snap brisera cette barrière. Les utilisateurs d’EVM peuvent continuer à utiliser MetaMask sans avoir à changer de portefeuille. Grâce aux contributions open-source de Drift, qui construisent une excellente implémentation de MetaMask Snap, l’UX est l’équivalent d’une interaction avec n’importe quelle chaîne EVM. Les utilisateurs du réseau principal d’Eclipse pourront interagir avec les applications natives de MetaMask ou utiliser des portefeuilles natifs de Solana tels que Salmon.
1.3.2 Compatible avec le backend des VM
1.3.2.1 Transpilateur / Compilateur
Projet représentatif : Wrap
Warp est un transpilateur Solidity-Cairo qui a été développé par Nethermind, une équipe d’infrastructure bien connue sur Ethereum. Warp peut traduire le code Solidity en Cairo, mais le programme Cairo traduit a souvent besoin de modifier et d’ajouter des fonctionnalités Cairo (telles que l’appel de fonctions intégrées, l’optimisation de la mémoire, etc.) pour maximiser l’efficacité de l’exécution.
1.3.2.2 Couche de compatibilité de l’interpréteur de bytecode/VM
Projets représentatifs : Kakarot, Neon EVM
Kakarot est un interpréteur de bytecode EVM implémenté sous la forme d’un contrat intelligent écrit au Caire sur Starknet, qui simule la pile, la mémoire, l’exécution et d’autres aspects de l’EVM sous la forme d’un contrat intelligent du Caire. Par rapport à la traduction de code, Kakarot implémente l’implémentation élément par élément d’Opcode et de Pre-compile derrière l’EVM, et construit des composants tels que Account Registry et Blockhash Registry pour fournir un traitement supplémentaire pour le mappage d’adresses de compte et l’acquisition d’informations de bloc, de sorte que kakarot ait une compatibilité native plus élevée.
Neon EVM est un type d’EVM qui fonctionne comme un contrat intelligent et peut être déployé sur n’importe quelle chaîne SVM. Le réseau principal Eclipse lui-même utilise SVM comme environnement d’exécution, mais apporte une compatibilité EVM complète (y compris la prise en charge du bytecode EVM et Ethereum JSON-RPC) via l’EVM Neon, et un débit plus élevé que l’EVM monothread. De plus, chaque instance Neon EVM a son propre marché de frais local, c’est-à-dire qu’il existe une limite supérieure (1/4 de l’unité de calcul de bloc) liée à l’interaction d’un seul compte de contrat à une hauteur de bloc, de sorte que les utilisateurs n’ont besoin de payer des frais prioritaires que lorsqu’une interaction ou un bloc de contrat chaud spécifique est plein. En ce sens, une application déploie son propre contrat pour obtenir un avantage similaire à celui d’une chaîne d’applications, réduisant ainsi la perturbation de l’expérience utilisateur, de la sécurité ou de la liquidité de l’ensemble du réseau lorsqu’un contrat particulier interagit avec la congestion tx.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Rollup Falls Fortement La VM a encore une histoire à raconter
Par PSE Trading Analyst @cryptohawk, Mirror
TL ; DR
Une machine virtuelle est un système informatique émulé par logiciel qui fournit un environnement d’exécution pour un programme. Il peut émuler une variété de périphériques matériels pour permettre aux programmes de s’exécuter dans un environnement contrôlé et compatible.
La machine virtuelle Ethereum (EVM) est une machine virtuelle basée sur une pile qui exécute des contrats intelligents Ethereum ; zkEVM optimise l’efficacité de la génération à l’épreuve de zk sur l’équivalence/compatibilité EVM.
zkVM élimine l’équivalence/compatibilité EVM et augmente la priorité de la convivialité zk.
privacy zkVM superpose les fonctionnalités de confidentialité natives sur zkVM ;
SVM, FuelVM et MoveVM ont en commun de rechercher les performances ultimes grâce à l’exécution parallèle, mais ils ont leurs propres caractéristiques dans les détails de conception.
ESC VM et BitVM ont mené des expériences innovantes sur la couche de calcul sur les chaînes ETH et BTC respectivement, mais la demande de mise en œuvre réelle dans l’environnement actuel est faible.
1.1 Qu’est-ce qu’une VM ?
Une machine virtuelle (VM) est l’élément constitutif des ressources informatiques virtualisées qui a presque les mêmes fonctions qu’un ordinateur, y compris l’exécution d’applications et de systèmes d’exploitation. Le concept de machines virtuelles n’est pas nouveau, et la 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 qui exécute des contrats intelligents blockchain. Les machines virtuelles fournissent généralement un environnement informatique virtuel en émulant différents périphériques matériels. Différentes machines virtuelles peuvent émuler différents périphériques matériels, mais incluent généralement le processeur, la mémoire, les disques durs, les interfaces réseau, etc. Lorsqu’une transaction on-chain est soumise, la machine virtuelle est responsable du traitement de la transaction et de la mise à jour de l’état de la blockchain (l’état global actuel de l’ensemble du réseau) qui est affecté par l’exécution de cette transaction. Les règles spécifiques qui modifient l’état du réseau sont définies par la machine virtuelle. Lors du traitement d’une transaction, la machine virtuelle convertit le code du contrat intelligent dans un format qui peut être exécuté par le matériel du nœud/validateur.
Le noyau le plus important d’une machine virtuelle est LLVM (low-level-virtual-machine), qui peut être considéré comme le noyau le plus important du compilateur. La figure montre le schéma de fonctionnement de l’EVM d’origine, et le contrat intelligent est converti en Bytecode via le code intermédiaire de LLVM IR. Ces bytecodes sont stockés sur la blockchain, et lorsque le contrat intelligent est appelé, le bytecode est converti en l’Opcode correspondant, qui est ensuite exécuté par l’EVM et le matériel du nœud.
1.2 Machines virtuelles grand public
1.2.1 EVM - La VM blockchain a un total d’une pierre, l’EVM est exclusif à huit compartiments et le reste est divisé en deux compartiments
Projets représentatifs : Optimisme, Arbitrum
En tant qu’écosystème blockchain avec la plus grande activité de développeurs et d’utilisateurs du secteur, l’EVM de la machine virtuelle Ethereum est une machine virtuelle basée sur une pile qui fournit un environnement informatique virtuel en émulant des périphériques matériels tels que le processeur, la mémoire, la mémoire et les piles, afin d’exécuter des instructions de contrat intelligent et de stocker l’état et les données du contrat intelligent. Le jeu d’instructions de l’EVM comprend divers opcodes d’opcode, tels que les opérations arithmétiques, les opérations logiques, les opérations de stockage, les opérations de saut, etc.
La mémoire et la mémoire émulée par l’EVM sont des dispositifs utilisés pour stocker l’état et les données du contrat intelligent. L’EVM traite la mémoire et la mémoire comme deux zones distinctes qui peuvent accéder à l’état et aux données d’un contrat intelligent en lisant et en écrivant dans la mémoire et la mémoire.
La pile de simulations EVM est utilisée pour stocker les opérandes et les résultats des instructions. La plupart des instructions du jeu d’instructions de l’EVM sont basées sur une pile, elles lisent les opérandes de la pile et repoussent les résultats dans la pile.
Le processus de conception de l’EVM est évidemment ascendant, d’abord en finalisant l’environnement matériel simulé (pile, mémoire), puis en concevant son propre jeu d’instructions d’assemblage (Opcode) et bytecode (Bytecode) en fonction de l’environnement correspondant. La communauté Ethereum a conçu deux langages compilés de haut niveau - Solidity et Vyper - pour l’efficacité de l’exécution de l’EVM. Inutile de dire que Vyper est le langage EVM de haut niveau de Vitalik conçu pour remédier à certaines des failles de Solidity, mais il n’a pas reçu beaucoup d’adoption dans la communauté, il a donc progressivement disparu dans l’obscurité.
1.2.2 zkEVM - Je veux tout : compatible avec l’environnement EVM + prise en charge de la conversion racine de l’état global pour générer zk-proof
Projets représentatifs : Taiko, Scroll, Polygon zkEVM
Parce que l’EVM n’est pas construit avec le calcul à l’épreuve zk, il n’est pas convivial pour les circuits de preuve, en particulier en termes d’opcodes spéciaux, d’architectures basées sur la pile, de surcharge de stockage et de coûts de preuve. zkEVM est une machine virtuelle qui exécute des contrats intelligents d’une manière compatible avec l’informatique à l’épreuve de zk, de sorte que le processus d’exécution d’EVM peut être vérifié de manière plus efficace et plus rentable grâce à zk-proof/validity-proof. Par rapport au cumul OP, la couche d’exécution n’a besoin que de copier l’EVM, et la construction conviviale de l’EVM est un défi supplémentaire pour ZK Rollup.
Les ZK-rollups ne sont pas facilement compatibles avec la machine virtuelle Ethereum (EVM). La preuve d’un calcul EVM à usage général dans un circuit est plus difficile et gourmande en ressources que la preuve d’un calcul simple tel que le transfert de jetons décrit précédemment.
Cependant, les progrès de la technologie à divulgation nulle de connaissance(s’ouvre dans un nouvel onglet) ont ravivé l’intérêt pour l’intégration du calcul EVM dans des preuves à divulgation nulle de connaissance. Ces efforts visent à créer une implémentation EVM à connaissance nulle (zkEVM) qui peut vérifier efficacement l’exactitude de l’exécution du programme.
Comme l’EVM, le zkEVM passe d’un état à l’autre après avoir effectué des calculs sur certaines entrées. La différence est que zkEVM crée également des preuves à divulgation nulle de connaissance pour vérifier l’exactitude de chaque étape de l’exécution du programme. Les preuves de validité peuvent vérifier l’exactitude des opérations impliquant l’état de la machine virtuelle (mémoire, pile, stockage) et le calcul lui-même (c’est-à-dire, l’opération a-t-elle appelé les bons opcodes et les a-t-elle exécutés correctement ?). ）。
À l’heure actuelle, il est difficile pour Rollup d’obtenir une compatibilité ZK-friendly et EVM (ou même équivalent), c’est-à-dire de répliquer la couche d’exécution Ethereum L1 aussi complètement que possible, y compris les hachages, les arbres d’état, les arbres de transaction, la précompilation, etc., afin que le client d’exécution Ethereum L1 puisse l’utiliser tel quel pour traiter les blocs Rollup ; Soit abandonner la compatibilité EVM et recréer l’Opcode existant pour la preuve/vérification dans le circuit, permettant l’exécution de contrats intelligents.
1.2.3 zkVM - Vous ne pouvez pas l’avoir dans les deux sens : des machines virtuelles non evm orientées vers l’efficacité à l’épreuve de zk
Projets représentatifs : Starknet, Zksync, RISC ZERO
Plutôt que la compatibilité EVM, zkVM a trouvé un diviseur commun entre la cryptographie et les langages de haut niveau avec les preuves de données et les mises à jour d’état comme objectifs principaux, fournissant un cadre commun pour un large éventail d’applications.
Starkware dispose d’un certain leadership technologique en raison de son démarrage précoce dans l’ensemble du domaine ZK et de son accumulation technologique relativement suffisante. Il est l’architecture technique représentative centrée sur ZK autour de laquelle Cairo VM et le langage du Caire sont construits. L’inconvénient est que le Caire est plus cher à apprendre.
Le framework de ZKsync est compatible à la fois avec EVM et ZK, et intègre Solidity avec son langage de circuit développé par ses soins, Zinc, unifiant les deux au niveau IR au sein du compilateur. L’avantage est que le LLVM du noyau du compilateur est compatible avec plusieurs langages.
RISC Zero utilise l’architecture RISC-V pour construire des simulateurs qui permettent aux programmeurs d’écrire des programmes pour zkVM dans des langages à usage général tels que Rust, C/C++ et Go, ce qui signifie que la logique d’application n’a pas besoin d’être limitée à ce qui peut être exprimé dans Solidity, ce qui permet d’écrire du code indépendant de la chaîne.
1.2.4 Confidentialité zkVM - zk-friendly + prise en charge native de la confidentialité, essayant d’allumer une nouvelle étincelle dans l’écosystème
Projets représentatifs : Aleo, Ola, Polygon Miden
La blockchain est un système de registre public où toutes les transactions sont effectuées sur la chaîne, ce qui signifie que les changements d’état contenant des informations sur les actifs liés aux adresses ou aux comptes sont ouverts et transparents. Par conséquent, en plus de travailler sur des solutions de mise à l’échelle, certaines équipes blockchain estiment que la prochaine fonctionnalité clé à mettre en œuvre est la confidentialité.
En plus de la prise en charge de la mise à l’échelle conviviale par zk, Privacy zkVM permet à ses développeurs d’applications de couche supérieure d’ouvrir des dapps liées à la confidentialité grâce aux fonctionnalités de confidentialité nativement prises en charge par son propre langage de programmation, ce qui apportera de nouveaux scénarios d’application et de grands récits, tels que la résolution complète du problème MEV et la garantie de la propriété des données des utilisateurs. Bien sûr, la complexité de la conception de Privacy zkVM nécessitera une équipe technique beaucoup plus importante pour la mettre en œuvre, et cela peut prendre plusieurs années à réaliser.
1.2.5 SVM - Après la marée descendante, il y a encore des braises : un environnement d’exécution qui a été conçu à l’extrême de la performance
Projets représentatifs : Eclipse Mainnet, Nitro, MakerDAO Chain (peut-être)
SVM, ou Solana Virtual Machine, se concentre sur un environnement d’exécution haute performance, et les contrats intelligents sont principalement écrits en Rust. Contrairement aux environnements d’exécution EVM et EOS WASM à un seul thread, les SVM permettent des transactions qui ne se chevauchent pas et l’exécution simultanée de transactions qui ne lisent que le même état en exigeant que les transactions Solana décrivent tous les états qui leur seront lus ou écrits au moment de l’exécution.
De plus, afin de vérifier/diffuser rapidement un grand nombre de blocs de transactions, le processus de vérification des transactions sur le réseau Solana fait un usage intensif des optimisations de pipeline qui sont courantes dans la conception de processeurs. Pour répondre à la situation où une série d’étapes traitent le flux de données d’entrée, et chaque étape a une responsabilité matérielle différente. Une analogie typique est celle d’une laveuse et d’une sécheuse, qui lavent/sèche/plient plusieurs lots de linge en séquence. Le lavage doit être effectué avant le séchage, et le pliage doit être effectué avant le séchage, mais chacune de ces trois opérations est effectuée par une unité séparée.
De plus, les SVM sont basées sur des registres et ont un jeu d’instructions beaucoup plus petit que les EVM, ce qui rend l’exécution des SVM plus facile à prouver dans ZK. Pour les cumuls optimistes, les conceptions basées sur les registres facilitent la définition des points de contrôle.
1.2.6 Fuel VM - Buff Stack : Machine Virtuelle Parallèle sous le framework UTXO
Projet représentatif : Carburant
Fuel VM est basé sur le cadre technologique EVM, Solana, WASM, BTC et Cosmos, et possède les caractéristiques suivantes par rapport à EVM :
La chose la plus unique est que Fuel a non seulement la capacité d’exécuter des transactions en parallèle avec des transactions qui ne se chevauchent pas en définissant des listes d’accès comme les SVM, mais adopte également le modèle UTXO, qui est divisé en UTXO de jeton et UTXO contractuel, ce qui améliore encore l’efficacité de l’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 propre langage spécifique au domaine, Sway, et à la chaîne d’outils de support Fort, avec un environnement de développement qui conserve les avantages des langages de contrats intelligents tels que Solidity tout en adoptant les paradigmes introduits dans l’écosystème d’outils Rust.
À l’avenir, la machine virtuelle Fuel implémentera également des mises à niveau du langage Sway, y compris des optimisations du compilateur en termes de taille de bytecode, Sway prendra en charge plus de backends (les backends EVM sont déjà en développement), les abstractions seront plus économiques, plus d’applications seront migrées de Solidity/Vyper vers Sway, une meilleure analyse de réentrée au niveau du compilateur, etc.
1.2.7 ESC VM - Successeur d’Ordinal/Smartweave : La couche de calcul au-dessus d’Ethereum
Projet représentatif : Protocole Ethions
ESC VM, ou Ethions Virtual Machine, est une solution de smart contract proposée par Ethions Protocol. Le protocole Ethions lui-même est un protocole similaire à BTC Ordinal sur la chaîne Ethereum, se concentrant sur l’exploration d’alternatives à faible coût aux contrats intelligents et à la L2.
Ethions permet aux utilisateurs de contourner le stockage et l’exécution de contrats intelligents à une fraction du coût, et d’appliquer les données d’appel dans Tx pour calculer via des règles de protocole pré-convenues. Pour le dire simplement, tant qu’une transaction Ethereum réussie a une calldata qui répond à la spécification de données valide spécifiée et que l’adresse unique et « à » n’est pas 0, elle peut être considérée comme ayant légalement créé un Ethion, l’adresse « de » étant le créateur et l’adresse « à » étant le propriétaire.
Au début de la conception, chaque Ethion est plus enclin à la forme de NFT, comme l’image NFT, et écrit directement le contenu de l’image dans les calldata via le format Base64 :
L’eths le plus populaire récemment est Ethion, qui a été créé en référence à la spécification du protocole BRC-20 :
Le contrat intelligent introduit par ESC VM, connu sous le nom de « contrat muet », est annoncé comme un contrat logique, mais n’interagit pas sur la chaîne sous la forme d’EVM lui-même. En outre, la machine virtuelle ESC ajoute également un format spécial « Commande de l’ordinateur », qui sera reconnu par la machine virtuelle ESC pour interagir avec les contrats muets, tels que Déployer - déployer - déployer - appeler le contrat muet.
Il y a quelques limites à ce schéma, l’une est que la fonction du « contrat muet » n’est pas payable, c’est-à-dire que si vous voulez envoyer de l’ETH par le biais d’un contrat stupide, vous devez passer par un « contrat pont », et le « contrat pont » lui-même présente un risque d’abus de contrôle et de vol d’actifs ; Deuxièmement, il y a un seuil d’entrée dans l’écosystème, qui ne permet pas la création arbitraire de contrats stupides, et son code doit être défini par la proposition de gouvernance du Protocole d’Ethions.
Pour résumer, ESC VM est une couche de calcul construite sur Ethereum L1 en tant que couche de stockage de données, qui est mise en œuvre en plaçant la logique de contrat, les appels de contrat, les appels de contrat et d’autres contenus de données dans les calldata d’Ethereum tx, et le consensus d’état global de ESC VM est le consensus des clients ESC VM, qui est similaire à la logique d’implémentation SmartWeave d’Arweave, mais la couche de stockage de données de SmartWeave est Arweave.
VM 1.2.8 Bit - Une expérience de recherche intéressante : un canal d’exécution peer-to-peer au-dessus de BTC
Projet représentatif : ZeroSync
Robin Linus, le fondateur de ZeroSync, a publié un livre blanc le 9 octobre, « BitVM : Compute Anything On Bitcoin », qui n’est pas une VM pour être précis, mais une tentative de créer un espace informatique complet de Turing avec des contrats stockés sur la chaîne Bitcoin, mais la logique du contrat est exécutée hors chaîne. Si vous pensez que l’autre partie est en défaut, vous pouvez lancer une contestation sur la chaîne, et si l’autre partie ne peut pas répondre correctement, vous pouvez prendre tous les fonds du contrat.
L’avantage est qu’il peut donner à Bitcoin Turing l’exhaustivité sans aucune modification du protocole Bitcoin, sans nouveaux opcodes, sans soft forks, et prêt à être appliqué.
Ses inconvénients sont également évidents, l’un est qu’il ne prend en charge que les transactions entre deux parties (l’une prouve et l’autre vérifie), et l’autre est que la création d’un contrat nécessite la création d’une grande quantité de données et la pré-signature d’un grand nombre de transactions, et le coût du stockage d’informations hors chaîne est énorme.
Voici une brève introduction à la logique technique :
(1) Engagement d’entrée de points
L’engagement d’entrée de point permet au prouveur de définir une valeur d’entrée de 0 ou 1 pour la porte logique, et dans cette promesse, il y a deux valeurs de hachage H(A0) et H(A1), et le prouveur doit révéler un hachage précurseur, par exemple A0, puis définir la valeur d’entrée à 0, si A1 est révélé, définir la valeur d’entrée à 1.
(2) Engagement de porte logique
Une fois que vous avez les valeurs d’entrée, vous pouvez combiner n’importe quelle porte logique dans Bitcoin Script en combinant les opcodes amp et NAND de Bitcoin.
(3) Engagement de circuit binaire
La complétude de Turing peut être obtenue en combinant des centaines de millions de portes logiques dans un circuit binaire. Afin de valider ce circuit binaire sur le réseau Bitcoin, toutes les portes logiques doivent être placées dans un nœud feuille avec une adresse Taproot.
(4) Lien défi-réponse
Il ne suffit pas d’engager le circuit sur la chaîne, les deux parties de la transaction ont besoin d’un moyen efficace de vérifier que les calculs du contrat sont corrects. Idéalement, le contrat se déroule hors chaîne, et les deux parties sont heureuses lorsqu’elles sont coopératives et incontestées. Cependant, s’il y a un différend entre les deux parties à la transaction, il est nécessaire d’entrer dans l’étape Challenge-Response pour vérifier les résultats du calcul et forcer la distribution du solde du canal via Bitcoin Script.
En tant que tel, BitVM est loin d’être une sorte de Bitcoin Rollup ou L2 et ne dispose pas d’un environnement d’exécution de machine virtuelle complet, d’un état global, d’un langage de haut niveau pour la publication de contrats intelligents complexes et ne peut pas permettre à un nombre quelconque d’utilisateurs d’interagir facilement avec ces contrats. Pour illustrer cela avec un exemple profane, BitVM est comme construire un ordinateur géant plus grand qu’une pièce à l’époque où tout le monde peut utiliser des appareils mobiles.
1.2.9 MoveVM - un produit des gènes Web2 de Facebook
Projets représentatifs : Aptos, Sui
Move est un langage de programmation pour l’écriture de contrats intelligents sécurisés, qui a été développé à l’origine par Facebook pour prendre en charge la blockchain Diem, et après l’arrêt du projet de blockchain Diem, des projets tels que Aptos et Sui ont continué à utiliser le langage Move. La plus grande caractéristique de la blockchain Move est que le stockage des données adopte un stockage global, qui se compose d’une arborescence avec l’adresse du compte comme racine, et chaque adresse peut stocker des données de ressources et du code de module.
Il existe deux types de programmes différents pour Move : les modules et les scripts. Un module est une bibliothèque qui définit les types de structure et les fonctions qui opèrent sur ces types. Le type de structure définit le mode de stockage global pour le Move, et la fonction module définit les règles de mise à jour du stockage. Les modules eux-mêmes sont également stockés dans un stockage global. Les scripts, quant à eux, sont le point d’entrée de l’exécutable, similaire à la fonction principale dans les langages traditionnels, et sont des extraits de code temporaires qui ne sont pas publiés dans le magasin global.
En résumé, le module Move est similaire au module de bibliothèque dynamique qui est chargé lors de l’exécution de l’exécutable système, tandis que le script est similaire au programme principal. Les utilisateurs peuvent écrire leurs propres scripts pour accéder au stockage global, y compris les modules d’appel, tandis que la publication de modules ou l’exécution de scripts peuvent être manipulées via la machine virtuelle de déplacement.
1.3 Tendances du développement écologique
Maintenant que l’effet de réseau EVM est si fort, la migration des utilisateurs EVM vers des écosystèmes de chaînes non-EVM est devenue le plus grand point de croissance pour les projets de blockchain émergents, qui apporteront plus de composabilité Dapp, et une plus grande connectivité pourrait conduire à une croissance plus rapide des utilisateurs dans les années à venir.
1.3.1 Compatible avec le front-end du portefeuille
L’introduction des utilisateurs d’EVM dans les chaînes non-EVM a toujours été un obstacle majeur, mais le lancement récent de Metamask Snap brisera cette barrière. Les utilisateurs d’EVM peuvent continuer à utiliser MetaMask sans avoir à changer de portefeuille. Grâce aux contributions open-source de Drift, qui construisent une excellente implémentation de MetaMask Snap, l’UX est l’équivalent d’une interaction avec n’importe quelle chaîne EVM. Les utilisateurs du réseau principal d’Eclipse pourront interagir avec les applications natives de MetaMask ou utiliser des portefeuilles natifs de Solana tels que Salmon.
1.3.2 Compatible avec le backend des VM
1.3.2.1 Transpilateur / Compilateur
Projet représentatif : Wrap
Warp est un transpilateur Solidity-Cairo qui a été développé par Nethermind, une équipe d’infrastructure bien connue sur Ethereum. Warp peut traduire le code Solidity en Cairo, mais le programme Cairo traduit a souvent besoin de modifier et d’ajouter des fonctionnalités Cairo (telles que l’appel de fonctions intégrées, l’optimisation de la mémoire, etc.) pour maximiser l’efficacité de l’exécution.
1.3.2.2 Couche de compatibilité de l’interpréteur de bytecode/VM
Projets représentatifs : Kakarot, Neon EVM
Kakarot est un interpréteur de bytecode EVM implémenté sous la forme d’un contrat intelligent écrit au Caire sur Starknet, qui simule la pile, la mémoire, l’exécution et d’autres aspects de l’EVM sous la forme d’un contrat intelligent du Caire. Par rapport à la traduction de code, Kakarot implémente l’implémentation élément par élément d’Opcode et de Pre-compile derrière l’EVM, et construit des composants tels que Account Registry et Blockhash Registry pour fournir un traitement supplémentaire pour le mappage d’adresses de compte et l’acquisition d’informations de bloc, de sorte que kakarot ait une compatibilité native plus élevée.
Neon EVM est un type d’EVM qui fonctionne comme un contrat intelligent et peut être déployé sur n’importe quelle chaîne SVM. Le réseau principal Eclipse lui-même utilise SVM comme environnement d’exécution, mais apporte une compatibilité EVM complète (y compris la prise en charge du bytecode EVM et Ethereum JSON-RPC) via l’EVM Neon, et un débit plus élevé que l’EVM monothread. De plus, chaque instance Neon EVM a son propre marché de frais local, c’est-à-dire qu’il existe une limite supérieure (1/4 de l’unité de calcul de bloc) liée à l’interaction d’un seul compte de contrat à une hauteur de bloc, de sorte que les utilisateurs n’ont besoin de payer des frais prioritaires que lorsqu’une interaction ou un bloc de contrat chaud spécifique est plein. En ce sens, une application déploie son propre contrat pour obtenir un avantage similaire à celui d’une chaîne d’applications, réduisant ainsi la perturbation de l’expérience utilisateur, de la sécurité ou de la liquidité de l’ensemble du réseau lorsqu’un contrat particulier interagit avec la congestion tx.