Run a Relayer
Reference relayer implementation for cross-chain Avalanche Interchain Message delivery.
This repository contains off-chain services that help support Avalanche Interchain Messaging (ICM).
Currently implemented applications are
- ICM Relayer
- Full-service cross-chain message delivery application that is configurable to listen to specific source and destination chain pairs and relay messages according to its configured rules.
- Signature Aggregator
- Lightweight API that requests and aggregates signatures from validators for any ICM message, and returns a valid signed message that the user can then self-deliver to the intended destination chain.
Updating dependencies and E2E testing
Applications in this repository depend on the following upstream repositories, both directly in terms of code imports defined in the go.mod
file as well as indirectly for E2E tests where binary versions are used to spin up the test network via tmpnet
:
- avalanchego
- coreth (indirectly)
- subnet-evm
[!NOTE]
We require any commits referenced in our main
branch to be present in the default branches of the repositories above, but during active development it might be useful to work against changes in progress that are still on feature branches.
When developing such features that require updates to one or more of the above, care must be taken to understand where the relevant code comes from. The binaries of applications built in this repo are built against versions referenced in the go.mod
file. The E2E tests run against a simulated network running locally that is started by calling a separately compiled avalanchego
binary as well as its plugins. These are compiled based on the values of AVALANCHEGO_VERSION
in this repository's ./scripts/versions.sh
.
avalanchego
and coreth
have a direct circular dependency and this repository is only indirectly dependent on coreth
but directly dependent on avalanchego
. Therefore if any updates are required from the coreth
side, a corresponding avalanchego
commit referencing those changes is required. On the other hand subnet-evm
just depends directly on avalanchego
.
[!NOTE]
It's possible that a subnet-evm
version is compatible with multiple different avalanchego
versions and not limited to the one listed in subnet-evm
's /scripts/versions.sh
Example dependency update flow
The most complicated example case that can arise above is that a feature depends on a new change in coreth
and all versions are mutually incompatible. The steps below outline the necessary commits:
- If an
avalanchego
commit referencing this change in itsgo.mod
file doesn't exist yet then it needs to be added. - Add a commit in
subnet-evm
that references theavalanchego
commit from above in both itsgo.mod
file as well as itsscripts/versions.sh
file. - Create a new commit in this repository referencing
avalanchego
andsubnet-evm
directly andcoreth
indirectly as well as update references in thescripts/version.sh
file for bothAVALANCHEGO_VERSION
andSUBNET_EVM_VERSION
.
Publishing all of the commits mentioned above to GitHub branches will enable running E2E tests through the CI.
[!TIP]
Running the tests locally doesn't require publishing the subnet-evm
commit since ./scripts/e2e_test.sh
takes a flag specifying a local checkout of the subnet-evm
repository.
Releases
GoReleaser is used to build the binaries of the services and also Docker images with those binaries. The monorepo feature of GoReleaser Pro is used to automate the release flow in response to tags like signature-aggregator/v0.0.0
. The release actions in .github/workflows automate this, but the release build can also be run locally. Be sure to install the "pro" distribution of the command line utility, so that it can parse the monorepo
key. For example:
Then:
Or, for the relayer:
Last updated on