2019-05-08 Meeting notes: upgrading a network

Date

May 8, 2019

Participants

  • @Kelly Foster

  • @Łukasz Gołębiewski

  • @Kayvan Kazeminejad

  • @Timm Schäuble

  • @Artur Gajowy

  • @Ovidiu Deac

  • @Dominik Zajkowski

  • @Sebastian Bach

  • @Adam Szkoda

  • @Chris Boscolo

  • @Tomáš Virtus

  • @Lucius Meredith

Goals

Discuss the process for upgrades

Discussion topics

Item

Notes

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