Add a consensus critical minimum upgrade height

[evan-forbes]

It was brought up by @YazzyYaz that not only do we need a signalling mechanism for validators, but we also need there to be some cutoff for other nodes such as RPC endpoints and light nodes.

One suggestion for implementing such a cutoff would be adding a consensus critical minimum upgrade height. Of course, if this min height is consensus critical, then any variation in the height could cause the network to halt. One example of such variation would be if the min upgrade height needs to be extended for any reason.

The enforcement of a consensus critical minimum upgrade height could be either directly in the state machine, or via prepare and process proposal. If its in the state machine, any variation in upgrade height would result in an app hash mismatch. If the mechanism is enforced in process proposal, then all blocks that include a crank message will be rejected.

[rootulp]

Why do light nodes need a consensus critical minimum upgrade height?

[cmwaters]

Why do light nodes need a consensus critical minimum upgrade height?

They don't. This mechanism is to ensure that enough non-validators have upgraded before the network upgrades by setting a minimum height with which upgrades can occur. This is purely a matter of politeness for block explorers and other teams integrating with Celestia which may take longer to upgrade than simply switching binaries

[cmwaters]

Adding some minimum height is a bit tricky. For example with the v2 upgrade you would already need to add some height for when v3 upgrades is permitted which is largely unknown. Also there would be no flexibility to change this grace period as it would cause non determinism in the state machine across nodes with different versions which could get ugly.

Since this grace period is more of a nice to have, I would firmly advocate for it to not be a consensus critical parameter and instead have it as a local parameter that is baked into the binary. Essentially nodes would reject the crank message in CheckTx if it came before a height that was hardcoded into the binary (so the same for everyone). Of course, this could be overpassed if a proposer wanted to but since this is not a hard requirement but a polite thing to do I think it's tolerable

[rootulp]

They don't. This mechanism is to ensure that enough non-validators have upgraded before the network upgrades by setting a minimum height with which upgrades can occur.

Are you claiming that this feature is only desirable for consensus nodes? If so, should we update the OP to remove "light nodes". If not, can we clarify why this feature is desirable for DA nodes?

if it came before a height that was hardcoded into the binary

Will this hardcoded block height be chain ID specific? Will the hardcoded block height only apply to one version at a time? It looks like this could get messy because we'll need to maintain some map of chain ID to version to block height where block height represents the minimum possible height that a crank message will be accepted (for a given chain ID and version).

If a single proposer can include the crank message by failing to update to a version with the hard-coded minimum upgrade height, I question whether we should build this feature at all because it won't provide any guarantee on when the chain upgrades.

[cmwaters]

Are you claiming that this feature is only desirable for consensus nodes? If so, should we update the OP to remove "light nodes". If not, can we clarify why this feature is desirable for DA nodes?

Okay perhaps I wasn't explaining this clear enough. If you are a rollup that uses a DA light node. If we release the binary and the network quickly upgrades before you upgrade your light node you may no longer be able to validate new headers and become stuck until you upgrade

[rootulp]

IIRC this is no longer considered in scope for v2. If it was in scope then it would need a CIP and there isn't one for it.