Virtual Machine Emulation

Disclaimer: This is a summary of patterns we have observed during our research and should not be considered any form of technical or investment advice. Also, the given “known examples” do not imply they are the best implementations of the said pattern or any superior to any other implementation of the pattern not listed.

Summary

Allow smart contracts written in one language to run on another blockchain platform.

Context

The application uses a set of smart contracts and embedded states which need to be usable on the target blockchain. State and transaction load patterns cannot be used to load smart contracts from the source blockchain to target blockchain, as the execution environment is not identical. However, the target blockchain platform could emulate the Virtual Machine (VM) used to execute smart contracts. The list of smart contracts and their states to be migrated is given in the snapshot. After the snapshot, smart contracts are marked as unusable using token burning.

Problem

How to load and run smart contracts from the source blockchain on the target blockchain?

Forces

• Platform dependence – Usually, the smart contract language is blockchain platform-specific.
• Turing completeness – Not all smart contract languages are Turing complete. Thus, it may not be possible to recreate the same behaviour using a different smart contract language.
• Correctness – It is difficult to guarantee that the rewritten smart contract behaves precisely like the original smart contract.
• Time and cost – Rewriting and testing smart contracts take time hence also costly.

Solution

Use the process outlined in the following figure to reuse the smart contract execution environment (aka., VM, sandbox, or container) on the target blockchain. First, copy the VM from the source blockchain. Second, integrate the VM into the target blockchain. Third, if the VM does not hold the smart contract code, redeploy the smart contracts on the target blockchain using the state initialization pattern. Fourth, use the same pattern to set the states of the deployed smart contracts. Smart contract code and their states can be found from the snapshot. Sixth, update the mapping between old and new smart contract addresses on the application-level reference to blockchain identifier mapping database (i.e., ID database), as smart contract addresses vary across blockchain instances, and could also depend on the address that deployed the smart contract, transaction sequence number, among others. Finally, it is also desirable to include the snapshot file and mapping between old and new smart contract addresses as a Proof of Exist (PoE) entry, as they are not included in the target blockchain’s history.

If the target blockchain allows importing the source blockchain’s VM, it could be copied over. However, in practice, it is more likely for the target blockchain to use a customised VM that supports the same instruction set. For example, while Hyperledger Burrow supports the Ethereum VM (EVM), a proxy is used to abstract the transaction fee-related parameters, as Hyperledger does not have a concept of transaction fees. Moreover, not all VMs hold the smart contract code. For example, while Hyperledger chaincode containers hold the code, EVM uses the code stored in the global state. Also, earlier versions of Hyperledger Fabric required smart contract to be instantiated on the target blockchain before use. Such instantiation may also be used to set the address and access rights of a smart contract.

Furthermore, even if the addresses can be reused, it is desirable to create new accounts, as discussed in the establish genesis pattern. This intern could change the address of the smart contract. Therefore, rather than copying the VM, which is likely to require extensive configuration, it is easier to redeploy the smart contracts on the target blockchain’s VM. In such cases, the first two steps can be skipped, given that the two VMs exhibit the same execution behavior. Such compatibilities could be checked using bytecode-level formal verification while reducing the cost and complexity of smart contract validation. When account owners hold the private keys, users need to create new accounts, redeploy smart contracts, and set their states. Also, if the reference to a smart contract is provided via a smart contract registry or transactions are routed via a proxy contract, first, the corresponding registry or proxy contract needs to be deployed. Then update the registry or proxy with the new smart contract address.

Benefits

• Correctness – Execution behaviour and correctness of the original smart contract are preserved, as the same smart contract code and execution environment are used.
• Time and cost – Saves time and reduces cost, as no code reverse engineering, translation, and testing are needed.

Drawbacks

• Turing completeness – Works only when the target blockchain platform can emulate the source blockchain’s VM (i.e., smart contract platform independence) without any limitations in behaviour and Turing completeness.

Related patterns

• When emulation is not possible, use the smart contract translation pattern.
• Snapshotting, state aggregation, and token burning patterns can be used to capture the smart contract code, embedded states, aggregate the states, and burn the smart contracts.
• Use the state initialisation pattern to deploy and set the state of smart contracts.
• PoE entries of mapping between old and new smart contract addresses can be added using either blockchain anchor or encrypting on-chain data patterns.

Known uses

• EVM bytecode can run on Hyperledger, VMware Concord, Tron, and VeChain.
• Deloitte was able to move smart contracts from Ethereum to VeChain, as both blockchains supported the same EVM.
• Docker containers used by Hyperledger to store and execute smart contract code could be reused on multiple channels and across different networks.