ICS 14: IBC consensus state upgrade protocol

[cwgoes]

Will cover:

• Protocol for altering IBC root-of-trust (can be enabled as an option in the negotiation handshake)

[cwgoes]

Datagram formats that need to be defined here:

• CONNROTUPGRADE
• CONNROTUPGRADEACK

(do we need a three-way?)

[ebuchman]

How is this distinct from the regular lite client update operation?

[cwgoes]

This was proposed by @zmanian - it would be a secondary way to update a root-of-trust in case of an irregular chain upgrade (which might change the chain ID) or a fork (so the 2/3 signature requirement could be relaxed gradually after some time period had passed).

[cwgoes]

I am not sure if this needs to be designed separately from the flexible light client validity predicate already included in ICS 2.

@zmanian Do you envision governance involvement for "approving" a consensus state upgrade? In that case this should be specified separately. If it's just a special operation on the originating chain (which can be signed over), the light client validity predicate can incorporate it.

[zmanian]

So I guess there are two schools of thought here.

1. Signaling of an irregular state upgrade should occur in the tendermint header.

2. The Signaling of an irregular state upgrade should be it's own datatype signed by a quorum of validators.

I am very much in favor of the 2nd approach but I've heard that others have a preference for the 1st one.

I think the 2nd mechanism is the most general and will work well of instance in cases where the chain has halted. Essentially the validators can just have a mechanism for signing this packet

If we go with the second mechanism, the ValidityPredicate needs to be able handle a message of the irregular update and then it causes the next consensus state to be zero. All the connection and channel information needs to be persisted across the the irregular update.

[cwgoes]

The validity predicate in ICS 2 has become sufficiently general that it encapsulates this.