Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[IBC] Implement ICS-02 IBC Light Client Interface #894

Closed
14 tasks
h5law opened this issue Jul 10, 2023 · 2 comments · Fixed by #932 · May be fixed by #933 or #916
Closed
14 tasks

[IBC] Implement ICS-02 IBC Light Client Interface #894

h5law opened this issue Jul 10, 2023 · 2 comments · Fixed by #932 · May be fixed by #933 or #916
Assignees
Labels
ibc IBC specific changes

Comments

@h5law
Copy link
Contributor

h5law commented Jul 10, 2023

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

@h5law h5law added the ibc IBC specific changes label Jul 10, 2023
@h5law h5law added this to the M7: Pocket NoS (North Star) milestone Jul 10, 2023
@h5law h5law self-assigned this Jul 10, 2023
@h5law h5law moved this to Up Next in V1 Dashboard Jul 10, 2023
@Olshansk
Copy link
Member

@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
Copy link
Contributor Author

h5law commented Jul 10, 2023

@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

@h5law h5law moved this from Up Next to In Progress in V1 Dashboard Jul 13, 2023
@h5law h5law moved this from In Progress to In Review in V1 Dashboard Jul 24, 2023
@github-project-automation github-project-automation bot moved this from In Review to Done in V1 Dashboard Jul 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment