HF mechanism requirements

[deepthiskumar]

Drafting Requirements/considerations for any HF mechanism

1. HF signalling

   1. On-chain or off-chain

2. HF pre-release for nodes to participate in the HF

3. Upgrade monitoring period/ HF activation

   1. 60% of the stake should upgrade to proceed with the HF
   2. Able to abort fork if stake percentage not reached and continue with the previous version or a manual emergency HF

4. New version

   1. Change in protocol and/or major transaction version number. This may impacts zkApps (backwards compatibility) and other applications that consume blockchain state.

5. State transition

   1. Ledger transition (in the case account field changes or hash function changes) should be automated and performed by nodes during the upgrade
   2. Blockchain state transition at fork point is performed by nodes during the upgrade.
      1. Continue the chain by recursively proving block at the fork point. Until this is possible, all nodes should produce the same genesis block.
      2. Berkeley HF did not recursively prove at the fork point.
   3. Snarking all staged transactions at the fork point i.e., all confirmed transactions should be snarked. Berkeley HF used staged ledger and relied on out-of-snark consensus on the ledger.
   4. Fork point should be finalized as per the consensus algorithm. Ouroboros Samasika finality guaranteed at 290 confirmations. For Berkeley 100 slots (~60 confirmations) were used for finalization.
      1. A tie breaking rule must exist in the event there are forks of the same length as block selected from the canonical chain

6. Historical state preservation

   1. Archive node migration be completed before the switch. Ideally this should be after HF is activated/confirmed as a result of 60% or more upgraded. Otherwise, there needs to be a mechanism to revert or fail forward in the event nodes don't upgrade.

7. Testing

   1. Public testnets with the new changes
   2. Ability to disable features with major/critical bugs to ensure rest of the HF features/fixes can be released
   3. Public testing of the upgrade mechanism

8. Monitoring

   1. Be able to monitor software upgrades before the fork (pre-fork release) and determine upgraded stake
   2. Monitor fill rate post upgrade but before the fork
   3. Monitor fill rate post fork

9. Emergency HF mechanism

[deepthiskumar]

Protocol level-
Compatibility with previous version

1. Blocks built from previous version should not be accepted. Blockchain snarks from previous versions should not be verifiable/accepted
2. Transactions may change and become incompatible
   1. Applied transaction must not be replayable
3. public/private keys must be compatible
4. Signatures must be compatible (mainnet and devnet)
   1. Signing apps should remain compatible
5. zkapp Proofs may become incompatible until a backwards compatibilty for zkApps is added
6. Account data must remain as is except for any protocol fields that are updated. Also, new fields may be added. Any change in the ledger hash should be transparent and verifiable
7. Network RPCs may change making it incomaptible with previous version
8. GraphQL changes- breaking changes? TBD (including any format/serialization changes)
9. Archive node changes- TBD
10. CLI changes, Rosetta changes- TBD
11. Global slot since genesis must be continued from previous version.
    1. Cosnequently locked tokens should continue to vest as per schedule in the previous version
12. Epoch number should continue? TBD

[dkijania]

I would also add Packaging/Release requirements. Last time we had a pipeline that built Mainnet/Devnet packages. It was kind of hackish and not very clean (duplicated a lot of CI code), but was stable and easy to configure/use. I would add the same requirement here.

• Allow do build packages (debian/docker) for Daemon/Archive/Rosetta with mainnet and devnet signatures for arbitrary slot
• Cleanup existing (and unfortunately out of date) HF pipeline, Make it share common jobs with standard packaging flow