Introduction
In this article, We will dive into the following topics as well as solutions we offer with MultiVM:
1. Exploring the function of MultiVM as an execution layer in a modular blockchain and its implementation.
2. Understanding the unique aspects of MultiVM rollup compared to other rollup solutions.
3. Illustrating a clear perspective on the user and developer experience.
Motivation
In the ever-growing array of blockchains with different architectures and virtual machines (VMs), thousands of projects are tied to the blockchain where they initially started building their products. While it would be beneficial for most projects to deploy their products on multiple blockchain ecosystems, the cost, time, and resources required make it impractical. Consequently, going multichain currently has a negative expected value for most projects. One of the main reasons for this is the disparity in VMs across different blockchains. Unless a project has developed their product using the EVM, it is nearly impossible to scale across different ecosystems. The main hurdle lies in the differences between the VMs, as they require different sets of instructions and often operate on different programming languages. In simple terms, projects would have to spend millions of dollars to deploy their products on various chains.
As a result, numerous infrastructure providers have started developing cross-chain technology named “bridges” to facilitate the transfer of data and assets between different blockchains. However, bridges come with their own set of issues. They are often centralized, making them susceptible to censorship, and they represent a major target for hacks, resulting in billions of dollars’ worth of digital assets being stolen. Additionally, bridges impose relatively high fees on cross-chain transactions and are notoriously slow in transferring assets, leading to a poor user experience due to these disadvantages and other minor nuances.
After intensive R&D we are ready to present a new, innovative solution to improve the lives of projects and users alike, by an order of magnitude:
The first Multi-Virtual-Machine execution environment within a single blockchain, or simply MultiVM.
Now, let’s further share a little introduction to the basic components.
Basics of Layer 2s
Rollups are layer 2 networks that process transactions on an alternative blockchain and then transfer the transaction data back to the main blockchain, mainly to provide a lower transaction cost for the user. They are part of several scaling solutions for blockchains like Ethereum which provide great security and decentralization, but are therefore costly and relatively slow. There are two main types of rollups: Optimistic rollups, which assume all transactions are valid and allow users to contest fraudulent transactions within a certain time frame — in most cases seven days — and ZK-rollups, which use Zero-Knowledge proofs to validate transactions and allow faster withdrawals. ZK-rollups are generally more mathematically complex but could support a wider range of applications. However, rollups also come with risks, including the risk of faulty smart contracts, censorship receptivity through centralization of key parts of the stack, such as centralized sequencers. To use rollups on Ethereum, users need to bridge their funds to the Layer 2 network, complete transactions, and if desired bridge their funds back to the mainnet.
In most cases the L1->L2 bridges are amongst the best designed in the industry, especially the enshrined ZK-bridges, which provide greater levels of security.
Basics of modular blockchains
Modular blockchains are blockchains that focus on one or two core functions while leaving the rest to developers to build on top of them. This approach allows for more scalability, flexibility, and cost efficiency compared to monolithic chains, which combine all the core functions in one. There are four core responsibilities or layers of a blockchain: consensus, execution, settlement, data availability. Modular blockchains offer benefits such as lower development and launch costs, flexibility in combining different layers, and improved scalability. However, there are challenges in terms of security and complexity. Despite these challenges, the future of the blockchain industry is most likely headed towards modularity.
Introduction to Risc Zero
zkVM is an experimental software that allows users to prove correct execution of Rust code. It enables the building of zero-knowledge applications that leverage existing Rust packages. The software provides a developer-friendly experience and offers an open-source prover that can prove computations of any size on standard consumer hardware. With zkVM, it is possible to generate proofs locally or remotely using Bonsai. The core of a zkVM application is the guest program, which is compiled to an ELF binary. The executor runs the binary and records the session, while the prover checks and proves the validity of the session, outputting a receipt. This receipt can be used to verify the execution of the guest program and read its publicly shared outputs. The zkVM is designed as a verifiable computer that works like a real embedded RISC-V micro-processor, allowing for limitless computations through the use of continuations.
Introduction to MultiVM
Let’s now move on to MultiVM. So, what exactly is MultiVM?
MultiVM serves as an execution layer within a modular blockchain. In simpler terms an execution layer is a crucial component responsible for executing transactions, calculating gas, verifying transaction validity, managing accounts, and more. Execution layers could be utilized in other rollups as well. That’s why it is worth mentioning that this aspect of MultiVM primarily interests other projects that may utilize the MultiVM execution layer for their own specific purposes, rather than ordinary users.
For ordinary users, the next part of MultiVM, currently referred to as MultiVM Rollup, holds greater significance. As the name implies, MultiVM Rollup is MultiVM’s particular implementation of a rollup on top of the MultiVM execution layer.
In the upcoming sections in this article, we will delve into the intricate mechanics of these two parts of MultiVM, providing a comprehensive understanding of their functionality.
Let’s multi forward!
Multi-Virtual-Machine Execution Layer
Inside most blockchains, there is a core responsible for executing applications. This core is represented by a Virtual Machine (VM) — a program that can execute a set of predetermined instructions. Most blockchains typically have one VM. This greatly limits the interaction between blockchains with different VMs, as the set of instructions of each VMs varies significantly. However, in theory, this is possible. Examples of such projects already in circulation are Aurora and Neon. But these are very inflexible solutions in terms of scalability to new blockchains. To clarify, Aurora only supports interactions between Ethereum and NEAR. Extending this project’s capabilities to include more networks like Solana will entail rewriting almost all the code, since this was most likely not included in the architecture initially. This is where MultiVM comes in.
MultiVM acts as an execution layer, providing an environment for decentralized app execution. Its main feature is the presence of multiple virtual machines, each operating according to its predefined rules. For example, the Ethereum Virtual Machine (EVM) has its own set of instructions, and the Solana Virtual Machine (SVM) has its own. Using our invention of Cross-VM-Call mechanisms within MultiVM, it becomes possible to invoke SVM instructions from EVM and vice versa. Now, imagine having not just 2, but 10 different virtual machines. And each VM can invoke any other VM, with developers not even needing to know which VM they are calling. All these mechanics are already built into MultiVM’s Meta Contract. The Meta Contract manages calls between different VMs, processes their results, and obtains the final transaction result. Thus, our unique Cross-VM-Call system, together with the Meta Contract, allows the system to scale to host N number of VMs in the same execution layer and thereby for applications written in different languages and with different architectures to seamlessly interact with each other. In the first version, we integrated 3 different virtual machines with our Meta Contract:
- Fragment VM — MultiVM’s native virtual machine based on Risc Zero zkVM
- Ethereum VM
- Solana VM
But in the future the number of VMs will increase. The way virtual machines interact with each other in the execution layer is quite intuitive and easy to grasp.
All of these together provides unlimited flexibility and a 10x improvement in terms of development experience for dApp developers.
Example:
One of the main features of DeFi is the ability to connect applications together like LEGO blocks. This has led to the emergence of new products within the DeFi sector, such as liquid staking and DEX aggregators. MultiVM extends this capability not at the application layer, but at the execution layer. For example, it becomes possible to connect Solana’s Jupiter AMM contract with Ethereum’s Uniswap AMM contract via a DEX aggregator contract written in Fragment VM. Isn’t that cool? 😎
Sequential vs Parallel vs Asynchronous VMs
Sequential, parallel, and asynchronous virtual machines are three different approaches to running multiple sets of transactions simultaneously. Here’s an overview of their differences:
1. Sequential VMs: A virtual machine executes transactions in a sequential manner. This means that each set of transactions needs to be completed before the next one can start. Sequencing ensures that all transactions are executed in a specific order. This approach might be suitable when there are interdependencies between transactions, and a specific sequence needs to be followed — this approach is used by Ethereum.
2. Parallel VMs: In the context of virtual machines, parallel virtual machines execute transactions concurrently rather than sequentially. Each transaction runs independently and can be processed by different validators at the same time. This approach can significantly improve performance and efficiency for transactions that can be run in parallel — this approach is used by Solana.
3. Asynchronous VMs: Asynchronous computing refers to the execution of transactions independently without a fixed time-based relationship or dependency between them. Asynchronous virtual machines operate in a similar manner, where different virtual machines run transactions independently without waiting for a specific order or synchronization. This allows for more flexibility and efficiency in executing transactions, as they can be processed whenever resources are available — this approach is used by NEAR.
All VMs inside MultiVM must belong to the same execution type. In other words, all virtual machines must be either sequential, parallel, or asynchronous. This is the initial restriction when adding a VM to MultiVM. It is a quite strong limitation, but there is nothing stopping us from converting the execution of all virtual machines to sequential. In this case, the throughput of the entire system will be determined by the throughput of the slowest VM (most likely EVM).
In order to avoid bottlenecking the system, the parallel transaction execution approach used in Monad will be employed as an optimization to its current system in the coming months.
Zero-knowledge VMs
The second limitation when adding a VM to MultiVM is the support for generating zero-knowledge proofs when executing transactions. Any VM that meets the following requirements can be added as a part of MultiVM environment:
- The VM is zero-knowledge compatible in terms of being able to generate proofs of execution and having fast enough algorithms to verify them;
- The VM can perform execution interruptions while saving the state and then continue to run;
- The VM has the capability to retrieve the spent cycles and limit the maximum number of cycles.
MultiVM Rollup
The MutliVM Rollup is the implementation of a ZK L2 solution, built on top of the MultiVM execution layer. Essentially, this is the first product that will be integrated with the MultiVM execution layer. The architecture of this rollup is similar to the architectures of many other ZK rollups (Starknet, Mantle, Scroll, Polygon zkEVM) with some differences in specific components like the enshrined bridge and ZK fraud proofs.
Let’s briefly go through the components of this system:
- RPC: RPC implements the JSON RPC protocol for interacting with the MultiVM environment. It uses the standard implementation of the Ethereum JSON RPC client, so all wallets, development environments, and other services supporting this implementation will be available in MultiVM out-of-the-box.
- DA Services: DA services ensure the availability of data in our system. In other words, they allow us to request all the necessary data to verify proofs. Although the transaction list is not needed to verify the proof, we must record these transactions in calldata so that all the data can be indexed in case of failures from all rollup producers. This allows the latest proof to be obtained and ensures the continued operation of our system or the ability to withdraw all funds.
- Settlement Layer (Ethereum L1): This layer includes everything necessary to ensure the security of the entire system at the desired level. The security level of the entire MultiVM system will depend entirely on the security level of the settlement layer, so it makes sense to choose the Ethereum blockchain as the settlement layer.
- Enshrined Bridge: This part is the most interesting and unique in the MultiVM Rollup architecture compared to other architectures. The Enshrined Bridge is a bridge that enables users to make deposits/withdrawals in MultiVM in a truly secure way thanks to ZK (Zero Knowledge). Each transaction in the bridge is processed in the same way as any other transaction in the system, so in case of any errors, the system guarantees a refund to the user. More details about the bridge will be described in the next article.
- ZK Fraud Proofs: The process of detecting and reporting fraud on MultiVM Rollup involves replaying the state on a local machine, comparing it with the state on Ethereum, initiating a verification process, generating a ZK proof of fraud using a Risc Zero, verifying the proof on-chain, and entering a state recovery mode if fraud is proven. Unlike the usual approach in optimistic rollup solutions, there is no need for every node to re-execute all transactions to confirm any fraudulent activity. A single node can perform this task, providing undeniable ZK proof of whether the state is correct or incorrect.
Summary
MultiVM is an execution layer within a modular blockchain that offers unique interoperability between multiple VMs, such as the EVM and SVM, using Cross-VM-Calls. Additionally, MultiVM supports zero-knowledge VMs that can generate proofs of execution and verify them. MultiVM also includes the MultiVM Rollup, which is its implementation of ZK rollup, offering increased scalability and flexibility for users and builders.
In the next articles topics covering more details about the MultiVM architecture, ecosystem and business model will be discussed.
Up until then, keep in mind:
More VMs -> More Products -> More Users -> More Value!
