Under the wave of Rollup, the VM still has stories to tell

1.1 What is a VM?

A virtual machine (VM) is a building block for virtualizing computing resources, possessing nearly the same functionality as a computer, including running applications and operating systems. The concept of a virtual machine is not new, and this technology is widely used across many technical ecosystems.

In the context of blockchain, a virtual machine (VM) is software that runs programs, often referred to as the runtime environment for executing blockchain smart contracts. Virtual machines typically provide a virtual computing environment by simulating different hardware devices. Different virtual machines can simulate different hardware devices, but they usually include CPU, memory, hard disk, network interfaces, etc. When an on-chain transaction is submitted, the virtual machine is responsible for processing that transaction and updating the blockchain state affected by the execution of that transaction (the current global state of the entire network). The specific rules for changing the network state are defined by the VM. When processing transactions, the VM converts smart contract code into a format that can be executed by node/validator hardware.

The most important core of the VM is LLVM (low-level virtual machine), which can be seen as the most important core of the compiler. The diagram shows the operation scheme of the original EVM, where smart contracts are transformed through LLVM IR intermediate code into Bytecode. This Bytecode is stored on the blockchain, and when a smart contract is called, the Bytecode is converted into the corresponding Opcode, which is then executed by the EVM and node hardware.

1.2 Mainstream VMs

1.2.1 EVM------A common stone in blockchain VMs, EVM takes the lion's share

Representative projects: Optimism, Arbitrum

As the blockchain ecosystem with the highest developer and user activity in the industry, the Ethereum Virtual Machine (EVM) is a stack-based virtual machine that provides a virtual computing environment by simulating hardware devices such as CPU, memory, storage, and stack to execute smart contract instructions and store the state and data of smart contracts. The instruction set of EVM includes various opcodes, such as arithmetic operations, logical operations, storage operations, jump operations, etc.

The memory and storage simulated by EVM are devices used to store the state and data of smart contracts. EVM treats memory and storage as two different areas, accessing the state and data of smart contracts by reading and writing to memory and storage.

The stack simulated by EVM is used to store the operands and results of instructions. Most instructions in EVM's instruction set are stack-based, reading operands from the stack and pushing results back onto the stack.

The design process of EVM is clearly bottom-up, first determining the simulated hardware environment (stack, memory), and then designing its own set of assembly instruction sets (Opcode) and bytecode (Bytecode) based on the corresponding environment. The Ethereum community has designed two compiled high-level languages for EVM execution efficiency—Solidity and Vyper. Solidity needs no introduction, while Vyper was designed by Vitalik to address some shortcomings in Solidity, but it did not gain much adoption in the community and gradually faded from the historical stage.

1.2.2 zkEVM------I want it all: Compatibility with EVM environment + support for global state root conversion to generate zk-proof

Representative projects: Taiko, Scroll, Polygon zkEVM

Since EVM was not designed with zk-proof computation in mind, it has characteristics that are not friendly 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 computation, allowing the execution process of EVM to be verified more efficiently and at a lower cost through zk-proof/validity-proof. Compared to OP Rollup execution layers that simply replicate EVM, building a ZK-friendly EVM is an additional challenge for ZK Rollup.

ZK-rollups are not easy to be compatible with the Ethereum Virtual Machine (EVM). Proving general EVM computations in circuits is more difficult and resource-intensive than proving simple computations (such as token transfers described earlier).

However, advancements in zero-knowledge technology have reignited interest in wrapping EVM computations in zero-knowledge proofs. These efforts aim to create a zero-knowledge EVM (zkEVM) implementation that can effectively 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 can verify the correctness of operations involving virtual machine states (memory, stack, storage) and the computation itself (i.e., did the operation call the correct opcode and execute it correctly?).

The idea is appealing, but reality is harsh. Currently, Rollups find it difficult to achieve both ZK-friendliness and EVM compatibility (or even equivalence). They must either fully replicate the Ethereum L1 execution layer, including hashes, state trees, transaction trees, precompiles, etc., so that the Ethereum L1 execution client can be used as is to process Rollup blocks; or abandon EVM compatibility and recreate existing opcodes for proof/verification in circuits, thus allowing the execution of smart contracts.

1.2.3 zkVM------You can't have your cake and eat it too: A non-EVM virtual machine oriented towards zk-proof efficiency

Representative projects: Starknet, Zksync, RISC ZERO

zkVM abandons EVM compatibility, focusing on data proof and state updates, finding a common ground between cryptography and high-level languages to provide a universal framework for various applications.

Starkware, having started early in the entire ZK field, has a substantial technical accumulation and holds a certain technological lead. It represents a typical ZK-centric technical architecture, having built Cairo VM and the Cairo language around ZK. Its downside is that the learning curve for Cairo is relatively high.

ZKsync's framework accommodates both EVM and ZK characteristics, merging Solidity with its self-developed circuit language Zinc, unifying the two at the IR level within the compiler. Its advantage lies in the LLVM core of the compiler, which can accommodate multiple languages.

RISC Zero uses the RISC-V architecture to build a simulator that allows programmers to write programs for zkVM using general-purpose languages like Rust, C/C++, and Go, meaning application logic is not limited to what can be expressed in Solidity, allowing for the writing of chain-agnostic code.

1.2.4 Privacy zkVM------zk-friendly + native privacy support attempts to ignite new sparks in the ecosystem

Representative projects: Aleo, Ola, Polygon Miden

As a public ledger system, all transactions on the blockchain are conducted on-chain, which means that state changes containing asset information related to addresses or accounts are public and transparent. Therefore, in addition to focusing on scalability solutions, some blockchain teams believe that the next key feature to achieve is privacy.

Privacy zkVM, in addition to supporting zk-friendly scalability, has native privacy features supported by its programming language, enabling developers of upper-layer applications to create privacy-related dapps, which will bring new application scenarios and grand narratives, such as completely solving the MEV problem and ensuring user data ownership. Of course, the complexity of designing Privacy zkVM requires a larger technical team for implementation, and it may take several more years to realize.

1.2.5 SVM------After the tide recedes, there are still embers: An execution environment that has reached extreme performance design

Representative projects: Eclipse Mainnet, Nitro, MakerDAO Chain (maybe)

SVM, or Solana Virtual Machine, focuses on a high-performance execution environment, with smart contracts primarily written in Rust. Compared to the single-threaded computing of EVM and EOS WASM execution environments, SVM achieves concurrent execution of non-overlapping transactions and transactions that only read the same state by requiring Solana transactions to describe all states read or written during execution.

Additionally, to achieve fast verification/broadcast of large transaction blocks, the transaction verification process on the Solana network widely uses pipelining optimizations common in CPU design. This is to accommodate a stream of input data processed in a series of steps, with each step handled by different hardware. A typical analogy is a washing machine and dryer, which sequentially wash/dry/fold multiple batches of clothes. Washing must occur before drying, and folding must occur before drying, but each of these operations is executed by a separate unit.

Moreover, SVM is based on registers and has a much smaller instruction set than EVM, making it easier to prove SVM execution in ZK. For optimistic Rollups, the register-based design can more easily set up checkpoints.

1.2.6 Fuel VM------Buff stacked: A parallel virtual machine under the UTXO framework

Representative projects: Fuel

Fuel VM is an improvement based on EVM, Solana, WASM, BTC & Cosmos technology frameworks, with the following characteristics compared to EVM:

Most uniquely, Fuel not only sets up access lists similar to SVM, allowing for non-overlapping transaction parallel execution, but also adopts the UTXO model, dividing tokens into UTXO and contract UTXO, further improving access efficiency and computational throughput.

Additionally, Fuel VM provides a powerful and smooth developer experience through its domain-specific language Sway and supporting toolchain Forc, retaining the advantages of smart contract languages like Solidity while incorporating paradigms introduced in the Rust tool ecosystem.

In the future, Fuel VM will also implement upgrades to the Sway language, including compiler optimizations regarding bytecode size, support for more backends (with EVM backend already in development), more economical abstractions, migration of more applications from Solidity/Vyper to Sway, and improved compiler-level reentrancy analysis.

1.2.7 ESC VM------The successor of Ordinal/Smartweave: A computational layer on Ethereum

Representative projects: Ethscriptions Protocol

ESC VM, or Ethscriptions Virtual Machine, is a smart contract solution proposed by the Ethscriptions Protocol. The Ethscriptions Protocol itself is a protocol on the Ethereum chain similar to BTC Ordinals, focusing on exploring low-cost alternatives to smart contracts and L2.

Ethscriptions allow users to bypass smart contract storage and execution at a very low cost, performing calculations on the calldata applied in Tx according to pre-agreed protocol rules. In simple terms, as long as a successful Ethereum transaction occurs, if its calldata meets the specified valid data specifications & is unique & the "to" address is not 0, it can be considered a valid Ethscription creation, with the "from" address as the creator and the "to" address as the owner.

At the design outset, each Ethscription leaned more towards the form of an NFT, such as an image NFT, directly writing the image content into the calldata in Base64 format:

Recently popular eths refer to Ethscriptions created based on the BRC-20 protocol specifications:

The smart contracts introduced by ESC VM are called "Dumb Contracts," serving as a logical contract publicized but not interacting on-chain in EVM form. Additionally, ESC VM introduces a special format called "computer commands," where Ethscriptions created using this format will be recognized by ESC VM to interact with Dumb Contracts, such as Deploy - deploying a Dumb Contract, Call - calling a Dumb Contract.

This solution has some limitations. First, the functions of "Dumb Contracts" are not payable, meaning if you want to send ETH through a Dumb Contract, you must go through a "bridge contract," which itself poses risks of power abuse and asset theft; second, there are entry barriers in the ecosystem, not allowing arbitrary creation of Dumb Contracts, as their code needs to be defined through governance proposals of the Ethscriptions Protocol.

In summary, ESC VM uses Ethereum L1 as a data storage layer, building a computational layer on top of it, implementing contract logic, contract calls, and other data content within the calldata of Ethereum transactions. The global state consensus of ESC VM is the consensus of the ESC VM client, similar to the logic of Arweave's SmartWeave, except that SmartWeave's data storage layer is Arweave.

1.2.8 Bit VM------An interesting research experiment: A peer-to-peer execution channel on BTC

Representative projects: ZeroSync

Robin Linus, founder of ZeroSync, released a white paper on October 9 titled "BitVM: Compute Anything On Bitcoin." To be precise, it is not a VM but attempts to create a Turing-complete computational space, with contracts stored on the Bitcoin chain, but the logic execution of the contracts occurs off-chain. If one party believes the other has defaulted, they can initiate a challenge on-chain, and if the other party cannot respond correctly, the initiating party can take all funds in the contract.

Its advantage lies in granting Bitcoin Turing completeness without requiring any modifications to the Bitcoin protocol, no new opcodes, and no soft forks, making it applicable at any time.

Its drawbacks are also evident: it only supports transactions between two parties (one party proves, the other verifies), and creating a contract requires generating a large amount of data and pre-signing numerous transactions, leading to significant off-chain information storage costs.

Here is a brief introduction to the technical logic:

(1) Point Input Commitment

Point input commitment allows the prover to set input values of 0 or 1 for logic gates, with two hash values H(A0) and H(A1) existing in this commitment. The prover needs to reveal a hash preimage, for example, A0, setting the input value to 0; if A1 is revealed, the input value is set to 1.

(2) Logic Gate Commitment

With the input values set, arbitrary logic gates can be combined in Bitcoin scripts using operations like AND and NOT.

(3) Binary Circuit Commitment

By combining billions of logic gates into a binary circuit, Turing completeness can be achieved. To commit this binary circuit to the Bitcoin network, all logic gates need to be placed into a leaf node of a Taproot address.

(4) Challenge - Response Phase

Simply committing the circuit on-chain is not enough; both parties need an effective way to verify whether the contract's computation result is correct. Ideally, if the contract runs off-chain and both parties cooperate with no disputes over the result, everyone is happy. However, if there is a dispute, a challenge-response phase is needed to verify the computation result and enforce the distribution of channel balances through Bitcoin scripts.

Therefore, BitVM is far from a Bitcoin Rollup or L2; it does not possess a complete virtual machine execution environment, global state, or high-level language for publishing complex smart contracts, nor does it allow any number of users to easily interact with these contracts. To put it simply, BitVM is like building a giant computer larger than a room in an era where everyone can use mobile terminals.

1.2.9 MoveVM------A product inheriting Facebook Web2 genes

Representative projects: Aptos, Sui

Move is a programming language for writing secure smart contracts, originally developed by Facebook to support the Diem blockchain. After the Diem blockchain project was halted, projects represented by Aptos and Sui continued to use the Move language. The biggest feature of Move blockchain is that data storage uses global storage, composed of a tree rooted in account addresses, where each address can store resource data and module code.

Move has two different types of programs: modules and scripts. Modules are libraries that define structure types and functions that operate on these types. Structure types define Move's global storage model, and module functions define the rules for updating storage. Modules themselves are also stored in global storage. Scripts are entry points for executable files, similar to the main function in traditional languages, representing temporary code snippets not published in global storage.

In summary, Move modules are similar to dynamic library modules loaded at runtime by system executable files, while scripts are akin to the main program. Users can write their own scripts to access global storage, including calling modules, while publishing modules or executing scripts is done through the Move VM.

1.3 Ecosystem Development Trends

With the current strong network effects of EVM, the migration of EVM users to non-EVM chain ecosystems has become the biggest growth point for emerging blockchain projects, which will bring more Dapp composability and greater connectivity, potentially triggering faster user growth in the coming years.

1.3.1 Wallet Frontend Compatibility

Bringing EVM users to non-EVM chains has always been a major obstacle, but the recently launched Metamask Snap will break this barrier. EVM users can continue to use MetaMask without switching wallets. Thanks to Drift's open-source contributions, an excellent MetaMask Snap implementation has been built, providing a user experience 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 (like Salmon).

1.3.2 VM Backend Compatibility

1.3.2.1 Transcoders / Compilers

Representative project: Wrap

Warp is a Solidity-Cairo transcoder, currently developed by the renowned Ethereum infrastructure team Nethermind. Warp can translate Solidity code into Cairo, but the translated Cairo program often requires modifications and the addition of Cairo features (such as calling built-in functions, optimizing memory, etc.) to maximize execution efficiency.

1.3.2.2 Bytecode Interpreters / VM Compatibility Layers

Representative projects: Kakarot, Neon EVM

Kakarot is an EVM bytecode interpreter implemented as a smart contract written in Cairo, deployed on Starknet. It simulates aspects of EVM's stack, memory, execution, etc., in the form of Cairo smart contracts. Compared to code transcoding, Kakarot implements EVM's underlying Opcode and Pre-compile on a line-by-line basis and builds components like Account Registry and Blockhash Registry for additional handling of account address mapping and block information retrieval, giving Kakarot higher 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 its execution environment, but through Neon EVM, it brings complete EVM compatibility (including EVM bytecode support and Ethereum JSON-RPC) and higher throughput than single-threaded EVM. Additionally, each Neon EVM instance has its own local fee market, meaning that there is a limit on the computational units related to interactions of a single contract account at a specific block height (1/4 of the block's computational units), so users only need to pay a priority fee when interacting with specific hot contracts or when the block is full. In this sense, applications deploying their own contracts can gain advantages similar to application chains, thereby reducing the disruption to the overall network user experience, security, or liquidity caused by congestion from interactions with a specific contract transaction.

ChainCatcher reminds readers to view blockchain rationally, enhance risk awareness, and be cautious of various virtual token issuances and speculations. All content on this site is solely market information or related party opinions, and does not constitute any form of investment advice. If you find sensitive information in the content, please click "Report", and we will handle it promptly.