Announcing Go Relayer v2.0

The v2 release of the go relayer is a milestone in the development of the Interchain and sets a new standard for IBC technology. Building upon Strangelove’s many years of experience building and deploying IBC, it brings a more scalable event based architecture which drastically reduces query load on RPC nodes and allows for integration of non-Cosmos chains into IBC. Join us as we walk through the major new abstractions and features.

Chain Processor - IBC Chain Event Bus

The Chain Processor is an event bus that processes the events from each finalized block on a supported chain and emits them for action by the Path Processor (discussed later). The go relayer originally relied on the Tendermint websocket connection for events and notifications of each block. In testing the websocket worked fine, but exposure to production workloads showed significant issues with websocket reliability and necessitated a polling approach. This polling approach was more reliable but caused significant load on chain nodes supporting the relayer, causing operators additional cost and the slowing down of packets.

The go relayer v2 solution is to poll for blocks (previous implementations queried a lot of state), parse the events from them, and then create an event stream to be consumed and acted on. This is the role of the Chain Processor. Strangelove intends this event stream to be the basis for other applications like arbitrage and MEV bots.

Path Processor - Event based relaying

The Path Processor abstraction consumes and acts on the events emitted by the Chain Processor. This moves the go relayer to an event-based architecture. We have also migrated the handshake logic to this pattern with the result that handshakes now complete in 30-40% fewer blocks.

By architecting the Chain and Path Processors as their own subsystems, the go relayer is now able to cover any number of channels and chains simultaneously within the same process, drastically reducing the burden on operators. This feature will be released in v2.1.0 coming in mid-August 2022.

Connection Based Relaying

Another change that comes with v2 is a move to connection-based relaying. Initially there was just one IBC protocol: token transfers. With the dawn of interchain accounts, interchain queries, and contract-to-contract IBC, channels become an implementation detail. As a result, relaying all of the channels on top of a specified connection automatically becomes a critical feature. Any new channel created on top of the specified connection will have its handshake automatically completed and those packets will immediately be relayed. The go relayer v2 also accepts an allowlist or a denylist for channel filtering.

Configuration - Automating the Interchain

Relayer configuration has always been highly manual and required editing a configuration file, often by hand. With the advent of the chain registry we can now automate all this manual work and provide standard RPC servers to help users get up and running quickly.

Chain Provider - Expanding the interchain

The Chain Provider abstraction moves all the chain-specific logic for querying and transacting with IBC chains behind an interface. This allows for the implementation of non-Cosmos SDK-based chains into the go relayer. We currently have implementations in progress for Penumbra (a privacy focused zone) and Polkadot (ComposableFi leading the integration). This expansion of IBC is critical to the long term success of the protocol and Strangelove will continue to prioritize this important work.

What’s Next?

• Prometheus metrics for the relayer to show relayer performance on relayed channels, whole channel statistics (i.e. total number of packets, acks, timeouts), and share of channel statistics.

• Automated fund management, giving users a single deposit address and automated trading into fee currencies on each chain

• Reasonable feature requests accepted, just open an issue!

Strangelove Team Contributors:

• @mark-rushakoff - ibctest integration lead and code review for provider/processor refactors

• @jtieri - provider and connection based relaying refactors lead and code review for processor refactor

• @agouin - processor refactor lead and global code review

• @boojamya - configuration refactor lead and associated chain-registry work.