Multivm: Specifications

In the previous article, we discussed the basic architecture overview of MultiVM; what it is, what components it consists of, and who may find it interesting. In this article, we will go much deeper and explore what unique experience this will bring to users and what happens to the transaction inside the Meta Contract during cross-VM calls.

This article will be divided into two parts:

1. MultiVM specifications.
2. MultiVM ZK Fraud proof system.

MultiVM Specifications

When integrating new VMs into MultiVM, various issues may arise. Below, we will discuss some of the most interesting ones from the perspective of a cryptocurrency enthusiast. To simplify, we will only consider 2 VMs in all paragraphs below: Ethereum and Solana. The logic applies fully to a greater number of VMs as well.

Address management

An Ethereum address is generated using this method, and it looks something like this: 0xc1ec9Ab40EF6020e4f04D5e12269284347B29b55.

A Solana address is generated using this method, and it looks something like this: C1ZEjo6Wftg7F3mbjyVG1bdcMBtwNoMYYJcAajibwZLB.

Different cryptographic methods ⌲ different accounts / wallets / public keys.

In the first article, we mentioned that users can seamlessly interact with any contracts. But how can I interact with a Solana contract if I have an Ethereum address, which looks different from a Solana public key? The answer is simple: Accounts mapping. Each new user can link all accounts supported by different VMs within MultiVM. The linking is done through signature verification, ensuring that one cannot take over someone else’s account. This process only needs to be done once, before the first transaction. It is essential to link only two accounts: the Ethereum address and the MultiVM account. Linking other accounts is optional. Even without linking accounts for other VMs, one can still interact with all contracts on any VM. Account mapping is managed by the Meta Contract, making all this data entirely on-chain.

Transaction Flow

The transaction format that the MultiVM Node can accept matches the transaction format on their “original chains.” In other words, the MultiVM Node is capable of working with both Ethereum transactions and Solana transactions intentionally to support all the infrastructure around each specific VM (wallets, JSON RPC clients, developer IDEs, etc).

Before a transaction reaches the Meta Contract, it goes through the standard path through JSON RPC and Sequencer components. Since this is no different from implementations in other rollup solutions, we won’t go into this part here. It’s more interesting to see what happens to the transaction inside the Meta Contract.

As soon as transactions enter the Meta Contract for further execution, they are transformed into a Call entity. A call denotes calling a contract within MultiVM, containing data such as the contract being called, transaction sender, and arguments. Logically, a call can be divided into three types:

- Contract call — the very first contract call after the transaction starts executing (calling the Meta Contract is not considered a call);

- Cross-contract call — calling a contract from another contract, both contracts are deployed on the same VM;

- Cross-VM call — calling a contract from another contract, both contracts are deployed on different VMs.

Why do we call this “Logically”? Because technically, each call follows the same flow — determining which VM can and should execute the call, executing the call, and returning a commitment at the end. The commitment includes the execution result of the call and additional information to help confirm that neither the input nor the output data was tampered with. It will later be used to generate ZK proof of execution and validate the execution.

It’s worth noting that in the case of cross-contract and cross-VM calls, we will have multiple commitments as outputs: one for each internal call. All these commitments are combined into a recursive structure called a Fragment, hence the name Fragment VM. One Fragment ensures that not only a specific call but the entire chain of calls was executed correctly and without any tampering by the validator.

Token contract adapters

Several important issues that arise at the dApp level and potentially could disrupt their compatibility among each other are the various token standards. Specifically, the following questions arise:

- What will a standard token contract look like on MultiVM? Will it be unified for all VMs?

- How to ensure compatibility of the operation of both individual contracts and all contracts as a whole?

For better understanding of the issue, let’s remember how token transfers work in Solana and Ethereum in general. For example, let’s use the Defi Option Vault (DOV) contract where a user wants to deposit a certain amount of tokens.

EVM — SVM

EVM

1. User A approves the use of N $USDT tokens for the DOV contract — this is called an allowance.
2. User calls the deposit method in the DOV contract, specifying N tokens to deposit in the arguments.
3. The DOV contract makes a cross-contract call to the ERC-20 $USDT token contract, asking the $USDT contract to decrease User A’s balance by N tokens and increase the DOV contract’s balance by N tokens.
4. The $USDT token contract checks if the user has given permission to use N $USDT tokens for the DOV contract. If yes, it decreases one balance and increases the other, and returns the operation result to the DOV contract.

SVM.

1. User calls the deposit method in the DOV contract.
2. The DOV contract makes a cross-contract call to the SPL $USDT token contract
3. Now let’s take a brief technical dive into the implementation specifics of Solana. In Solana, everything is an account entity. It can store arbitrary data, which can be balance data or program code. Everything is called an account. When we talk about a token contract on Solana — it is an account that contains code for the SPL Token Program. But unlike Ethereum, user balance data is not stored within this contract. This data is stored in separate accounts that can be uniquely identified by the token contract address and the user’s address (these identified accounts are called associated token accounts). Only the token contract has access to the data within associated token accounts (guaranteed by cryptography). So when a command “transfer N tokens from address X to address Y” comes to the token contract, it means the token contract will identify associated token accounts for the two addresses X and Y, and change balance values accordingly.

The two mechanisms described above for token handling illustrate the challenge of implementing this in MultiVM without breaking compatibility with existing contracts. To solve this problem, MultiVM will use an Adapter Token Contract. The main problem that the Adapter Token Contract solves is that we leave the same flow on the side of users / developers / wallets when working with the token, but we react to these actions in our own way. This can be visually represented as follows:

MultiVM

In other words, the Adapter Token Contract acts as a sort of proxy. Based on the data from the incoming call, it can understand from which contract (EVM, SVM, FVM) this call came from and react accordingly. For example, if a request comes in to get a balance from the SVM contract, the Adapter Token Contract will find the necessary associated token account and then already ask the ERC-20 contract for the balance of that account. For each ERC -20 token contract, one Adapter Token Contract will be deployed.

ZK Fraud Proofs

Previously, we mentioned that each implementation of the VM is built on top of RISK Zero zkVM. This means that each transaction execution not only changes the state within our environment according to certain rules within smart contracts, but also generates ZK proofs that this execution is correct. Generating these proofs requires much more computational power than regular transaction execution. Therefore, our system will use an optimistic approach to verify the correctness of transaction execution (optimistic approach to generating and verifying proofs). This approach works as follows.

There are two almost identical environments. One is responsible for the speed of transaction execution and their pre-finalization. This environment is almost a constant part of the MultiVM process. Why almost? The answer will be given below.

The second environment is responsible for the security and correctness of the entire system. It comes into play only if a validator disagrees with the current state of the chain.

Let’s take a closer look at the flow of work in these environments and the communication flow between validators in stages.

1. The first image shows the first environment (which we will refer to as the Fast Execution environment). The last image shows the second environment (which we will call the Execution Guards environment).
2. The Fast Execution environment essentially performs the work that validators perform in many well-known L1 and rollups L2. Validators in this environment take raw transactions, reorder them, execute them, and modify data within the database. Validators write this data to the data storage after reaching a consensus with each other regarding the transaction result.
3. In the future, the Execution Guards environment will require a list of all transactions that have passed through the Fast Execution environment. Therefore, at this stage, all transactions are also recorded in some data availability layer. The cost of recording transactions in the data availability layer is low, but it has a high degree of decentralization and accessibility.
4. Consensus is not a bottleneck, as in some other L1 blockchains, because unlike them, this verification stage is not final so can be very simplified. This finalization stage is called pre-finalization: it ensures the necessary level of security, sufficient speed of operation, and a sufficient level of scalability. The pre-finalization stage is not related to ZK.
5. Validators in Fast Execution environments earn standard transaction fees + incentives from MultiVM.
6. Moving on to the more interesting Execution Guards environment. It is a kind of replica of the first environment: it also executes transactions, but does so for verification purposes and on a one-time / on-demand basis, rather than constantly. It also generates the data necessary to create ZK proof of transaction execution — this part relates to the magic of ZK (specifically to mathematics and cryptography). This environment has its own independent set of validators, but there is no reason why a validator cannot participate in the work of both environments. Validators in the Execution Guards environment are responsible for alerting if they are confident that some transactions have been executed incorrectly.
7. In this case, a validator (let’s say validator A) who found an incorrect transaction notifies all validators from both environments that he found an error. He also stakes a certain amount, which serves as a guarantee that it is not a false positive error. If it is confirmed in the future that everything was executed correctly and the validator made a mistake, this stake will go to the treasury pool to compensate for the consequences.
8. All validators suspend their work and start incident analysis. Specifically, first, everyone waits for ZK proof from validator A. Generating this proof takes quite a long time, but everyone can verify its correctness very quickly. This is the main difference between ZK rollups and other rollups, where each validator has to execute all transactions and reach a consensus among themselves to ensure that there was indeed an error.
9. If validator A fails to provide ZK proof within the allotted time, he also forfeits his stake to the treasury pool, and the system resumes operation.
10. If his concerns are confirmed, validator A will be rewarded with a substantial amount, validators involved in the verification will also receive a small reward, and validators involved in the erroneous pre-finalization of this transaction will be penalized. The system state will be rolled back to the last fully finalized state.
11. If within a certain time frame (1 week, but this value can be recalibrated in the future through governance) no erroneous transactions are found, the system state will be considered finalized up to that point and can no longer be changed. The timeline of finalization can be visually represented as described.

It may seem that rolling back the system to its last finalized state will cause irreparable damage, as a huge number of transactions will be rolled back. For example, transactions such as profit realization, NFT sales, profits from various protocols, etc. However, it is important to note that in other systems (such as Ethereum and Solana), the consequences of similar attacks will be much greater, as potential attackers can withdraw these funds from the network and use them as they please. In our system, withdrawals will not be available until the withdrawal transaction from the network is fully finalized. Therefore, while a fraudster may “break” the system, they will not be able to profit from it. This is what is meant when it is said that ZK technology enhances security in rollups.

Real security and real decentralization are getting closer, aren’t they?

Summary

In this article, we have discussed in detail various specifications of MultiVM: how account management works for different VMs, interactions with tokens, and transactions within the Meta Contract. We have gone into the ZK Fraud proofs system, its advantages, and the challenges it presents. The next article will provide a clear illustration of how MultiVM functions from a user’s perspective.