MultiVM is built on top of Risk Zero zero-knowledge virtual machine called zkVM. It lets you prove correct execution of arbitrary Rust code. We selected zkVM as our base layer to avoid creating everything from scratch. The Risk Zero solution has all the primitives we need.

The zkVM is essentially a CPU, in particular an implementation of the RISC-V architecture, serving as the foundation for other VMs.

The main core consists of two parts — Host and Guest.

When interacting with a contract on a Virtual Machine, the process involves a Node that securely passes the input data to the desired VM execution environment, receiving a verifiable execution receipt in return. Anyone with a copy of the receipt can verify the guest program's execution and access public outputs.

Meta Contract

For the sake of interoperability there's a special system program that provides communication and interaction between runtimes. We call it Meta Contract, since it serves as the entry point for any transaction. The main 4 modules it consists of:

• Account Management — a module responsible for public keys management, signatures, managing user balances and account aliases.
• Shared State — VM runtime used only as an execution layer. The contract in the execution environment receives input data, and produces output changes, so the Meta contract module modifies the state based on the results of execution.
• Block formation module responsible for verifying the correctness of cross-VM calls, validating storage changes, verifying transaction signatures, gas cycles, and other auxiliary checks.
• Adapters / Wrappers — it’s a unifying middleware standard between specifications of different runtimes. The most basic example is the ERC20 Token Standard, which can be accessed from different VMs.

Cross-VM Calls / Messaging

Since we have multiple VMs, we implement a Cross-VM messaging system. This means that we have a way for different VMs to communicate with each other. When a contract wants to call another contract from another VM — a Cross-VM call occurs. This is achieved by "interrupting" host-level control and creating a transaction "fragment". After execution, all such fragments are collected, and a STARK ZK proof can be created for each one, or can be merged into one Master ZK Proof. This is the key feature of Cross-VM calls — the ability to fully validate the transaction at all stages.

Execution layers

A little bit more about execution layers. For now we support 3 of them:

• EVM is a primary runtime. All transactions are executed sequentially because of this.
• Fragment VM — is a base layer of our core, so we support ELF binaries. You can write your custom Rust contracts using our SDK.
• Solana VM — using our SDK Wrapper we are running Solana contracts.

It’s possible to have an unlimited amount of VM, until they support special methods and instructions, to be executed inside the zkVM runtime. Parallel execution will be possible, when we solve the state collision problem. By the time of the mainnet launch, transactions on VMs that support parallel execution, are expected to be run in parallel. However, any Cross-VM messaging affecting the EVM must be executed sequentially.

A little note about RPC: Extended JSON RPC, responsible for transaction routing and emulating Ethereum JSON RPC specification. Metamask support was our priority from the start as we're aiming for a big amount of EVM dApps. Other wallet integration is possible by adding and supporting the necessary RPC methods.

Gas