Establish Genesis

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

Set the state on the new blockchain’s genesis block.

Context

The application has a large number of states, and all of them need to be recreated on the target blockchain. The blockchain governance body has decided to spin up a new blockchain instance as the target and use tokens as the native asset. The list of accounts and states to be migrated is given in the snapshot. 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

As seen in the following figure, use the snapshot of states from the source blockchain to set states on the target blockchain’s genesis block during its initialisation. If a user cannot use an existing private key to prove its ownership of a state migrated to the target blockchain, a new key pair needs to be created. Thus, the first step is to get each user to create a new key pair and a corresponding account ID (accID) using the account creation algorithm of the target blockchain. Second, update the account ID in the snapshot file with accID. Next, create the genesis block configuration file (aka., genesis file) while including the accounts and states from the updated snapshot file. Then use the genesis file to initialize the target blockchain. Update the application-level reference to blockchain identifier mapping database (i.e., ID database) on the Blockchain Access/API Layer (BAL)to reflect the new set of accIDs. Also, add a Proof of Exist (PoE) entry that tracks the mapping between old and new account IDs to record how the new accounts came into existence.

The first two and last two steps are optional when the accounts can be reused across the blockchains. However, it is desirable to create new private and public key pairs, as well as corresponding accounts on the target blockchain. This can guard against weaknesses that may appear in the source blockchain, its wallets, and exchanges that could compromise a private key or seed used to generate it. Further, the use of new accounts could enhance the anonymity of the application’s accounts, especially when states are not very specific such that it is nontrivial to build a mapping table, e.g., when state aggregation pattern is used. User involvement is needed to create key pairs and new accounts if they hold the private keys. Moreover, platforms such as Hyperledger requires users to enrol their digital certificates with the certificate authority.

If the number of states in the snapshot is too big to fit into the genesis block, aggregation pattern could be used to reduce the state. Native assets are typically set during the genesis block creation. Typically, smart contracts are not deployed during the genesis. However, while Hyperledger Fabric does not use a native asset, it allows smart contracts to be deployed using the genesis block.

Encrypting on-chain data pattern can be used to encrypt the Proof of Exist (PoE) entry added to the blockchain to hide the mapping between old and new accounts. For example, Hyperledger Fabric private data collections can be used to allow a subset of peers to store the mapping between old and new accounts in a private state database and share them with each other while adding a hash of that data to the ledger using a transaction.

Time taken by all users to create new accounts is difficult to predict. Hence, sufficient notice ranging from a couple of days to weeks needs to be given to the users before the snapshot and genesis block are created.

Benefits

• Consistency – Arbitrarily creating states on the genesis block to bootstrap a blockchain is not considered a consistency violation, as the genesis block is built by the blockchain governing body and the content of the block is transparent. Moreover, it is the blockchain governance body that establishes the genesis block.
• Latency – Migration can be performed fast, as only the genesis block is used to recreate the state.
• Cost – No transaction fees as the global state is initialized by the genesis block’s configuration than using transactions.
• Accountability – could be preserved by adding the PoE entry that tracks the mapping between old and new account IDs.
• This pattern can be used to recreate native assets of any new instance of a blockchain.

Drawbacks

• Latency  The process slows down when users have to create new accounts.
• Consensus – The consensus is enforced only for the format of the genesis block, as the global state is yet to establish.
• Size – The pattern works only if the states fit into a single block or can be aggregated to fit into a single block.

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

• The genesis block is used to specify the initial distribution of native assets on a blockchain. For example, the genesis block of the Æternity included the ERC-20 tokens of users who supported the initial migration from Ethereum to its blockchain.
• Zeepin used a similar approach as it migrated from NEO to its blockchain.
• Telos – an instance of the EOS platform – used the EOS snapshot file to build its genesis block.
• The pattern is also used for hard spooning, e.g., Bithereum created its genesis block using a snapshot from Bitcoin at a set block number.