ICS28: Enable the removal of a consumer chain from the provider

[mpoke]

Closes #651

Closes #669

• handle timeouts on the consumer chain side (see TODOs here and here)

[AdityaSripal]

This is really a signaling proposal correct? There's no enforcement involved

[mpoke]

What do you mean by enforcement? If the proposal passes, then the consumer chain is removed once stopTime elapses. Validators can still run full nodes of the consumer chain without being penalized. So in that sense, it is indeed a signaling proposal. The only thing enforced is that validators are no longer slashed for not validating on the consumer chain. Should I make this clearer in the spec?

[AdityaSripal]

No one gets slashed. The child chain could effectively continue running as an independent chai

[mpoke]

Yeah, but with a different set of validators. Or at least not validators got from Interchain Security. Most likely, this would entail the consumer chain stops and is restarted as an independent chain.

[mpoke]

@AdityaSripal Regarding handling timeouts on the consumer chain side (see TODOs here and here), is there anything else that must be done besides shutting down the chain?

How is the provider chain notified that the consumer chain shut down? I guess that the provider either receives a MsgTimeoutOnClose message from the relayer proving that the consumer closed the CCV channel or waits until its own packets timeout, right?

Finally, how can the consumer chain move its CCV channel to CLOSED and shut down at the same time?

[AdityaSripal]

So long as our side does ChanCloseInit, a relayer should be able to do TimeoutOnClose on the counterpary

[mpoke]

So long as our side does ChanCloseInit, a relayer should be able to do TimeoutOnClose on the counterpary

If the consumer chain executes onTimeoutPacket(), the IBC logic will move the channel to CLOSED (e.g., here). This should be sufficient for the relayer to do TimeoutOnClose on the counterpary. However, when is the consumer chain shutting down? It cannot be in onTimeoutPacket(), since the channel will not chage to CLOSED. We could add the following lines to the BeginBlock() of the consumer CCV module

channel = provableStore.get(channelPath(ConsumerPortId, providerChannel))
abortSystemUnless(providerChannel == "" OR channel.state != CLOSED)

What do you say?

[AdityaSripal]

I don't know if there's a way to shut down the consumer chain within the state machine itself. I suppose validators can simply shut down their nodes once the channel has closed (block gets committed). Though they still need to make their nodes available so relayers can query proofs of channel close

[mpoke]

I don't know if there's a way to shut down the consumer chain within the state machine itself. I suppose validators can simply shut down their nodes once the channel has closed (block gets committed). Though they still need to make their nodes available so relayers can query proofs of channel close

This is important since as soon as the CCV channel is closed, the consumer chain is no longer secured, i.e., the validators can do whatever they want. We should be able to cleanly shut down (e.g., export the state and no longer accept TXs).

[mpoke]

I tried to deal with shutting down the consumer chain in the commit ea6919b. @AdityaSripal Could you please have a quick look?

[AdityaSripal]

Nice work Marius!

[josef-widder]

I guess this influences some of the properties in system_model_and_properties.md? For instance, some properties only hold in the case of lockUnbondingOnTimeout = TRUE. In the FALSE case, some misbehavior might not lead to a slashing on the provider chain, for instance?

[mpoke]

Good point. I'll look into it.

[mpoke]

@josef-widder I added a note discussing the implications of calling StopConsumerChain with lockUnbonding set to false (see 3f24b4b).