Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Item

Notes

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.

    • 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

Decisions

  • Acceptance criteria for upgrading the platform: Done when you can introduce a forking change and migrate a testnet.

Action items

  •  

Decisions