Teleporter Anycasting

[michaelkaplan13]

What is anycasting?

Currently, TeleporterMessenger supports point-to-point messaging. Message senders specify which contract on which blockchain that they want to be called. Many applications though may not care about what the destination of a message is, they could just publish values to be consumed by any contract/chain that wants them. This is a form of "anycasting" where the sender does not care who the receiver of a message is, or if the message is delivered at all.

One possible use case for anycasting is publishing price feed values from one chain to any other chain that wants to consume them. When a new subnet launches, it likely will not have direct price feed integrations on it, but it can easily consume price feeds from other chains that do have such integrations (i.e. the C-chain) using AWM.

How could anycasting be implemented?

The AddressedCall Warp message format defined in AvalancheGo is already generic enough to support this type of use case because it only includes information about the sender of the message, and does not include any information about the intended destination.

The publishing of anycast messages could be done through an interface along the lines of:

function sendAnycastMessage(data memory bytes);

The implementation of this function would call assign a unique ID to the message, and then submit it to the Warp precompile by calling sendWarpMessage.

An AWM relayer instance should be configured to listen for such messages being sent from specific source chains and addresses, and to know where and how to deliver the messages when it hears of them. To make the delivery of anycast messages uniform across chains and contracts, there can be an IAnycastReceiver interface similar to ITeleporterReceiver that should be implemented by any contracts looking to receive these messages.

Some receiving applications may have different requirements for message ordering. For instance, when receiving a price feed value you may only want whatever is the latest value, ignoring any stale values delivered. It's also possible applications would want strict ordering of all messages received, or want to be able to receive any messages that were ever sent and not care about ordering at all (an archive of sorts). Using the message ID assigned by the sender, it shouldn't be difficult to implement AnycastLastestReceiver, AnycastOrderedReceiver, and AnycastArchiveReceiver to meet each of these possible use cases.

Open Questions

• Should the anycast sending and receiving contracts have standalone instances that applications are able to call (similar to the design of TeleporterMessenger, or should there be parent contract implementations that applications can inherit from to send and receive anycast messages?
• If necessary, how would incentives work for anycasting?
  • Incentives for anycasting would need to be provided by the receivers, rather than by the senders as is the case with TeleporterMessenger.
  • A contract looking to subscribe to receive certain anycast updates could directly provide a reward mechanism for anyone that delivers qualifying messages. This would incentivize both the sending of the message on the source chain, and delivery of the message on the specific destination.

[minghinmatthewlam]

An AWM relayer instance should be configured to listen for such messages being sent from specific source chains and addresses

A call out here that the publishers of the anycast data might not have any additional incentive to call sendAnyCastMessage, so it might end up being the relayer who calls that function.

Additional open questions:

• Will we need a standardized message format? A simple example would just contain message id, that can act as nonce, check for ordering, latest, etc.

struct AnycastMessage{
  uint256 messageID;
  bytes message;

• How can relayers be sure that the receiving app will deliver the promised rewards? There should be a uniform interface the receiving app implements so that the relayers don't need to audit each app to make sure they'll get their rewards. The relayer just needs to deliver the message passing the qualifications to get the associated rewards, the rest in terms of message execution is the dapp's responsibility.

[geoff-vball]

Idea: A pub/sub registry, one (or more) on each chain, where a contract can register to receive messages from a particular address/blockchainID combo. The contract can specify a reward, max frequency, etc.

First let's think about what a rudimentary anycast with just send/receive methods on the contracts with no pub/sub would look like. I think the only param the receive method needs is the messageIndex, which we use to call getVerifiedWarpMessage() on the warp precompile, which gives back sourceChainID, originSenderAddress, payload.

Now imagine we implement the pub/sub registry. The pubsub registry's receive method will need messageIndex and destinationAddress, it calls getVerifiedWarpMessage() to make sure the relayer has given it a legitimate warp message, and probably needs to unwrap some sort of nonce in the payload to guarantee this message is newer than the last. Once everything is verified, instead of passing the WarpMessage, because then the consuming contract would need to trust the registry, we actually call the SAME receive method as originally implemented, which only takes messageIndex. Now the consuming contract needs to call getVerifiedWarpMessage() again, which is inefficient, but we've kept the same message interface and don't actually need to trust the pub/sub registry at all, it is purely an incentivization layer.