[IBC] Implement ICS-02 IBC Light Client Interface

[h5law]

Objective

IBC relies on the verification of state of a counterparty chain through the use of IBC "light clients". IBC light clients are not "fully featured" light clients from the typical sense of the word, instead they are simply state verification algorithms. They are given the current state of the chain they represent periodically by relayers and must:

1. Verify the state transition is valid (2/3 of their trusted validator set has signed the new state they receive)
2. Identify misbehaviour from the chain it represents
3. Verify the inclusion/exclusion of any particular element via a CommitmentProof against the consensus state of the network they represent

ICS-02 defines the interface, functions, data types and processes to interact with IBC clients in general. ICS-02 is not an implementation of any particular client but instead defines how each client implementation must work.

This issue tracks the creation of such an interface and all other definitions outlined by the ICS-02 specification

Origin Document

ICS-02 Specification IBC Light Clients Document

Goals

• Implement the relevant Client interfaces, types and functions
• Add CLI and RPC endpoints to retrieve the current ConsensusState from the Pocket Network
• Add more information to the block headers for state verification purposes
• Allow for the querying of IBC client specific information through ICS-24's store system

Deliverable

• [ ] Create the Client interface with the necessary methods
• [ ] Create the ConsensusState and ClientState serialisable objects
• [ ] Create endpoints to retrieve the ConsensusState for the Pocket Network
• [ ] Allow the storage of Client related information in the ICS-24 stores
• [ ] Store different Client events in the Event Logging system

Non-goals / Non-deliverables

• Implement a Pocket IBC Light Client

General issue deliverables

• [ ] Update the appropriate CHANGELOG(s)
• [ ] Update any relevant local/global README(s)
• [ ] Update relevant source code tree explanations
• [ ] Add or update any relevant or supporting mermaid diagrams

Testing Methodology

• [ ] Task specific tests or benchmarks: make ...
• [ ] New tests or benchmarks: make ...
• [ ] All tests: make test_all
• [ ] LocalNet: verify a LocalNet is still functioning correctly by following the instructions at docs/development/README.md
• [ ] k8s LocalNet: verify a k8s LocalNet is still functioning correctly by following the instructions here

---

Creator: @h5law Co-Owners: @h5law

[Olshansk]

@h5law I looked at all the goals & deliverables and this is definitely a hefty task. I think it makes sense to keep this as one issue but make sure to try and keep the PRs small and independent as you're working on it.

Identify misbehaviour from the chain it represents

Do you have pointers/ideas as to what this may be? For example: double signing, invalid tx, other types of Evidence?

[h5law]

@Olshansk

Do you have pointers/ideas as to what this may be? For example: double signing, invalid tx, other types of Evidence?

So here misbehaviour is actually relatively simple ie: is the new block height more than the previous one. This kind of thing. I will find a reference and give more details but it's not much more complex than some basic validation.

Hefty task

This will actually be a smaller PR compared to the interface implementation with ICS-08 which will be a separate issue and PR. Im hoping to use this to setup the WASM integration to be smoother. ultimately this will be laying the groundwork for the client implementations to come