Customizable Message Relay Decision

[cam-schultz]

Background

The relayer currently decides whether or not to relay a Warp message based purely on correctness. For example, for Teleporter messages, it will not relay the message if it is not an allowed relayer or if the message has already been delivered. That may be sufficient for managed relayers whose costs are subsidized by the operator, in which case the value the relayer brings to the system is measured by the value that Warp connectivity brings to the connected Subnets. This is generally difficult to quantify.

Warp messages do not inherently provide an incentive for a relayer to pay the cost of delivering them to another blockchain. Teleporter addresses this by supporting fee incentives that are redeemable by the address that delivered the Teleporter message to the destination blockchain. This feature opens up the possibility for a "relayer marketplace" in which individual relayers indpendently decide which messages to relay according to their own profit/loss criteria. In addition to the connectivity incentive mentioned above, relayers would also have a direct economic incentive to not only deliver messages, but be the first to do so in order to claim the reward.

These incentive-based decisions are much more open ended than correctness-based decisions. It would be intractable to attempt to support a wide variety of such decisions via the configuration file alone. Instead, we should consider an architecture that allows for custom relayer decisions to be easily implemented and integrated into the application.

Current Architecture

In the current architecture, message decision logic is encapsulated in MessageManager.ShouldSendMessage. Any extension of this function requires changes to source. This custom code may be too specific to merge to the main branch of this repository,
or in a competitive landscape, it may be sensitive. The most sensible approach would be to fork this repository, increasing the maintanence burden and fragmenting development activity.

Proposed changes

Instead, a "plug and play" architecture is proposed in which the relayer communicates with a sidecar process over a standardized interface implemented in something like gRPC. A composable architecture would reduce the need to fork awm-relayer and allow for greater flexibility in how the decision logic is implemented. Relayer operators could focus on their unique requirements instead of needing to understand and maintain the other components of the application.