Hardfork process automation

[deepthiskumar]

No description provided.

[deepthiskumar]

Pre-fork period: A fixed time period before on-chain fork initiation during which node operators prepare their setup for the hard fork. This includes the following

1. Migrate Archive DB
2. Migrate Rosetta DB
3. Install a client version that triggers the fork upon reaching consensus otherwise reverts to the existing chain

On-chain fork period: A fixed number of slots/network downtime during which nodes execute the hard fork (Fully automated)

1. Determine the state to fork off
2. Reach consensus on the state to fork off of, next protocol version (maybe even hash of the protocol constants of the new client), slot number at which the network forks
3. Upon reaching consensus, export the fork block and ledger corresponding to the block
4. Migrate the ledger if required (based on what's in the newer version of the client), generate fork constants required to generate blocks in the new fork. Fork constant to include the network start time/slot
5. Start the new version of client along with the migrated ledger and fork constants. Seeds should also be upgraded to ensure upgraded network resumes.
6. Wait for slot/time to resume block production in the upgraded network

Post upgrade monitoring (alerting)

1. Nodes are able to start and have sufficient peers
2. Blocks are being produced
3. Transactions resume
4. Other network health metrics

Security considerations:

1. Prevention and /or fallback mechanism when consensus is not achieved on the block to fork off due to various reasons such as not enough nodes upgraded, not enough stake participating in consensus, nodes crashing due to bugs in the implementation, chain reorgs/short forks etc
2. Sufficient window for each phase of the hard fork process to ensure maximum participation
3. Preventing network partition
4. Grace period is sufficient to make chain density as good as possible