You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 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
@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?
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
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:
CommitmentProof
against the consensus state of the network they representICS-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
ConsensusState
from the Pocket NetworkDeliverable
Client
interface with the necessary methodsConsensusState
andClientState
serialisable objectsConsensusState
for the Pocket NetworkClient
related information in the ICS-24 storesClient
events in the Event Logging systemNon-goals / Non-deliverables
General issue deliverables
Testing Methodology
make ...
make ...
make test_all
LocalNet
is still functioning correctly by following the instructions at docs/development/README.mdk8s LocalNet
is still functioning correctly by following the instructions hereCreator: @h5law
Co-Owners: @h5law
The text was updated successfully, but these errors were encountered: