ICS003: Remove client and consensus state validation during the connection handshake

[colin-axner]

Summary

Remove the client and consensus state validation which occurs during the connection handshake.

Problem

During the connection handshake, IBC was designed to ensure the correctness of a connection/channel handshake such that when a channel is opened, we know that sending a packet can only be received and processed between two chains which are only connected to each other.

While on paper, this design approach makes a lot of sense, the abstraction of this logic has lead to difficulties on the implementation front.

Light clients represent other chains. A chain will have many light clients, one for each chain it would like to connect to. This abstraction is intuitive. A chain is only responsible for making sure its light clients are properly setup and functioning.

The connection handshake went a step further by ensuring not just that a chain's own light client is properly setup, but that the chain it wishes to connect to, has a correctly setup light client for itself. It does this by validating the client state and consensus state. The important information for a tendermint client, being the chain id and validator set hash.

Note that since we are not proving execution, we are not protecting against a malicious chain. We are only checking correctness of the relayers.

A few problems have arisen over time with regards to this construction:

• not all chains have consensus state information available extend 03-connection with a proof object for chains that can't introspect their own consensus state. #839
• not all implementations of a light client share the same client/consensus state structures Remove Hardcoding of Tendermint Client Validation in Connection Handshake ibc-go#5315
• because client and consensus state keys are proved, additional storage was added to improve iteration Efficient Consensus State Iteration ibc-go#125, consensus state queries are still inefficient Default ordering in gRPC responses assumes lexicographic values of Height, not numerical value ibc-go#1399
• because client and consensus state paths are proved, changing the stored value is very difficult (cannot break client/consensus state structures)
• in ibc-go, historical information is required to be set to lookup past consensus states (leads to additional store writes for infrequent access, also most recently blocked feature req [Feature]: Explore setting create_empty_blocks to false cosmos-sdk#20733)

Proposal

Social consensus is already required to avoid accessing a malicious chain. A user must select a channel which it believes to be correctly setup. Thus, we are not adding much defense with client and consensus state proofs. We should take advantage of the social consensus approach and remove the client and consensus state proof verification in the connection handshake.

Pros:

• reduction in complexity (2 less proofs)
• client and consensus state representation is decoupled from core ibc proofs (allows for breaking changes)
• additional reverse iterator keys in 07-tendermint can be added
• client and consensus state keys can be updated to be iterator efficient
• allows for multiple implementations of a single client with different underlying client state/consensus state structures to be natively supported
• aligns with ibc lite, less work to implement a layer of ibc

Cons:

• more social consensus
• when the stars perfectly align, it is possible that two chains have open connection ends that don't point to each other

[damiannolan]

The pros here outweigh the cons by a lot! Thanks for the writeup