Hard Fork

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

Change the global state of the blockchain.

Context

The application has a large number of states, and all of them need to be recreated on the target blockchain. The user has chosen an existing private or consortium blockchain as the target. The user has gained the consent of blockchain’s governance body to introduce state changes that violate the consensus rules. 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 states from the snapshot to change the global state on the target blockchain. If a user cannot use an existing private key to access the state migrated to the target blockchain, follow the first two steps to create a new account and update the snapshot file. Next, update the blockchain client software on all nodes of the target blockchain to include the snapshot file at a set block number (blockNo). Once the blockNo is reached, all blockchain nodes should append the states from the snapshot file into the ledger to update the global state. Due to the arbitrary addition of new states, blocks produced before and after the software update will be incompatible. Such a change in blockchain state transition rules is referred to as a hard fork. Finally, 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.

While the first two 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 enhances the anonymity and guard against exposure of private key due to weaknesses that may appear in the source blockchain. Similarly, user involvement is needed to create new accounts.

While any state can be amended during a hard fork, deployment of smart contracts is unprecedented. However, compared to the establish genesis pattern, there is no limit on the number of states that can be recreated during a hard fork.

Similar to the snapshotting pattern, approval of the blockchain governance body is needed to update the blockchain client software. Further, the blockNo to initiate the hard fork need to be determined while considering the time needed to develop and patch all the nodes, as well as time taken by all users to create new accounts. Hence, a notice period ranging from a couple of days to weeks needs to be given before the hard fork.

Benefits

• Consistency, Accountability, Integrity, and Immutability – Blockchain sync tools rely on asynchronous messaging, immutability (to identify states updated after a given block number), consensus (to provide consistency), and validation. Hence, no state, history, and IDs are lost or changed in the process, ensuring consistency, accountability, integrity, and immutability.
• Governance – No explicit approval of the blockchain governance body is needed to add a new node.
• Cost – No transaction fees as data synchronization is at the blockchain data structure level.
• Compatibility – This pattern works on any blockchain where source and target blockchain platforms are compatible (i.e., follow the same consensus rules), and the target node(s) is new.

Drawbacks

• Latency – Time to synchronize a large volume of states and history could vary from hours to days. Time can be substantially reduced by bootstrapping a node using a snapshot and synchronizing only the ledger state (i.e., state only data fidelity level).

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

• Hard forks are used to spin-up new cryptocurrencies. For example, after launching the blockchain using establish genesis pattern, Æternity went through three rounds of hard forks to migrate the remaining ERC-20 tokens.
• When Steem was sold to Tron, objecting users spin up a new cryptocurrency called Hive by forking the Steem blockchain.
• Similarly, a conflict over the use of a hard fork to recover cryptocurrency lost due to the DOA attack resulted in Ethereum and Ethereum Classic.