AWM Rust Relayer MVP Scope and Design

[vikinatora]

Hey everyone, LimeChain has an idea about building an alternative relayer that can serve as a fallback to the Go Relayer in the beginning. In case of a implementation bug, having multiple relayer implementations reduces the chance that the message won't be relayed to the target subnet. Below you will find the high-level scope and design for the MVP version. We'd be happy to get some feedback on our idea.

AWM Relayer in Rust Scope

Overview

The goal of this document is to outline the high-level design and scope of an Minimum Viable Product(MVP) Avalanche Warp Messaging Relayer in Rust.

Scope

P2P Network

Consideration is given to using either JSON RPC or direct requests via Protobuf. The latter is favoured due to existing Protobuf types in avalanche-rs, streamlining implementation and obviating the need for defining new types. Additionally, having a network module implemented, it can serve as an example the community can use in order to build their own clients in Rust.

• Relayer is able to establish a P2P connection with other nodes/clients.
• Relayer is able to receive and process networking messages.
• Relayer is able to request signatures via AppRequest messages
• Relayer is able to handle error and common edge cases.
• Contribute functionality to avalanche-rs network module if deemed appropriate.

Message Handling

The message handling module is responsible for managing inbound and outbound cross-chain messages.

• Relayer is able to poll Warp Messages from origin (user-configured) Subnets
• Relayer is able to process and validate Warp Messages
• Relayer is able to deliver messages to target Subnets
• Relayer is able to handle error and common edge cases

Signature Aggregation

Signature aggregation is a sub-process stemming from a newly received inbound message. This process is critical to the security of the AWM protocol.

• Relayer is able to gather validators subsets for a Subnet
• Relayer is able to aggregate signatures into a BLS Multi-Signature
• Relayer is able to construct transaction and call receiveCrossChainMessage function with the message with aggregated signature
• Relayer is able to handle error and common edge cases

Persistence

Relayer is a stateful application, although not data heavy(at least in the MVP version). The persistence layer is to be implemented using a Rust trait, so that in the future DBs can easily be added and swapped for one another.

• On initial startup, the relayer will initialize basic file storage(TOML) that will keep track of the configured chain id’s and their latest processed block.
• In case the relayer stops, it will be able to recover and start from where it left of.
• Relayer is able to handle error and common edge cases

User Configuration

• Users will be able to configure the relay through:
  • A TOML config file (-config-file path-to-config).
  • Additional command line arguments, including an optional -dev option for testnet settings.
  • Default values through #[serde(default)] for log level, network ID, and P-chain API URL.

Future Plans

• Implement distinct functionalities like strict ordering of messages
• Improve existing functionalities to give more customizability and confidence in users
• Extend the functionality with other VMs, VM Warp Payloads, contract-level messaging protocols and others

[martineckardt]

Awesome initiative! Some internal feedback:

@cam-schultz

Everything in this doc is consistent with our Go relayer implementation. I'd advise architecting the Rust implementation to be extensible to other VMs, VM Warp payloads, and contract-level messaging protocols, as subnet-evm + Teleporter is only the start 🙂

Warp is designed to be a minimal messaging interface. Therefore, a warp message only contains minimal fields:

• Network ID: ID of the network (Mainnet, Fuji, local testnet), to prevent replay attacks
• SourceChainID: The BlockchainID (not related to the EVM chainID)
• Payload: bytes

The contents of the Payload can be arbitrary. To encourage standardization, we provide some initial Payload types (namely AddressedCall and Hash). More are to come and anyone can define their own types. Teleporter utilizes the AddressedCall payload type.

You can find more information of the different Warp payloads here:
https://github.com/ava-labs/avalanchego/tree/master/vms/platformvm/warp/payload

[vikinatora]

Thank you for the feedback @martineckardt. I'm adding a diagram that we believe encompasses the high-level architecture of the Relayer.