| |
|---|
Resources | |
Discussion and questions | 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. 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? 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 | |
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 Is the RNode version noted in every block? Make decisions about how to manage versioning semantics
|
Decisions | |