plan for consensus parameter updates

[jchappelow]

Consider a relatively simple ConsensusParameters update to the block size. What are our options for facilitating a network change of such a parameter? Do we need cometbft 0.38? Can we just push a software release that defines a height where the parameter would change? I would just like to have a general idea of how we would proceed to change something like this on an existing network, assuming restarting from genesis with the existing datasets is an unacceptable solution.

[charithabandi]

I was thinking of having governance based transactions, where we have a config model that handles config updates and transactions specifying the parameters we want to update and probably height at which this changes can be reflected.

But few questions that came up were:
Do we need network agreement for these changes? - Yes

[jchappelow]

Without cometbft 0.38, governance transactions seems to be the way. I feel like if we restrict proposed changes to existing validators the method could go like this:

• validator makes a tx proposing a change to consensus params (however we want to specify the change is fine)
• other validator operators have to inspect the proposed update to decide if they want to approve
• if the validators approve with threshold, the changes go into effect via ConsensusParamUpdates in EndBlock (just like the validator updates).

With this model I think there's no need for an activation height? Just whenever threshold is reached and ConsensusUpdates is given to cometbft it just happens.

Sounds like the main question are:

• how do we encode the proposed changes? (json would be alright here IMO)
• do we need to build some tooling for validators to decode the proposal from a proposal transaction payload?
• EDIT: how does a validator approve? A digest of the changes, or a token from the initial proposal transaction?
• is there a need to schedule an activation height, and if so how? I am thinking there's no need.

[brennanjl]

You guys have definitely dug into this more, but these are my immediate thoughts:

It seems like the easiest way to do this is that we have a persisted object that tracks the state of consensus parameters. This exists in a data store, is included as a part of the apphash, and in all ways functions like the datastore and validator modules.

A validator would submit a vote to change some consensus parameter. That vote would have an expiration height, and be given a unique ID (maybe based on the transaction ID). Other validators could vote to confirm that consensus parameter. If it receives a requisite number of votes, the change would immediately take effect.

how do we encode the proposed changes? (json would be alright here IMO)

My concern about JSON is non-determinism, but yeah the general idea is that we would have defined a struct for a change / defined structs for different types of changes. Or, if we want to keep it very simple, maybe validators just vote on an entirely new consensus param object? Since it's not an automatic process, validators would be able to see everything that would be changed. This would leave us with one serializable payload for all of consensus params.

do we need to build some tooling for validators to decode the proposal from a proposal transaction payload?

Probably, so that they can analyze the proposed changes. I feel like this would be relatively easy.

EDIT: how does a validator approve? A digest of the changes, or a token from the initial proposal transaction?

As discussed above, they would likely vote "yes" on an unique ID of the proposed changes (maybe the txid)?

is there a need to schedule an activation height, and if so how? I am thinking there's no need.

There could be a need. If the network was going to all of a sudden turn on gas costs, other parties would want to have time to update their tooling. I think it would be pretty easy to add it as optional; if not specified, it would simply be immediate.

It seems we could use Comet v0.38 for this, but I'm not sure how necessary that would be, and it could be more trouble than it's worth. I doubt consensus params would change that often (unlike an oracle). The increase in consumed blockspace from using simple governance transactions is likely worth it to have uniform tracing of validator votes + overall simplicity (as compared to using vote extensions).

[jchappelow]

I think we have a reasonably clear idea how this would be done with formal governance to do voting. However, if we were to release today with none of this in place, I think a height-based hard fork can do this in a pinch. For example, we release v0.6.2 (or whatever) with the following (pseudocode) in EndBlock:

if height == consensusV1ActivationHeight {
    return abciTypes.ResponseEndBlock{
        ConsensusParamUpdates: <new stuff>
    }
}
``