Network upgrade communication protocol

From Kulupu wiki
Jump to navigation Jump to search
Kulupu
Blockchain
Walletpolkadot.js
NodeGithub
StatusPolkadot Telemetry
ChatDiscord, Matrix
LaunchedSeptember 2019

On Kulupu network, a network upgrade will affect the whole well-being of the blockchain. As a result, it is important to make sure that the process is as trustworthy and secure as possible. This communication protocol document aims at improving this, by creating a defined checklist for what should be done at each network upgrade, and at each step, who is responsible for doing what things.

Coordinator-initiated network upgrade[edit | edit source]

Under normal circumstances (with exceptions stated in the next section developer-initiated network upgrade), the core team usually does not directly propose a network upgrade for Kulupu (precisely, Kulupu The Coin). A network upgrade is initiated by a coordinator. The coordinator is self-assigned. Everyone can be a coordinator by announcing it themselves. This also means that in extreme situations, there can be multiple coordinators proposing multiple network upgrades, and only one of them will succeed.

During the upgrade process, the primary communication channels are Github, Discord and Matrix.

  1. The core team will periodically publish Core Paper Newsletter, documenting new features and changes in the runtime. The community can also propose new features to be implemented by documenting the details in Github issues.
  2. The coordinator will first contact the core team, by creating a new issue in Github, stating a new network upgrade is expected to be cut off.
  3. The coordinator should then seek council support, to get at least the majority to signal that they will vote Aye on a future council motion that moves a network upgrade proposal into democracy referendum.
  4. If the core team feels optimistic that a majority of council support can be reached, it will assign the issue created in step (2) to itself.
  5. The core team will finalize the network upgrade runtime binary. This is expected to take some time, as the developers have to check necessary migrations and incompatibilities.
  6. The core team will move a motion in council to be voted, regarding this network upgrade.
  7. The coordinator is then expected to ask the council to move on the motion.
  8. If everything goes well, the network upgrade will become a democracy referendum.
  9. The core team will post a communication / marketing material, documenting features and changes, and if there are anything that users should be cautious about.
  10. The coordinator is then expected to ask the general public to vote on the referendum.
  11. As a general rule of thumb, upon a passed network upgrade, the council is expected to cover the necessary expenses for the coordinator and the core team, using the treasury. The coordinator should submit the treasury proposals for the council to vote.

Developer-initiated network upgrade[edit | edit source]

In exceptional cases, the core team may propose network upgrades themselves:

  • If there is a security issue that must be fixed immediately.
  • If a network upgrade has never been passed through coordinator-initiated network upgrade for a long time (one month).

Under this circumstances, the core team will handle the initiation of the whole process, together with, if necessary, any fast track interventions.