Skip to content

Relayer Next Overview

Sean Chen edited this page Jun 27, 2023 · 7 revisions

Motivation

With the IBC ecosystem starting to see more interest and buy-in from non-Cosmos chains, the types of relaying use-cases will expand rapidly as a result. Hermes' current architecture does not allow an adequate degree of flexibility for relayer developers to easily enable such use-cases. The Relayer-Next project (you might also hear it referred to as the relayer framework or the relayer library) aims to address this lack of flexibility; it seeks to re-architect Hermes' back end such that the different components that comprise its relaying pipeline can be composed together in a much more functional and modular fashion.

While the hope is that such a re-architected relayer back end will lead to a more performant and maintainable Hermes codebase, such a composable back end will also be open sourced as a library for the benefit of other relayer developers. We hope that such a library will make it much easier to spin up new relayer instances that address currently-nonexistent relaying use-cases.

What functionality does the Relayer-Next library support?

  • Cosmos-Cosmos relaying
  • Telemetry
  • Message batching
  • Solomachine-Solomachine relaying
  • Cosmos-Solomachine relaying

How is the relayer framework implemented?

The relayer framework implementation is centered around three kinds of contexts:

Each context contains the environment and dependencies that are required for operations in that context to work. For instance, the chain context contains parameters for talking to full nodes, while the transaction context contains the wallet credentials necessary for signing transactions.

The relay context is special in that it contains two chain sub-contexts, the source and destination contexts, which correspond with the sending of an IBC packet from a source chain to a destination chain. Compared to the current iteration of the Hermes relayer, the role of the two chain sub-contexts is fixed, i.e., a source chain always remains a source chain. This implies that in order to perform bi-directional relaying of IBC packets between two chains, two relay sub-contexts are needed in order to handle packets in each direction.

In addition to the source and destination chain contexts, the relay context also has two dynamic context parameters: the target chain context, and the counterparty chain context. These denote which chain context the relay context is currently targeting. For example, if the relay context were to send messages to the source chain context, then the target chain context would be the source chain. This helps to differentiate the different kinds of chains the relay context is interacting with, and helps to avoid coding errors caused by mistaking one chain with another.

In Depth Articles