Implementing A Breaking Change Release

[SteveHenley]

Summary:

SysOps runbook procedure for a breaking change release.

Definition:

Breaking change release is a release that is not backwards compatible. Should these procedures apply at the root shard level only or all shards? Protocol (data structures and/or API call parameters) breaking changes vs. specific implementation breaking change (scala vs java vs rust) ? Note that multiple language nodes can run in the same shard .. it might improve security and resilience.

Validators:

All bonded node validators must participate in a breaking change release implementation to migrate from the old network to the new network at the block height announced by the Tech Governance team (with inputs from dev team).

• 1. Breaking change release can be submitted by:
• 2. RChain core developers??
• 3. Proposers??

2. Editorial, approval & communication
   3. Editorial - review and edit submitted release request.
   4. Approval - review edited release request
   5. Communication
      1. Announcement procedure
         1. Atlassian release notes
         2. Social media
            1. developer.rchain.coop website
            2. Discord - development channel on RChain pub
            3. Telegram - RChain community
            4. Weekly community debrief
            5. RChain YouTube channel
   6. List breaking change release in registry.
      2. Release number
      3. Change classification
         3. Soft update
         4. Breaking change
         5. Hard fork
      4. Implementation date
3. Validator identification - identify which validators are involved in the breaking change release implementation.
4. (Third item - help me here Tomislav, see log: tech governance is needed)
   7. https://docs.google.com/document/d/1fvxMC6Bt5XwbVaLzYPy6ZPB8KzJvASO2sKRC6ZCPwpI/edit
5. Metrics
   8. Block height start - the block number at which validators must begin to implement a breaking change release.
      5. The recommendation is to treat validators that have not upgraded, as dead nodes until they upgrade
      6. How do we ensure that this doesn’t lead to a network security issue because most validators have not upgraded to the new release at the specified block height?
   9. Block grace period - the number of blocks within which validators must implement a breaking change release before being penalized (slashed?)
   10. Block height slash - the block number at which validators will be penalized for not completing a breaking change release implementation.
       7. (Incomplete implementation penalty - Slashing?)
6. Issue tree or stream??
7. New feature not being supported by existing validators will cause them to be slashed
   11. Have some block number where everyone has to update by a specific time
       8. Validators do not upgrade their block will be orphaned
       9. As a result validator will fork itself
   12. Possible resolution - is to have version number field in block. When a node receives a higher version block, it can simply pass on the block to other validators without doing anything with it.
       10. Incorporate into the version numbering scheme, semantics about whether the new version features break or cause slashing etc or not..
       11. Breaking/slashing causing changes should mostly be combined together into a single release, so validators have time to react and upgrade
       12. Have minimum feature set that should be support by validators for example Rholang 1.0.1
           6. Without upgrade say all features in Rholang will be breaking
           7. Example: 0.9.25.x / supports Rholang 1.0.1
   13. Casper -

[9rb]

1. Classify what's a breaking change vs not
2. Provide guidelines to implement a breaking change

This is similar to meta-eip

[zsluedem]

@SteveHenley Does this issue talk about the first breaking changes Rchain is going to make or just the guidelines for breaking changes?

[SteveHenley]

@zsluedem I believe this issue was created to address the guidelines for break changes. I will confirm this. I have added your question to the tech governance agenda for this Thursday.

[SteveHenley]

We need to discuss communication with exchanges. If there are any bugs we should have instantaneous stopping of transactions. We should be prepared for halting and rollbacks to dissuade hackers.