Original author: PSE Trading Analyst@cryptohawk
TL;DR
A virtual machine is a software-emulated computer system that provides an execution environment for programs. It can simulate various hardware devices and allow programs to run in a controlled and compatible environment.
The Ethereum Virtual Machine (EVM) is a stack-based virtual machine used to execute Ethereum smart contracts; zkEVM has made certain zk-proof generation efficiency optimizations in terms of EVM equivalence/compatibility;
zkVM abandons EVM equivalence/compatibility and increases the priority of zk-friendliness;
privacy zkVM superimposes native privacy features on zkVM;
SVM, FuelVM, and MoveVM have in common the pursuit of ultimate performance through parallel execution, but they have their own characteristics in design details;
ESC VM and BitVM have conducted certain innovative computing layer experiments on the ETH and BTC chains respectively, but the actual implementation demand is low in the current environment.
EVMs huge user ecosystem determines that any blockchain network that abandons it will have difficulty competing with it in the short term. Therefore, the non-EVM ecosystem introduces EVM ecological users through translators/compilers/bytecode interpreters and even VM compatibility layers to utilize non-EVM Using virtual machine features to build a new ecological narrative may be a necessary path to success.
1.1 What is a VM?
A virtual machine (VM) is a building block of virtualized computing resources that performs almost the same functions as a computer, including running applications and operating systems. The concept of virtual machines is not new, and the technology is widely used in many technology ecosystems.
In the context of blockchain, a virtual machine (VM) is a piece of software that runs programs, often referred to as the runtime environment that executes blockchain smart contracts. Virtual machines usually provide a virtual computer environment by simulating different hardware devices. The hardware devices that different virtual machines can simulate vary, but usually include CPU, memory, hard disk, network interface, etc. When an on-chain transaction is submitted, the virtual machine is responsible for processing the transaction and updating the blockchain state (the current global state of the entire network) affected by the execution of the transaction. The specific rules for changing the network state are defined by the VM. When processing a transaction, the VM converts the smart contract code into a format that the node/validator hardware can execute.
The most important kernel among VMs is LLVM (low-level-virtual-machine), which can be regarded as the most important kernel of the compiler. The figure shows the original EVM operation scheme. The smart contract is converted through the intermediate code of LLVM IR and converted into Bytecode. These Bytecodes will be stored on the blockchain. When the smart contract is called, the Bytecodes will be converted into corresponding Opcodes, which will then be executed by the EVM and node hardware.
1.2 Mainstream VM
1.2.1 EVM - Blockchain VM has one stone in total, EVM has eight buckets exclusively, and the rest are divided into two buckets.
Representative projects: Optimism, Arbitrum
As the blockchain ecosystem with the most active developers users in the industry, the Ethereum Virtual Machine (EVM) is a stack-based virtual machine that provides a virtual computer by simulating hardware devices such as CPU, memory, storage and stacks. Environment to execute the instructions of the smart contract and store the status and data of the smart contract. The instruction set of the EVM includes various opcodes, such as arithmetic operations, logical operations, storage operations, jump operations, etc.
The memory and storage simulated by the EVM are devices used to store the state and data of smart contracts. EVM treats memory and storage as two different areas, and it can access the state and data of smart contracts by reading and writing memory and storage.
The EVM simulated stack is used to store the operands and results of instructions. Most instructions in the EVMs instruction set are stack-based, reading operands from the stack and pushing results back onto the stack.
The design process of EVM is obviously bottom-up. First, the simulated hardware environment (stack, memory) is finalized, and then its own set of assembly instruction set (Opcode) and bytecode (Bytecode) are designed according to the corresponding environment. . The Ethereum community has designed two compiled high-level languages—Solidity and Vyper—for EVM execution efficiency. Solidity Needless to say, Vyper is an EVM high-level language designed by Vitalik to improve some of the shortcomings in Solidity. However, it did not gain high adoption in the community and gradually faded out of history.
1.2.2 zkEVM - I want it all: compatible with EVM environment + supports global state root transformation to generate zk-proof
Representative projects: Taiko, Scroll, Polygon zkEVM
Because the EVM was not built with zk-proof computations in mind, it has properties that are unfriendly to proof circuits, especially in terms of special opcodes, stack-based architecture, storage overhead, and proof costs. zkEVM is a virtual machine that executes smart contracts in a way that is compatible with zk-proof calculations, so that the execution process of EVM can be verified more efficiently and cost-effectively through zk-proof/validity-proof. Compared with OP Rollup, the execution layer only needs to copy EVM, and building EVM to be ZK-friendly is an additional challenge for ZK Rollup.
ZK-rollups are not easily compatible with the Ethereum Virtual Machine (EVM). Proving general-purpose EVM computations in a circuit is more difficult and resource-intensive than proving simple computations (such as the token transfer described previously).
However, advances in zero-knowledge technology (opens in a new tab) have reignited interest in wrapping EVM computations in zero-knowledge proofs. These efforts aim to create a zero-knowledge EVM (zkEVM) implementation that can efficiently verify the correctness of program execution. .
Like EVM, zkEVM transitions between states after performing computations on certain inputs. The difference is that zkEVM also creates zero-knowledge proofs to verify the correctness of each step in program execution. Validity proofs verify the correctness of operations involving the virtual machine state (memory, stack, storage) and the computation itself (i.e., did the operation call the correct opcodes and execute them correctly?).
The idea is beautiful, but the reality is very skinny. Currently, Rollup has difficulty in achieving both ZK friendliness and EVM compatibility (or even equivalence), that is, it must either copy the Ethereum L1 execution layer as completely as possible, including hash, state tree, and transaction tree. , precompilation, etc., so that the Ethereum L1 execution client can be used as-is to process Rollup blocks; or discard EVM compatibility and recreate the existing Opcode for in-circuit attestation/verification, allowing smart contract execution .
1.2.3 zkVM - You can’t have your cake and eat it too: zk-proof efficiency-oriented non-evm virtual machine
Representative projects: Starknet, Zksync, RISC ZERO
zkVM abandons EVM compatibility, takes data proof and status update as its core goals, and finds a common denominator between cryptography and high-level languages to provide a common framework for various applications.
Since Starkware started earlier in the entire ZK field and has accumulated sufficient technology, it has a certain technological lead. He is a representative ZK-centric technical architecture and built Cairo VM and Cairo language around ZK. The downside is that Cairo is expensive to learn.
The framework of ZKsync is compatible with the characteristics of EVM and ZK, integrating Solidity with its self-developed circuit language Zinc, and unifying the two at the IR level within the compiler. The advantage is that the compiler core of LLVM is compatible with multiple languages.
RISC Zero uses the RISC-V architecture to build a simulator that allows programmers to write programs for zkVM in common languages such as Rust, C/C++ and Go. This means that application logic does not need to be limited to what can be expressed in Solidity, allowing to write and chain Irrelevant code.
1.2.4 Privacy zkVM - zk friendly + native privacy support, trying to ignite a new ecological spark
Representative projects: Aleo, Ola, Polygon Miden
Blockchain serves as a public ledger system, and all transactions are conducted on the chain, which means that state changes containing asset information related to addresses or accounts are open and transparent. Therefore, in addition to working on scaling solutions, some blockchain teams believe that the next key feature to be implemented is privacy.
In addition to being zk-friendly and supporting expansion, Privacy zkVM also allows upper-layer application developers to develop privacy-related dapps due to the privacy features natively supported by its own programming language. This will bring new application scenarios and grand narratives. For example, completely solve the MEV problem and protect user data ownership. Of course, the complexity of the Privacy zkVM design requires a larger technical team to implement it, and it may take several years to achieve it.
1.2.5 SVM - After the tide recedes, there are still embers: an execution environment where performance design has reached the extreme
Representative projects: Eclipse Mainnet, Nitro, MakerDAO Chain (maybe)
SVM, the Solana virtual machine, focuses on a high-performance execution environment, and smart contracts are mainly written in the Rust language. Compared to the single-threaded EVM and EOS WASM execution environments, SVM enables concurrent execution of non-overlapping transactions and transactions that only read the same state by requiring Solana transactions to describe all states that a transaction will read or write when executing.
In addition, in order to quickly verify/broadcast a large number of transaction blocks, the transaction verification process on the Solana network extensively uses pipeline optimization common in CPU design. In order to satisfy the situation where the input data flow is processed in a series of steps and each step has different hardware responsible for it. A typical analogy is a washer and dryer that wash/dry/fold multiple loads of laundry in sequence. Cleaning must be done before drying, and folding must be done before drying, but each of these three operations is performed by a separate unit.
In addition, SVM is register-based and has a much smaller instruction set than EVM, making the execution of SVM easier to prove in ZK. For optimistic rollups, a register-based design makes it easier to set checkpoints.
1.2.6 Fuel VM——buff stack: Parallel virtual machine under UTXO framework
Representative project: Fuel
Fuel VM is an improvement based on the technical framework of EVM, Solana, WASM, BTC Cosmos. Compared with EVM, it has the following characteristics:
The most unique thing is that Fuel not only sets access lists similar to SVM, but also has the ability to execute transactions in parallel with non-overlapping transactions. It also adopts the UTXO model, which is divided into token UTXO and contract UTXO, further improving access efficiency and computing throughput.
In addition, Fuel VM provides a powerful and smooth developer experience through its own domain-specific language Sway and supporting tool chain Forc. Its development environment retains the advantages of smart contract languages such as Solidity, while adopting paradigms introduced in the Rust tool ecosystem.
In the future, Fuel VM will also implement Sway language upgrades, including compiler optimization in terms of bytecode size, Sway will support more backends (the EVM backend is already under development), abstraction will be more economical, and more applications will be available. Migrating from Solidity/Vyper to Sway, improving compiler-level reentrancy analysis, and more.
1.2.7 ESC VM - the successor of Ordinal/Smartweave: the computing layer on top of Ethereum
Representative project: Ethscriptions Protocol
ESC VM, or Ethscriptions Virtual Machine, is a smart contract solution proposed by Ethscriptions Protocol. The Ethscriptions Protocol itself is a protocol similar to BTC Ordinal on the Ethereum chain, focusing on exploring low-cost alternatives different from smart contracts and L2.
Ethscriptions allow users to bypass smart contract storage and execution at extremely low cost by applying protocol rules agreed in advance to calldata in Tx for calculations. Simply put, as long as there is a successful Ethereum transaction and its calldata complies with the specified valid data specifications the unique to address is not 0, it can be considered that an Ethscription has been legally created, the from address is the creator, and to address is the owner.
At the beginning of the design, each Ethscription prefers the form of NFT, such as picture NFT. The picture content is directly written into calldata in Base 64 format:
The most popular eths recently is Ethscription, which was created with reference to the brc-20 protocol specification:
The smart contract introduced by ESC VM is called"dumb contract"(Dumb Contract) is publicized as a logical contract, but it does not interact on the chain in the form of EVM. In addition, ESC VM also adds a special format"computer commands", ethscriptions created using this format will be recognized by ESC VM to interact with dumb contracts, such as Deploy - deploy dumb contracts, Call - invoke dumb contracts.
There are some limitations to this solution. Firstly,"dumb contract"The function is not payable, which means that if you want to send ETH through a dumb contract, you must go through a bridge contract, and the bridge contract itself has the risk of control abuse asset theft; second, there are entry barriers to the ecosystem. Arbitrary creation of dumb contracts is not allowed, and their code needs to be defined through the Ethscriptions Protocol governance proposal.
To sum up, ESC VM is a computing layer built on top of Ethereum L1 as the data storage layer. It is implemented by placing contract logic, contract calls, contract calls and other data contents in the calldata of Ethereum tx. ESC VM The global state consensus is the ESC VM client consensus, which is similar to Arweaves SmartWeave implementation logic, except that the data storage layer of SmartWeave is Arweave.
1.2.8 Bit VM - An interesting research experiment: peer-to-peer execution channel on BTC
Representative project: ZeroSync
ZeroSync founder Robin Linus released a white paper BitVM: Compute Anything On Bitcoin on October 9. To be precise, it is not a VM, but an attempt to create a Turing-complete computing space whose contracts are stored in Bitcoin. On-chain, but the logic of the contract is executed off-chain. If you believe that the other party has breached the contract, you can initiate a challenge on the chain. If the other party cannot respond correctly, you can take away all the funds in the contract.
The advantage is that Bitcoin can be given Turing completeness without any modifications to the Bitcoin protocol, no new opcodes, no soft forks, and it can be applied at any time.
Its shortcomings are also obvious. First, it only supports transactions between two parties (one party certifies and one party verifies). Second, creating a contract requires creating a large amount of data and pre-signing a large number of transactions. The cost of off-chain information storage is huge.
The following is a brief introduction to the technical logic:
(1) Click to enter the commitment
Point input commitment allows the prover to set the input value 0 or 1 for the logic gate. In this commitment, there are two hash values H(A 0) and H(A 1). The prover needs to reveal a hash preimage, such as A 0 , the input value is set to 0 , and if A 1 is revealed, the input value is set to 1 .
(2) Logic gate commitment
Once you have the input value, you can combine any logic gate in Bitcoin script by combining Bitcoins AND, NOT and other opcodes.
(3) Binary circuit commitment
Turing completeness can be achieved by composing hundreds of millions of logic gates into a binary circuit. In order to commit this binary circuit to the Bitcoin network, all logic gates need to be placed into a leaf node with a Taproot address.
(4) Challenge-response link
It is not enough to commit the circuit on the chain. Both parties need an effective way to verify that the calculation results of the contract are correct. In an ideal world, the contract runs off-chain, and both parties are happy if they are cooperative and have no dispute over the outcome. However, if there is a dispute between the two parties of the transaction, they need to enter the challenge-response link to verify the calculation results and force the channel balance to be distributed through Bitcoin scripts.
Therefore, BitVM is far from being some kind of Bitcoin Rollup or L2, does not have a complete virtual machine execution environment, global state, a high-level language for publishing complex smart contracts, nor does it allow an arbitrary number of users to easily interact with these contracts. Let’s use a very popular example to illustrate: BitVM is like building a giant computer that is larger than a room in an era when everyone can use a mobile terminal.
1.2.9 MoveVM - the product of Facebook’s Web2 genetic inheritance
Representative projects: Aptos, Sui
Move is a programming language for writing secure smart contracts. It was originally developed by Facebook to provide support for the Diem blockchain. After the Diem blockchain project was suspended, projects represented by Aptos and Sui continued to use the Move language. . The biggest feature of the Move blockchain is that data storage uses global storage, consisting of a tree rooted at an account address. Each address can store resource data and module code.
Move has two different types of programs: modules and scripts. Modules are libraries that define structural types and functions that operate on these types. The structure type defines the global storage mode of Move, and the module function defines the rules for updating storage. The modules themselves are also stored in global storage. The script is the entry point of the executable file, similar to the main function in traditional languages, and is a temporary code fragment that is not published in global storage.
To summarize, the Move module is similar to the dynamic library module loaded when the system executable file is run, while the script is similar to the main program. Users can write their own scripts to access global storage, including calling modules, while publishing modules or executing scripts operate through the Move VM.
1.3 Ecological development trends
Now that the EVM network effect is so powerful, the migration of EVM users to non-EVM chain ecology has become the biggest growth point for emerging blockchain projects. This will bring more Dapp composability and greater connectivity in the future. Several years trigger faster user growth.
1.3.1 Wallet front-end compatibility
Onboarding EVM users to non-EVM chains has historically been a major barrier, but the recent launch of Metamask Snap will break this barrier. EVM users can continue to use MetaMask without switching wallets. Thanks to Drifts open source contributions to building an excellent MetaMask Snap implementation, the UX is equivalent to interacting with any EVM chain. Eclipse mainnet users will be able to interact with native applications in MetaMask, or use Solana native wallets such as Salmon.
1.3.2 VM backend compatibility
1.3.2.1 Translator/Compiler
Representative project: Wrap
Warp is a Solidity-Cairo translator that has been developed by Nethermind, a well-known Ethereum infrastructure team. Warp can translate Solidity code into Cairo, but the translated Cairo program often needs to be modified and added with Cairo features (such as calling built-in functions, optimizing memory, etc.) to maximize execution efficiency.
1.3.2.2 Bytecode interpreter/VM compatibility layer
Representative projects: Kakarot, Neon EVM
Kakarot is an EVM bytecode interpreter written in Cairo and implemented in the form of smart contracts deployed on Starknet. It simulates the stack, memory, execution and other aspects of EVM in the form of Cairo smart contracts. Compared with code translation, Kakarot implements the step-by-step implementation of Opcode and Pre-compile behind EVM, and builds components such as Account Registry and Blockhash Registry to perform additional processing on account address mapping, block information acquisition, etc., giving kakarot more capabilities. High native compatibility.
Neon EVM is an EVM that runs as a smart contract and can be deployed on any SVM chain. The Eclipse mainnet itself uses SVM as the execution environment, but brings full EVM compatibility (including EVM bytecode support and Ethereum JSON-RPC) through Neon EVM, and has higher throughput than single-threaded EVM. In addition, each Neon EVM instance has its own local fee market, that is, there is an upper limit on the computing units related to single contract account interaction at a block height (1/4 of the block computing units), so users only need to interact with specific hot contracts Or you need to pay a priority fee when the block is full. In this sense, applications deploying their own contracts can obtain the advantages of approximating application chains, thereby reducing the damage to the user experience, security or liquidity of the entire network caused by congestion of a specific contract interaction tx.
References:
1.“Kakarot: Exploring Starknet’s Road to EVM Compatibility” by Cynic Starknet Astro
2.“BitVM sparks heated discussion, can the Bitcoin network achieve Turing completeness?”, by Haotian
3.https://ethereum.org/en/developers/docs/evm/
4.Starkware technical architecture and ecological review, by Maxlion
5.https://twitter.com/muneeb/status/1712461799327416491
6.Project Research丨Modular High-speed Execution Layer Fuel Research Report, from Web3 CN
8.https://docs.ethscriptions.com/overview/introducing-ethscriptions
9. “Analysis of the First Critical Vulnerability of Aptos Move VM”，by Numen Cyber Labs
10. https://ethereum.org/en/developers/docs/evm/
11.“What Is SVM - The Solana Virtual Machine”，by Squads
12.“Introducing Eclipse Mainnet: The Ethereum SVM L2”，by Eclipse
13.https://john-hol.gitbook.io/bitvm/
14.https://bitvm.org/bitvm.pdf
15.“The different types of ZK-EVMs”，by Vitalik Buterin
16. Cipholio Research Report: Discussing ZkVMs plans and future, by YOLO SHEN, Cipholio Ventures
