ICS 2: IBC consensus verification requirements

[cwgoes]

Required functions & semantics of the underlying consensus algorithm / blockchain.

• Security assumptions of the underlying consensus

This ICS should be able to specify exactly the properties & functions a consensus algorithm must be able to provide in order to be compatible with the rest of the IBC protocol. Initially, these will be more or less chosen as the properties that Tendermint has - the most restrictive set we can choose while retaining the properties which are necessary for IBC - that way future possible consensus algorithms can determine what they would need to satisfy in order to support IBC.

[mossid]

I think #2 should contain the requirements that the other ICSs are relying on, for example, #3 need a way to verify a header, #6 needs a way to determine whether the chain is malicious or not. The basic concept of "chain" can provide the criteria what is expected and what is wrong.

#7 is more like Tendermint lite client specification, where the tendermint lightclient headers are satisfying the consensus requirements. This way we can build the ICS components, such as connection, channel, and others on the consensus requirements while adding more consensus algorithms(e.g. Nakamoto + FG) to the ICSs.

[zmanian]

Some thoughts on requirements for consensus requirements for IBC.

Consensus should be

1. Proof Carrying
2. Asynchronously safe consensus
3. Finality

[cwgoes]

Some thoughts on requirements for consensus requirements for IBC.

Consensus should be

1. Proof Carrying

2. Asynchronously safe consensus

3. Finality

Yes; @mossid and I tried to capture these requirements, and others, in discussion, we think we can reason about the lite client verifier as providing information about what must have happened in a full node "full consensus" process - we'll write that up.