ICS28: Sovereign to consumer chain transition

[mpoke]

Closes #834

Also closes #830

The protocol in a nutshell:

• A sovereign chain sends a proposal with the following fields

    chainId: string // the ID of the chain
    spawnTime: Timestamp // the earliest time when the proposal can be handled 
    connId: Identifier // the ID of an existing connection end on the provider chain on top of which the CCV channel will be created

• The provider only accepts proposal with chainIds not already in use
• The provider validates connId
• The provider creates a genesis state for the consumer CCV module with the following fields

      preCCV: true, // flag indicating that the consumer CCV module will start in a pre-CCV state, i.e., it doesn't provide valset updates to Tmint
      connId: connectionEnd.counterpartyConnectionIdentifier, // connection ID on the sovereign chain
      initialValSet: initialValSet, // the current validator set on the provider chain

• The sovereign chain upgrades to add the consumer CCV module and initializing it using the genesis state queried from the provider

• A relayer starts the channel opening handshake

• On ACK, the sovereign chain calls the ReplaceValset method of the staking module which replaces the validator set with initialValSet from the genesis state.

• Once the validator set in the header matches initialValSet (typically two heights later), the sovereign chain upgrades to a full consumer chain, i.e., preCCV = false and the staking module is replaced by the consumer CCV module (in other words, the pre-CCV state is over).

• Note that the overview of the channel initialization protocol still needs to be updated.

[josef-widder]

I am lacking a bit of context here. From the diff, it looks like this method of becoming consumer chain replaces the idea of spawning. Is this right?

In theory we can completely swap out the valset from one block to the other. In practice, we would need that the new validators have synced to the system. I guess this requirement is captured somewhere else (a handbook) and is not part of the spec?

[AdityaSripal]

Nice work. I like the proposed protocol, have some nits

[AdityaSripal]

if defined

[mpoke]

If it's not define, it will be set to "" (the default value of gs.distributionChannelId) and then a distribution channel will be created in onChanOpenAck.

[danwt]

I don't see exactly why this is necessary, it can be left to

ibc/spec/app/ics-028-cross-chain-validation/methods.md

Line 1416 in 01dbba9

SendPendingSlashRequests()

It will be later, but maybe that doesn't matter.

This is anyways far behind the current code, which only ever sends packets from the consumer in EndBlock https://github.com/cosmos/interchain-security/blob/4474a08a43feb8e8de227f6a7ee8b33f724ab9b5/x/ccv/consumer/keeper/relay.go

(Just FYI)

[mpoke]

I don't see exactly why this is necessary, it can be left to

ibc/spec/app/ics-028-cross-chain-validation/methods.md

Line 1416 in 01dbba9

SendPendingSlashRequests()

The call to SendPendingSlashRequests was moved from onRecvVSCPacket to onChanOpenAck as from the consumer's perspective the CCV channel is established when it receives the first valid ChanOpenAck msg. Before, the CCV channel was established when receiving the first VSCPacket.

This is anyways far behind the current code, which only ever sends packets from the consumer in EndBlock https://github.com/cosmos/interchain-security/blob/4474a08a43feb8e8de227f6a7ee8b33f724ab9b5/x/ccv/consumer/keeper/relay.go

These changes in the code were not added to the spec yet.

[danwt]

It's quite hard for me to say anything precise about the changes. Overall, I didn't notice any mistakes, and I think the protocol concept is good.

Remark: maintaining this level of detail seems futile. The method.md file is essentially 2k+ lines of uncompilable code. Noone can read this and say that there are no mistakes.

Nice work though, the upgrade mechanism appears solid. I need to learn more ibc subtleties to be able to give more valuable feedback.

[josef-widder]

I have reviews the changes since our last synchronous discussion. In particular the overview. Looks great. I think the transition from sovereign to consumer might also have interesting applications in the future.

[josef-widder]

Is this the only place where this requirement is captured? Would it make sense to have it also somewhere in the properties?

[mpoke]

Good point. I added a note to the Bond-Based Consumer Voting Power property.