Architecture

As mentioned on one of the previous pages, MultiVM currently offers a hybrid rollup solution and will provide a fully ZK rollup solution in the future. This approach allows MultiVM to integrate system security through ZK proofs now, but the full potential of ZK rollup will be realized after migrating from hybrid rollup to ZK rollup. These two architectures are very similar, and their high-overview descriptions can be found on the sections hybrid architecture and ZK architecture below.

Hybrid architecture

At the high-overview level, the main components of the system can be represented as shown in the diagram below.

At the top level, the following main three layers of the system can be identified:

• Settlement Layer - this layer includes everything necessary to ensure the security of the entire system at the desired level. The security level of the entire MutliVM system will be entirely inherited from the security level of the settlement layer, so it is logical to choose Ethereum blockchain as the settlement layer. At first glance, it may seem that there are no limitations on choosing a settlement layer, but this is not the case. One of such critical limitations is the size of data that can fit into it. In terms of MultiVM, the data that needs to be stored in the blockchain are ZK-STARK proofs, which have a very large size and cannot fit into the Ethereum blockchain. One possible solution is to convert ZK-STARK proofs into ZK-SNARK, which are lighter in weight, but their security remains the same since they are generated from ZK-STARK proofs. After this conversion, ZK-SNARK proofs can be easily written into the Ethereum blockchain.

• Core Layer is a module that handles standard operations for any blockchain. Its tasks include pre-processing transactions, forming transactions into blocks, managing accounts, deducting fees, and so on. Any component in this layer can be run by any user on their computer. Essentially, this layer corresponds to the same as standard Ethereum nodes and clients, except that the transaction processing mechanism is modified for the rollup solution, and part of the transaction execution on the EVM is moved to a separate execution layer.

• Execution Layer - a unique and key part of the system. It consists of multiple ZK VMs that can interact with each other using cross-VM calls. Each VM is unique based on specific parameters and is optimally suited for various tasks.

As can be seen from the diagram above, designing a MutliVM system implies the modularity of the blockchain. This allows the entire system to be flexible and scalable. Such an architecture will be very useful when migrating from a hybrid rollup solution to a zk rollup solution.

Also the following main components of the system can be identified:

JSON-RPC

The component is the entry point of the system for users. Each transaction goes through this module for further routing in the system, regardless of whether it was initiated directly in the system or on the settlement layer. JSON-RPC is fully compatible with the standard Ethereum JSON-RPC client. Therefore, working with auxiliary services such as Metamask, explorers, etc., is already integrated.

MultiVM Environment

The presence of multiple virtual machines in one location increases the flexibility with which developers and projects can develop the ecosystem. At the same time, the interaction of regular users with the ecosystem will not have any differences. Moreover, users may not even know which VM will execute their transaction. Each VM can have different characteristics and features. Here are some of them:

1. Programming language (solidity / rust / c++ / go / python / …).

2. Execution cost. The higher the performance of the VM, the less gas will be required to be paid by the user.

3. Knowledge of specific frameworks by developers. For example, smart contracts on Near or Solana are written in Rust, but the main challenge in their development is not knowing Rust, but rather understanding the blockchain’s specifics and its SDK. Therefore, for instance, the ability to run native Solana contracts greatly facilitates the integration process of the product into our system.

4. Ability to dynamically add new VMs. Any VM that meets the following requirements can be added as a part of MultiVM environment:

   • the VM is zero-knowledge 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 the run;
   • the VM has the capability to retrieve the spent cycles and limit the maximum number of cycles.

Each of VMs is built either on top of RISC0 or integrated into RISC0.

Rollup Producer

Rollup producer, together with verifier producer, forms the foundation for the entire rollup system. The rollup producer acts as an intermediary between the settlement layer contract and the transaction execution layer. After the transactions are executed in the MultiVM environment, they are sent to the rollup producer, where they are batched, transformed into a compressed form, and recorded in the DA contract. In the future, these data in the DA contract will be used for verifying proofs of correct transaction execution. To reduce the cost of recording this data in the DA contract, it is stored in calldata instead of the storage contract. As a result, the DA contract will receive these data (we can unquestionably trust them), but additional money does not need to be spent on their storage. While the hybrid rollup solution is used in the MultiVM system, it is also necessary to use a simple consensus among rollup producers to reduce the likelihood of errors or fraudulent actions. The need for this consensus will be completely eliminated when migrating to zk rollup.

Verifier Producer

The verifier producer is a part of the system responsible for generating and verifying proofs. In case the verifier producer has doubts that a transaction was executed correctly, it initiates the “transaction verification process” through the DA contract. Initiating this process requires locking a large amount of money. If the initiation of this process is incorrect, the verifier producer will lose this money. If the initiation of this process is correct, the verifier producer will receive a reward. This reward will be taken from the rollup producers who mistakenly confirmed the correctness of the transactions.

After initiating the “transaction verification process”, the verifier producer requests data from the rollup producer. This data can be trusted as it can be compared with the data inside the DA contract. After that, the verifier producer must execute all transactions again, but this time, generating a ZK proof. Using this proof (it’s called a fraud proof), the verifier producer can prove to everyone that the transaction was executed incorrectly.

In the future, when there is a migration from a hybrid rollup solution to a zk rollup in MultiVM, the need for separating the two types of producers (rollup and verifier) will disappear, and they can be combined into one module.

DA Contract

The DA contract, as its name suggests, ensures the data availability of our system. In other words, it allows us to request all the necessary data to verify proofs. Actually to verify the proof, we do not need the transaction list. However, we must record these transactions in calldata so that anyone can index all the data from the calldata in case all rollup producers fail, obtain the latest proof, and continue to maintain the operation of our system or be able to withdraw all the funds. To ensure that we transmitted all the transactions correctly, it is also necessary to include a hash of the sum of these transactions in the proof.

ZK Bridge Contract

In almost all bridge systems, bridges are one of the most vulnerable points because a huge amount of funds is locked in them - this can be confirmed by looking at the list of the largest DeFi hacks. Most bridges currently operate on the principle of voting and trust: if the majority of participants confirm that funds A have arrived on blockchain C1, then the funds can be unlocked on blockchain C2. With the development of ZK technologies, the possibility of making this process more secure has emerged.

So ZK bridge is a crucial element that bolsters security measures. Apart from serving as a regular bridge, it leverages ZK technology to offer an additional protective layer for the entire system. Consequently, regular users can confidently access and engage with the system while ensuring their security.

ZK architecture

As can be seen from the diagram, the ZK rollup architecture differs only in the fact that the generation of ZK proofs and their verification on the settlement layer occurs in the rollup producer. But another not-so-obvious difference is the continuity of these processes. In hybrid rollup, the generation of ZK proofs occurs upon request from the verifier producer, whereas in this architecture, any change in the system results in ZK proofs of these changes. This ensures security at the settlement layer level. Obviously, the rollup producer must be very powerful, as the process of generating ZK proofs is currently very slow. It is well-suited for parallel execution, but only for one proof. Parallel generation of multiple proofs that depend on each other is still a challenging task, even from a theoretical standpoint.

Increased performance requirements for rollup producers, however, add quite important advantages. In this architecture, there is no need to re-execute transactions to finalize them, only to verify the ZK proof, which is a relatively simple operation. In other words, transaction hard-confirmation can be hundreds of times faster than in a hybrid architecture. Additionally, this leads to a faster and more convenient bridge functionality for users.