Hard Fork 1

[tgrospic]

Important dates

Done	Date (2021)	Event	Description
✔️	02 July	Specification	Specification of Hard Fork process
✔️	07 July	Announcement	Announcement of preparatory snapshot
✔️	12 July	Snapshot	Preparatory snapshot, block 896988 wallets_REV_BLOCK-896988.txt
✔️	12 July	Announcement	Disseminate information about Preparatory Snapshot
✔️	15 July	Announcement	Announcement of block height 908300 for final snapshot
✔️	16 July 10:41 UTC	Shutdown	Network shutdown at Last Finalized Block 908300
✔️	16 July	Snapshot	Final snapshot, block 908300 wallets_REV_BLOCK-908300.txt
✔️	18 July	Genesis	New network operational with genesis block 908400

Links in this table points to the text file where REV balances can be checked, for Preparatory and Final Snapshot.
The balance is in raw format (revlettes), add 8 decimal places to get REV amount.

Here are the raw csv files from export process documented in Export of REV vault state RCHIP. mergeBalances.csv contains mapping between REV address and its hash which is acquired from transaction server.

Overview

Two upcoming hard forks are planned for RChain main net network. They will restart the network from fresh state with only REV vault state (balances) transferred from the old network.
The purpose of this RCHIP is to provide specification how the process of the first hard fork will be executed. Hard Fork 1 is more like a rehearsal for Hard Fork 2 which will contain many improvements and fixes. So in Hard Fork 1 are only fixes to support future block-merge release, remove inactive validators from PoS contract and a few configuration changes.

Terminology:

• Snapshot - export of REV balances on specific block height (number)
  • detailed information of this process is specified in RCHIP
    Export of REV vault state (REV balances)
• Hard Fork - upgrade of a blockchain network that is not compatible with the existing state
• PoS - Proof of Stake contract used on RChain main net
• TreeHashMap - implementation of a Map (key-value pairs) in Rholang

List of changes for Hard Fork 1

Change	Type	Description	Reference
TreeHashMap depth (rewards map)	PoS fix	Support for block-merge (prevent conflicts)	PoS rewards map init
Reduce quarantine length	PoS config	Reduce period for holding unbonded/slashed validators in active bonds map	PoS quarantine length config
Remove inactive validators	PoS config	Remove inactive validators from bonds map, start a new network with only active validators	PoS initial bonds map
Increase max bonding amount	PoS config	Increase maximum amount of REV for validator to stake (1.5M REV => 5M REV)	PoS max bond config

New Main Net configuration

Config type	Value	Description
Shard name	root1	Root shard for RChain blockchain network
Network ID	mainnet1	Message identifier of the RChain network

Proof of Stake parameters

Config type	Value	Description
Epoch length	250,000	Number of blocks between epoch
Quarantine length	0	Number of blocks to keep validator after withdrawal (it's zero because epoch length is already included)
Minimum bond	12,000.00000000	Minimum stake needed for bonding (REV amount)
Maximum bond	5,000,000.00000000	Maximum stake allowed for bonding (REV amount)

Bonds file used to start the new network bonds.txt.

Impact on REV holders

In short, Hard Fork will not have impact for owners of private keys for corresponding REV address, including REV on exchanges.
MultiSig REV accounts cannot be migrated and must be transferred to private key owned REV address. To our knowledge, there should be no additional MultiSig accounts other than those used in system contracts.

The impact will be on operations on the network. After Final Snapshot network will be offline for a short period for the final community validation.

The Cooperative Board established the process to transfer some of the locked RHOC tokens. Description of the adjustments is documented in the Coop Governance-Committee repository and REV balances will be published in a separate file.

Timeline

The whole proces is divided in multiple steps to ensure enough time for the community to check the balance of their REV accounts and to minimize the downtime of the main net network.

Two snapshots are planned. The first Preparatory Snapshot will leave more time for community validation because network will continue working without interruption.
In the second Final Snapshot, the network will stop and exported REV balances will serve as the initial state of the REV vault for the new network.

Before Final Snapshot, RChain Cooperative will announce block height on which snapshot will be taken and published on GitHub rchain/rchain repository in the wallets_REV_BLOCK-nnnnnn.txt file for community validation.

This is also an invite to all Coop members to check their balance in specified wallets.txt file by searching for their REV address and comparing with the balance read from any available wallet.

Risks and validation

The Cooperative encourage members to check their balances and any reported irregularities will be investigated, documented and corrected.
The whole process of REV export (snapshot) and validation is documented (Export of REV vault state (REV balances)) and supporting repository (tgrospic/rnode-rev-export-hard-fork-1) enables anyone to repeat the process, not only before Hard Fork but any time in the future. The Cooperative will ensure that state before each Hard Fork is preserved and available in the future.

New network operational

REV balances exported in the Final Snapshot will serve as the basis to start the new network through Genesis ceremony. The first block will contain deploys with initial deposits from wallets.txt file published in rchain/rchain repository.