State Initialisation

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

Initialise/recreate states on the new blockchain.

Context

Concert application has a large number of states and smart contracts, and all of them need to be recreated on the target blockchain. The user has chosen an existing public blockchain as the target. The list of accounts, smart contracts, and states to be migrated is given in the snapshot or application-level reference to blockchain identifier mapping database. After the snapshot, states are marked as unusable using token burning.

Problem

How to load states and smart contracts to the target blockchain?

Forces

• Consistency – States such as blockchain native assets cannot be arbitrarily created because migration must preserve system invariants. It is difficult to create a complete copy of the ledger and block history, as the system is distributed, new blocks are built continuously, and finality is not immediate.
• Accountability – Initiation of new accounts and their states on the target blockchain must be recorded with proof.
• Size – A blockchain may contain a large number of accounts, states, smart contracts, and transactions. Moreover, history may consist of a large number of blocks. A large subset of these may need to be initiated on the target blockchain.
• Latency – Time to create accounts and initialize their states is proportional to the number of accounts and their states. Given the large size of the global state and history, time to make a copy could be very long. It takes even more time to recreate and validate the global state by applying all transactions and running smart contracts.
• Cost – Each account creation and state assignment may needs to pay a transaction fee. The transaction fee could also be proportional to the size of the state.
• Consensus – To accept a state, smart contract, transaction, or block as valid, both the sender and receiver nodes must follow the same consensus rules.
• Governance – The consensus of the blockchain’s governance body is required to update any state or blockchain platform software.

Solution

Create one state at a time on the target blockchain using the steps shown in the following figure. If a user cannot use an existing private key to access the state migrated to the target blockchain, follow the first step to create a new account. Then get the user to sign a transaction with the state listed in the snapshot as the payload and new address (i.e., accID) on the target blockchain as the recipient. Then submit the signed transaction to the target blockchain to recreate the state. Update the application-level reference to blockchain identifier mapping database (i.e., ID database) and add a Proof of Exist (PoE) entry to reflect new account IDs. It is also desirable to include the snapshot file as a PoE entry, as it is not included in the target blockchain’s history compared to establish genesis and hard fork patterns.

While the first and last two steps are optional when the accounts can be reused across the blockchains, it is desirable to create new key pairs and accounts. As discussed in the establish genesis pattern, this can enhance the anonymity and guard against exposure of private key due to weaknesses that may appear in the source blockchain. Also, user involvement is needed to create new accounts.

When users hold the private keys, they also need to sign the transaction used to recreate the state. Signed transactions are issued by the migration tool to the target blockchain, mainly for the convince of managing the migration. For example, when the transactions flow through the migration tool, it is easier to update the ID database and use the measure migration quality pattern to quantify the progress of the migration. Instead, users may send the signed transactions directly, as each state is initiated using an independent transaction. In fact, the entire loop can be parallelised.

Moreover, rather than using a snapshot file to identify the list of accounts and states to recreate, ID database could be used. However, it is essential that the latest state on the source blockchain is captured and recreated on the target blockchain. Thus, the token burning pattern can be used to guarantee that a state will not further change on the source blockchain.

This pattern is suitable to redeploy smart contracts and recreate states embedded in them, e.g., tokens. Sometimes a series of transactions may need to be replayed to set a particular state. However, this is time-consuming and costly, as transactions need to be replayed in exact order with finality. However, native assets cannot be recreated due to the violation of systems invariants. Assets lost as transaction fees during state transformation, token burning, and setting state could also be credited back while initiating a state.

Time taken by all users to create new accounts and sign transactions is difficult to predict. Hence, sufficient notice ranging from a couple of days to weeks needs to be given to the users, e.g., Effect.AI, Tron, Safex, and VeChain. However, user involvement does not slow down the entire migration process, as each state is independently recreated.

Benefits

• Consistency – One state can be initialized or smart contract can be deployed at a time without requiring the migration to be a single-shot operation; hence, the risk is reduced.
• Consistency and accountability – are preserved when proof of burn is verified before the state initialization and a PoE entry of the snapshot is added to the blockchain.
• Governance – No explicit approval of the blockchain governance body is needed to issue transactions.
• This pattern works with any target blockchain regardless of its existence.

Drawbacks

• Size, Cost, and Latency – If the number of accounts and their states is large, many transactions are needed to set their state, increasing the cost and latency. Size, cost, and latency could be reduced using the state aggregation pattern.
• The pattern works only for states and smart contracts that can be arbitrarily created, e.g., tokens generated by smart contracts. It does not work on native assets.

Related patterns

• Snapshotting, state aggregation, and token burning patterns could be used to identify, reduce, and burn the states to include in the genesis block.
• Use the blockchain anchor pattern to add a PoE entry that tracks the mapping between old and new account IDs.
• Alternatively, if the mapping between account IDs is not very large, an encrypted version can be added using the encrypting on-chain data pattern.

Known uses

• Binance, Bithereum, Bitizens, Effect.AI, EOS, Gifto, Kin, Qubicle, Safex, Storj, and Vechain migration used this pattern to issue new tokens on the target blockchain.
• Bithereum, Effect.AI, EOS, Kin, Qubicle, Safex, Storj, and Vechain also relied on users to create new accounts on the target blockchain, and inform new addresses to the migration tool.
• Other than Bithereum and Gifto, others also used token burning in combination with this pattern.