Integrating Warp Payload Types into AvalancheGo for Cross-VM Compatibility

[aaronbuchwald]

Subnet-EVM has defined two payload types for exchanging Avalanche Warp Messages, which were developed targeting the EVM: https://github.com/ava-labs/subnet-evm/tree/v0.5.6/warp/payload that I'd propose we migrate into AvalancheGo as a standard and so that they can be imported more easily instead of requiring Coreth or Subnet-EVM as an extra dependency.

The current payload types are a BlockHashPayload which includes only a BlockHash that is considered accepted by the source chain that signed the Avalanche Warp Message.

The second payload type is an AddressedPayload, which was designed to enable a verifiable address-to-address call across different chains. The AddressedPayload type includes a sourceChain, sourceAddress, destinationChain, destinationAddress, and an arbitrary byte array payload.

The sourceChain and destinationChain are the 32 byte blockchainIDs of the source and destination chains, which are the txID of the transactions that created those blockchains on the P-Chain, so they are not specific to Subnet-EVM.

The payload is an arbitrary byte payload, which is not EVM specific (although it will initially be used to transmit ABI encoded function arguments).

The sourceAddress and destinationAddress fields contain 20 byte addresses, which is the only EVM specific choice. Addresses in the EVM are 20 bytes, whereas other VMs may not use 20 byte addresses

If we are going to move this into AvalancheGo, then I'd propose switching from using a 20 byte address to a variable length address, so that it is compatible with VMs using a different address length.

[aaronbuchwald]

Given that Teleporter (https://github.com/ava-labs/teleporter) is using Nick's method to deploy and ensure that it is always talking to another instance of Teleporter on a different chain by checking the sourceAddress matches its own address, we could also move more of the payload out of the warp defined addressed payload.

For example, we could remove the destinationAddress and destinationChainID and include only the sourceChainID and sourceAddress and leave it to the Teleporter contract or anything built on top to define those fields if they are needed.

curious what you think about moving this out of Warp @michaelkaplan13

[michaelkaplan13]

Yeah, I agree that it's not necessary for the AddressedPayload to have either destinationChainID or destinationAddress.

This will make it fit more naturally for a wider range of use cases, such as anycasting. When publishing a value from one chain to be consumed by anyone, the sender doesn't know the intended destination chain or address.

This would also make this subnet-evm issue a moot point I believe. The only downside I can think of is that it may be providing fewer guard rails to dApp developers, which that issue was primarily focused on doing, but ultimately, dApps always need to verify the origin of a message when it is being received in order to know that it is legitimate, and they won't be able to misuse the destinationChainID in the warp message if it's not there at all.

[michaelkaplan13]

For the BlockHashPayload, if moving it into AvalancheGo (which I think makes sense), I would recommend renaming it simply HashPayload since it could be used to transmit hashes of values other than block headers, as @patrick-ogrady originally called out.