🚧 🚧 🚧 🚧 🚧 🚧 🚧 🚧 🚧 🚧 WORK IN PROGRESS 🚧 🚧 🚧 🚧 🚧 🚧 🚧 🚧 🚧 🚧
Table of Contents
Scope of this document
In the dedicated sub-protocol working group meeting from April 5th, we concluded that it would be useful to sketch out a possible update process for two exemplary scenarios.
See  👉 Protocol Version Upgrade Mechanisms Discussion (flow forum post) 👈 for terminology
Consensus nodes require a Quorum Certificate [QC] for view v-1 to advance to view v, which is part of the block proposal for view v. Imagine we change the block header, then a node not supporting the new protocol will remain at view v-1. Decoding newer blocks will fail, because the node does not know the new block header. Potentially even worse, the node may assume that this block is byzantine and erroneously raise a slashing challenge against the proposer.
<aside> 💡 We would like nodes to realize themselves that they don’t support the requires protocol version going forward, without needing observe some protocol message with a version they don’t support anymore!
</aside>
The Jolteon variant of HotStuff guarantees that each view concludes either with a QC or a Timeout Certificate [TC]. However, on the happy path the QC propagated as part of the subsequent proposal.
<aside> 📶 While Jolteon generates a certificate that concludes each view, this certificate is generally not communicated as a stand-alone message for efficiency reasons.
</aside>
(A) QC/TC communication
We could expand how we communicate QCs. Though, there would probably be a broad range of affected code. Generally, we want to guarantee that nodes see a QC or TC ending view v-1 (last view of the old protocol version). This must be solved for nodes actively participating as well as nodes catching up. There are a variety of affected implementation areas: