Hard Fork 1
tgrospic opened this issue · 0 comments
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)
- detailed information of this process is specified in RCHIP
- 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.
