Relayer Message Builder logic

[ancazamfir]

Summary

Describe and implement the message builder algorithm and FSM

Problem Definition

The Message Builder is a Relayer module that contains most of the logic of how IBC datagrams are built. For an event based model, this should be implemented as an FSM.
There should be clearly defined events and actions (routines).
An analysis of the action to be taken for each (state, event) combination should be done. Given ~15 events and ~10 states,
this may seem like an overwhelming task. However, many combinations can be ignored (e.g. all packet events for a connection builder FSM).
For a builder of message related to some object X, only the IBC events related to X and its flipped version (if one exists) and to the client(s) involved should be considered.
It will probably be the event handler that decides to remove an existing message builder when a "superior" event occurs for same X (e.g. a builder is in progress for ConnOpenTry to B message and a notification for ConnOpenTry from chain B is received for the same object)

Consideration should be given to having an FSM framework that presents events as generic or trait objects, with concrete implementations limited to object specific details. In the same time, it should be implemented such that it is very clear what is the action taken in a given state and for a given event.

Proposal

Here is one draft proposal, final decision and implementation may look differently. Only main "success" path events and actions are shown. Shown in italics are states valid for builders of messages connOpenTry and connOpenAck only.

Details should be included in an ADR and also documented in the implementation.
(lower level issues to be raised soon)

---

For Admin Use

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

[ebuchman]

One way of thinking about the relayer might be that, for each chain it's connected to, it synchronizes the chain's entire IBC store (ie. the whole store/ibc/key namespace). It could literally maintain a local copy of the whole ibc kv-store for each chain. This could be done using events+querying, but it could also be done instead by processing the IBC transaction messages directly, which would effectively amount to an implementation of a good chunk of IBC handler logic. (And bonus, if it used an IAVL tree for the local kv store, it could avoid having to query for merkle proofs all together, since it could do them itself).

If the relayer had a local copy of each chain's IBC store like this, it could model and test this whole message builder flow more directly between local copies, without having to worry about querying from and sending transactions to real chains. While we wouldn't have an IAVL tree, we could mock out the proof verification part, and just capture the core state transitions of the ibc store.

Without building something like this, I can imagine it's going to be very cumbersome to test the whole system, since we'll be depending on Go software, and integrations with all the queries and txs are likely to still take some time (ie. we're waiting for tendermint v0.34 to release, need to get tendermint-rs upgraded to it, then need proto files for clients in the sdk; we're still waiting some time for proto tx integration; etc.)

Having the local model might also really help clarify all the flow and what IBC is really about, and would get us significant progress towards the handlers.

[adizere]

Having a mirror of the IBC store of each chain is clearly helpful. To make this idea concrete, for connection handshake in particular, the relayer flow depends on the following interactions:

• query client consensus state on both chains + proof [x]
• query the state of a specific object (e.g., a connection or channel) on a chain + proof [x]
• query (fetch) headers from each chain
• submit datagram + proofs to destination chain

The bullets marked with [x] we can model/mock with the help of the local copy of IBC stores if I understood correctly. As a side note, we could take this idea even further and assume that the relayer participates as a full node in both chains.. and then we can fulfil locally all the bullets above.

[adizere]

We decided on a different relayer architecture (#326), which does not require the message builder anymore.