Repository navigation
[IBC] Implement ICS-02 IBC Light Client Interface #894
Copy link
Copy link
Closed
Description
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:
- Verify the state transition is valid (2/3 of their trusted validator set has signed the new state they receive)
- Identify misbehaviour from the chain it represents
- Verify the inclusion/exclusion of any particular element via a
CommitmentProofagainst 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
ConsensusStatefrom 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
Clientinterface with the necessary methods - Create the
ConsensusStateandClientStateserialisable objects - Create endpoints to retrieve the
ConsensusStatefor the Pocket Network - Allow the storage of
Clientrelated information in the ICS-24 stores - Store different
Clientevents 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
LocalNetis still functioning correctly by following the instructions at docs/development/README.md - k8s LocalNet: verify a
k8s LocalNetis still functioning correctly by following the instructions here
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
ibcIBC specific changesIBC specific changes
Type
Projects
- StatusShow more project fieldsDone
Activity
Olshansk commentedon Jul 10, 2023
@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.
Do you have pointers/ideas as to what this may be? For example: double signing, invalid tx, other types of
Evidence?h5law commentedon Jul 10, 2023
@Olshansk
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.
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