Smart Contract Translation

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

Translate smart contract code from one language to another.

Context

The application uses a set of smart contracts and associated states which need to be usable on the target blockchain. The smart contract language of the target blockchain is not interoperable; hence, state and transaction load or virtual machine emulation patterns cannot be used. The list of smart contracts and their states to be migrated is given in the snapshot.

Problem

How to load and run smart contracts 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

Follow the process outlined in the following figure to translate and deploy a smart contract on the target blockchain. First, verify that the respective source code produces the exact smart contract deployed on the source blockchain. Second, translate the smart contract to the new language. Then, test the functional correctness and security of the translated contract. Fourth, deploy the new smart contract to the target blockchain using the state initialization pattern. Fifth, use the same pattern to set the states of the deployed contract, as per the state recorded on the snapshot. Next, 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 different 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 original and translated code, 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.

Smart contracts updated or rewritten for the same blockchain instance are within the purview of this pattern because the new smart contract needs to be redeployed. Further, its states need to be set to the values of the previous contract. When the smart contract language is a compiled one, it is more desirable to compile the source code and then compare it with the binary code on the source blockchain. Compared to syntax-level comparison, this could reveal details such as compiler version and optimizations used during deployment of the original contract, which may need to be taken into consideration during the translation. Depending on the language support and tool availability, translation may happen either at the source or binary code level. In addition to the functional correctness, accuracy of data types, their visibility, and smart contract function-level access control must also be preserved. Also, aspects such as semantic equivalence, event handling, object-oriented features, and optimizations to reduce computation time and execution fees should be taken into account. Ideally, extensive functional and security testing should be performed on the test network provided by the target blockchain. It is not uncommon to use a bug bounty program to test critical smart contracts, e.g., token contracts. Therefore, the migration time frame should allocate sufficient time for such testing. When account owners hold the private keys, users need to create new accounts, deploy new smart contracts, and set their states. Also, if the reference to a smart contract is provided via a smart contract registry [? ], the registry contract needs to be translated and deployed first. Then update the registry with the new smart contract address.

Benefits

• Turing completeness –This pattern works for any blockchain platform that has a smart contract language rich enough to recreate the same behaviour.
• Correctness – Correctness can be enhanced by verifying the source code before translation, formal verification, and extensive testing.
• Time and cost – Errors, time, and cost could be reduced via automated translation and testing.

Drawbacks

• Correctness –
• Smart contract translation is not trivial and involves many complications. It is difficult to guarantee that a translated smart contract exhibits the same behaviour.

Related patterns

• VM emulation pattern is preferred when applicable. 
• 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 translated smart contracts.
• PoE entries of smart contract codes and updates to the contract addresses can be added using the blockchain anchor and encrypting on-chain data patterns.

Known uses

• As Serpent was deprecated and had several security weaknesses, Augur smart contract written in Serpent had to be rewritten in Solidity.
• Kyber redeployed its contract with fixes, as the contract was about to be unusable due to the revision of Ethereum gas costs.
• Tronbet migrated its ANTE tokens to new WIN tokens managed by a new smart contract with enhanced features. Both Augur and Tronbet used token burning and state initialization patterns to set the state of the new contract.
• Counterparty and Tron allow executing Ethereum smart contracts on Bitcoin and Tron by modifying the Solidity code, respectively.
• Sol2js is a tool to translate Ethereum Solidity to Hyperledger Javascript.