As long as a node runs software that adheres to the blockchain protocol, it doesn’t matter what software it runs. Blocks and state transitions are all you need.
Block format and block state transition are what matters
Requirement - maintain the blocks and the state of the network
What do we need to do know to prepare for upgrading?
What’s the process to upgrade if there is a change to how blocks are processed or managed?
Assume a requirement to not create a hard fork
Does a node need to be able to serve blocks from 0-n at all times? No. We have snapshots from past node versions. If someone wants to rebuild and wants to pay for the support, we can provide a rebuild service.
Proposal: Network supports current and most previous software versions.
RNode v1 is most recent version
RNode v2 is the updated version that supports all of what's in v1 to work and all of v2 to work
To mitigate risk of bugs we
Proposal
Blocks need to hold the version number
When we need to make an upgrade to the network that would be considered a breaking change in the blockchain protocol
Announce to the communiyt
Support adding blocks from version 1 and version 2 and announce the block number when nodes will stop accepting blocks from version 1
Requires specifying and communicating when version 1 will no longer be honored.
Risks
Running multiple versions of RNode on a network will create bugs
Tickets
How does the coop publish and share the genesis block?
We need business decision for how to request block in the past beyond the current finalized block + defined period
Document the path to going back to genesis by running older versions of RNode and upgrading up to the point you are able to reproduce the tuplespace since genesis
Document process for upgrade
Includes taking a snapshot
Is the RNode version noted in every block?
Make decisions about how to manage versioning semantics