Re-evaluate use of light client functionality in relayer

[ancazamfir]

Crate

relayer

Summary

I have some doubts wrt the way we are using the tendermint light client in our relayer, trying to detail here.

Problem Definition

We should be able to create IBC light clients on chain X for the same chain Y with different security parameters (aka options).
Currently the options are defined globally and relayer light clients are initialized before any IBC clients are created on chain. The configuration is also modified to keep the light client store information and having multiple relayer light clients per chain is hard to manage.
There are also issues when we try to use IBC clients created by other relayers and that don't have a corresponding local light client instantiated.

Proposal

At a high level:

• remove the light client sections from config. The config should only keep the chain info (full node rpc address and chain specific parameters) and

• keep default light client options/ security params

• no need to have a light client store, the store is on chain

• no need for the supervisor

• on create-client:

  • security options default from config, and
  • allow security options to be specified (height, hash, other options) in the CLI (Allow custom options when creating IBC clients #836)
  • relayer calls light client (lib) to fetch a light block from primary (similar to what we do at init today)
  • relayer stores this on chain via the MsgCreateClient

• on update-client the relayer:

  • gets the latest trusted light block from chain
  • gets the target height from context (e.g. latest if from CLI, height tight to proofs and events), same as today
  • retrieve verification trace from the light client (Retrieve minimal set from light client and include supporting headers in client updates #1058)
  • updates the chain with the set of light blocks

• relayer implements misbehavior monitoring and evidence submission (in progress):

  • listens to update client events
  • gets the light block for the update height from chain
  • gets light block(s) from the full node(s) it is configured with (light client fetch light block) and
  • verifies that they are the same
  • submits to chain the the MsgMisbehaviour with the two blocks as evidence
  • submits evidence of misbehaviour to the light client Relayer requirements for the Light Client tendermint-rs#497
  • all this happens in a background process/ thread, will very likely include this in Prevent client expiration #786

• summary of API needed from the light client:

  • fetch_light_block(rpc_address, height) that returns LightBlock
  • get_minimal_set(rpc_address, trusted_light_block, target_height, options) returns Vec<LightBlock> (Relayer requirements for the Light Client tendermint-rs#497) not actually needed, see Retrieve minimal set from light client and include supporting headers in client updates #1058

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate milestone (priority) applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[ancazamfir]

Closing as all has been implemented/ changed. The only item left is covered by #836