Propose and implement conditional feature activation

[troggy]

Bounty

All the consensus-breaking changes to leap-node should be applied only when a 2/3+ of validators are signalled they ready to apply the change.

Problem: Consider all the validators are running the same leap-node version. Then a new leap-node version is released with a consensus breaking change. Some of the validators may upgrade to it, some are not or going to do it later. In any case, there is no coordinated upgrade and at some point of time validators will run different versions of consensus and the chain will stop.

Proposed solution: Implement some sort of system for validators to signal which consensus version/features they support. Other node should collect these signals and activate corresponding consensus/feature only once a quorum of validators (2/3+) voted to use it.

Scope

• implement a validator signalling scheme
• test it on some consensus breaking change

Deliverables

• updated code
• updated tests
• (ideally) add integration tests

Gain for the project

possiblity to upgrade node in PoS environment

Expert

@johannbarbie @troggy

Publicly visible delivery

Roles

bounty gardener: @troggy / 100 DAI or 15% if a lot of support is needed for worker bounty worker: name / share bounty reviewer: name / share

Funded by

Dev Circle

[troggy]

@johannbarbie @TheReturnOfJan @pinkiebell @sunify would appreciate your attention here — is it defined well and makes sense? Can it be solved differently?

[pinkiebell]

All the consensus-breaking changes to leap-node should be applied only when a 2/3+ of validators are signalled they ready to apply the change.

Sounds good so far. On the implementation side, tendermint allows appHash to change after each block, that can be used to signal the upgrade and prohibit from old tendermint nodes to participate in consensus. But that's old knowledge, maybe tendermint supports a better system now 🤷‍♂

[troggy]

@pinkiebell I thought of changing the flag system we have now like that:

• flags are not affecting the logic, but rather being put in a data for heartbeat NST (as a bitmap?). Heartbeat NST are being broadcast already, this way the validators signal which features they support
• all the nodes listen to each other's heartbeat txs, read NST data and aggregate it for feature activation. Once enough validators have signaled they support feature X (as per their heartbeat NSTs) the feature is activated (similar as it is now with flags)

[pinkiebell]

@pinkiebell I thought of changing the flag system we have now like that:

• flags are not affecting the logic, but rather being put in a data for heartbeat NST (as a bitmap?). Heartbeat NST are being broadcast already, this way the validators signal which features they support
• all the nodes listen to each other's heartbeat txs, read NST data and aggregate it for feature activation. Once enough validators have signaled they support feature X (as per their heartbeat NSTs) the feature is activated (similar as it is now with flags)

Got it, I'm not aware of the flag system. But in case there are bad validator nodes, can this be a problem in tendermint consensus (halting chain) if only the flag system is used?

Using appHash signals tendermint to not bother with blocks that doesn't match the new appHash anymore.

[troggy]

Using appHash signals tendermint to not bother with blocks that doesn't match the new appHash anymore.

Yes, that would work, though it will require high coordination from the validators. Imagine a validator set of [V1, V2, V3, V4 ...] running consensus X. Then new feature is being rolled out into leap-node and V1 decides to switch it on. His block will be rejected as he runs X' and others may still run X. So there is a natural disincentive to upgrade first, because you may skip some period submissions. Moreover, the consensus will be stopped easily for controversal features (e.g. validator set is split 50/50% supporting the feature).

But you approach has a big PRO — it is way simpler to implement and that is great 😆

[troggy]

after a talk with Jan on this matter, I'm more convinced to go pinkie-way and include feature flags (or simply "consensus version" number) into appHash/app state. Easy, robust and no conditionals needed everywhere to guard features (that's huge!). On the downside: validators will need some off-chain mechanism to coordinate upgrades. Could be as simple as blog or message board. I think this is not a problem for now.

UPD: actually, there is nothing to do in this case — different code version already lead to different appHashes 🤔

[troggy]

expired. Needs to be resubmitted by gardener