Extend the Chain trait to enable listening for IBC events from non-Cosmos SDK chains, eg. Substrate

[DaviRain-Su]

Crate

None

Summary

init_event_monitor Support multiply chain to event mointor

https://github.com/informalsystems/ibc-rs/blob/8944f94815c35b2d3297971aa437900d259dc75a/relayer/src/chain.rs#L99

/// Initializes and returns the event monitor (if any) associated with this chain.
    fn init_event_monitor(
        &self,
        rt: Arc<TokioRuntime>,
    ) -> Result<(EventReceiver, TxMonitorCmd), Error>;

https://github.com/informalsystems/ibc-rs/blob/8944f94815c35b2d3297971aa437900d259dc75a/relayer/src/event/monitor.rs#L132

pub struct EventMonitor {
    chain_id: ChainId,
    /// WebSocket to collect events from
    client: WebSocketClient,
    /// Async task handle for the WebSocket client's driver
    driver_handle: JoinHandle<()>,
    /// Channel to handler where the monitor for this chain sends the events
    tx_batch: channel::Sender<Result<EventBatch>>,
    /// Channel where to receive client driver errors
    rx_err: mpsc::UnboundedReceiver<tendermint_rpc::Error>,
    /// Channel where to send client driver errors
    tx_err: mpsc::UnboundedSender<tendermint_rpc::Error>,
    /// Channel where to receive commands
    rx_cmd: channel::Receiver<MonitorCmd>,
    /// Node Address
    node_addr: Url,
    /// Queries
    event_queries: Vec<Query>,
    /// All subscriptions combined in a single stream
    subscriptions: Box<SubscriptionStream>,
    /// Tokio runtime
    rt: Arc<TokioRuntime>,
}

Problem Definition

Recently I am doing support for substrate relayer support, for event listening here, it seems that there is no support for multiple chains like ChainEndpoint defines an interface, here for EventMonitor to listen to events suitable for tendermint-rpc strong binding, no implementation and different chains between the loose coupling. Is there a good implementation to achieve this part of the function, because I found that this EventMointor in the implementation of start and listen command is related.

Proposal

None

Acceptance Criteria

None

---

For Admin Use

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

[romac]

Hi @DaviRain-Su, thanks for opening this issue! If I understand correctly, you are rightfully pointing out that the EventMonitor (which Hermes uses to listen for events from a chain) only works for Cosmos SDK based chains and that we should extend the Chain trait to allow non-Cosmos chains to implement their own version of the EventMonitor.

What do you suggest to fix this?

Would extending the Chain trait with a new method

    fn init_event_monitor(
        &self,
        rt: Arc<TokioRuntime>,
    ) -> Result<(EventReceiver, TxMonitorCmd), Error> {

work for you?

At the moment, the EventReceiver type is defined as follows:

pub type EventReceiver = channel::Receiver<Result<EventBatch>>;

where EventBatch is defined as

pub struct EventBatch {
    pub chain_id: ChainId,
    pub height: Height,
    pub events: Vec<IbcEvent>,
}

Do you think this would work? To be more clear, do you think it would be possible for Substrate to emit events such that we can feed them into a channel that emits EventBatches?

If you had some example code from your implementation, for example your implementation of the Chain trait for Substrate, it would be very useful to us to get a better understanding of what the requirements are.

[faddat]

this is super exciting.

<3

[DaviRain-Su]

@romac Thank you for your reply, do you see the logic of my modification here, my understanding for Newblock this event is the event of generating a new block on the node. For substrate is to generate SystemEventSuccess event. There may be some problems here. And for the chain request to substrate rpc request is used substrate-subxt. The last question is, for start this command also seems to be related to Eventmointor, I would like to know where are some difficulties in adapting this command here.

This is my code: https://github.com/octopus-network/ibc-rs/blob/b7d1556aae68262504115115330571795b5ec038/relayer/src/event/substrate_mointor.rs#L347

[romac]

@DaviRain-Su What do you think of the refactoring in #2865? Does this help with your use case?

[DaviRain-Su]

It looks good, but there are still some components that are strongly related to tendermint that I wish could be abstracted

[romac]

Closed by #2865: #2865 (comment)