ADR 0006: Consensus Governance

[kostko]

Rendered

[jcueto]

Here we can specify: "Since these are consensus parameters, they need to be specified in the genesis file and will be the same across all proposals."

This will help clarify the nature of the parameters.

[jcueto]

Maybe we can explicitly point out that this includes both self-delegations and delegations from other users, since conceptually sometimes people think about delegation as primarily in the "delegations from other users" case.

We can just add parentheses at the end: "(including both self-delegations and delegations from other users)."

[ptrus]

Is #2596 a prerequisite for this ADR? Or maybe at least a "good to have", so voters can actually confirm the proposed upgrade identifier (hash) matches a specific source code. (i guess alternatively, although not ideal, we could use something like hash of the source code?)

[kostko]

Yes, that's right. So in theory the hash could also be a Git commit or a hash of a manifest containing further information.

[bennetyee]

This seems a little odd: we prevent new proposals when one is pending, but as long as active proposals have not been voted on and moved to pending state, additional proposals can be made. Is the intent to prevent two pending proposals from becoming ... "in use" (i.e., approved and switch-over epoch has passed, so presumably all node operators have picked up the implementation or implemented the proposal themselves)? What happens (if anything) if two or more active proposals go into pending state and their switch-over epochs are close to each other, e.g., within upgrade_min_epochs_diff of each other?

Not a critical issue, but just wanted clarification / trying to understand the intent.

[kostko]

we prevent new proposals when one is pending, but as long as active proposals have not been voted on and moved to pending state, additional proposals can be made

I think this is just a misunderstanding, there are two things to an upgrade:

• First a governance upgrade proposal is created and it goes through the voting process.
• Only if the vote passes is an upgrade pending.

So this does not refer to other pending governance upgrade proposals but to already passed pending upgrades.

What happens (if anything) if two or more active proposals go into pending state and their switch-over epochs are close to each other, e.g., within upgrade_min_epochs_diff of each other?

See the Proposal Content Execution section below where there is another check when the passed governance upgrade proposal is executed. Only one upgrade can be pending and if two upgrade proposals are passed, the second one will fail to execute.

[ptrus]

If we follow the existing convention, I think these identifiers will start at 0x90 (and the governance app id will be 0x09) since 0x08 is in use by the new improved beacon already.

[kostko]

Hm, so I looked at the beacon when deciding on this and it uses the prefix from the previous beacon/epochtime apps which seems like the right thing to do:

oasis-core/go/consensus/tendermint/apps/beacon/state/state.go

Lines 16 to 32 in ae0e671

	// epochCurrentKeyFmt is the current epoch key format.
	//
	// Value is CBOR-serialized epoch time state.
	epochCurrentKeyFmt = keyformat.New(0x30)
	// epochFutureKeyFmt is the future epoch key format.
	//
	// Value is CBOR-serialized epoch time state.
	epochFutureKeyFmt = keyformat.New(0x31)
	// beaconKeyFmt is the random beacon key format.
	//
	// Value is raw random beacon.
	beaconKeyFmt = keyformat.New(0x40)
	// parametersKeyFmt is the key format used for consensus parameters.
	//
	// Value is CBOR-serialized beacon.ConsensusParameters.
	parametersKeyFmt = keyformat.New(0x41)

The app id for the beacon should be changed to 0x04 to be consistent.

[ptrus]

Ok yeah I also saw the comment in the beacon PR 👍

[pro-wh]

my summary:

this adds on-chain yes/no/abstain voting for "proposals." entities can vote, and their votes are counted proportional to their stake if they are a validator at the time the proposal is set to close. as an optimization for stable validator committees, they must also be validator at the time they vote. they can also change their vote leading up to the proposal close time.

this adds a set of proposal types for managing network upgrades. the on-chain representation of a proposed upgrade https://github.com/oasisprotocol/oasis-core/blob/v20.12.1/go/upgrade/api/api.go#L66 is mostly opaque, other than the epoch when it happens. this type and the mechanisms around it are already part of the codebase.