Relayer requirements for the Light Client

[ancazamfir]

Summary

Relayer requirements (shown in bold) for and interactions with the per-chain light clients.

Proposal

(re)Stating the light client relayer interactions with the light client:

• The relayer needs to send MsgUpdateClient specifying a light block at some height h, trusted height t and valset as the trusted validator set (fetched at t+1). In order to build this message, it needs:

  • fetch_light_block(t+1) -> gets the valset
  • get_minimal_set(t, h) -> if the header at h doesn't verify directly with t, the supporting headers in-between should be provided. this is already implemented as State::get_trace(). We can make use of it directly from ibc-rs. (Retrieve minimal set from light client and include supporting headers in client updates hermes#1058)

• misbehaviour_evidence(h1, h2) The relayer monitors client update messages and verifies the headers against locally configured full node witness(es). If evidence of misbehaviour is found, the relayer submit the evidence to the IBC client on chain (this is done currently in ibc-rs). In addition the relayer should submit the evidence to the full node.
  Alternatively the relayer could call light client with check_misbehaviour(h1) and get back some h2 if the light client detects misbehaviour.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[ancazamfir]

@milosevic please take a look if it reflects our discussion. Where should this be included wrt to documentation? I tend to update the relayer ADR with everything :) Should we start another ADR?

[adizere]

Should we start another ADR?

Yes, I vote for this.

Would also be useful to have a terminology or dictionary document to resolve ambiguities around the term client, since I find it confusing. There are two kinds of light clients we're referring to here:

1. Relayer client: a thread running inside a relayer. This is sometimes called "per-chain light client" or just "light client".
2. IBC client: a client hosted on a chain, running on all full nodes of that chain. Sometimes called "on-chain client".

What these clients have in common is that they are both an abstract layer of communication to a certain chain, e.g., can verify headers of that chain or fetch headers.

Please let me know If this distinction is accurate @ancazamfir @milosevic. Then I can write it down in a more permanent form somewhere. I propose we try to avoid using different terms than the two ones above.

[romac]

Let's move this to v0.18 as we will likely not have time to get it done for v0.17. Will tackle this once it's actually needed on the ibc-rs side.

[thanethomson]

@romac, when do you anticipate this will be needed in ibc-rs?

[romac]

Very soon :) I am actually going to start working on that this week.

[ancazamfir]

Made some updates to the issue to reflect the recent changes in the relayer light client. I think first priority is to get get_minimal_set(t, h) in.

[ancazamfir]

• misbehaviour_evidence(h1, h2) The relayer monitors client update messages and verifies the headers against locally configured full node witness(es). If evidence of misbehaviour is found, the relayer submit the evidence to the IBC client on chain (this is done currently in ibc-rs). In addition the relayer should submit the evidence to the full node.

Looked a bit in the light client code and this looks as the simpler solution: an API that eventually calls into

tendermint-rs/light-client/src/evidence.rs

Line 16 in 877e408

fn report(&self, e: Evidence, peer: PeerId) -> Result<Hash, IoError>;

I guess the relayer will need to pass the two conflicting headers (h1 and h2) and the peerId, url and timeout to the API, which should instantiate a ProdEvidenceReporter and report ConflictingHeadersEvidence with h1 and h2.

Alternatively the relayer could call light client with check_misbehaviour(h1) and get back some h2 if the light client detects misbehaviour.

Currently the relayer pulls the first header from the IBC client on chain and the second header from the full node for the counterparty chain. It then compares the two. The comment above refers to moving the pulling of second header in the light client library (or making use of existing functionality...haven't traced it yet) and submitting evidence to the full node and returning the evidence back to the relayer who will submit it to the IBC client on chain. I think we can do this later.