Standard cross-chain gateways and Axelar adapters

[ernestognw]

Description

From our discussions with the Axelar team, we created an initial MVP that we can start discussing here.
The MVP currently has 2 operational modes: in 1 or 2 steps. We still need to iterate to make sure the properties we discussed are met:

Properties

• Safety
  • Validity:
    • A message may only be executed if it was first scheduled for execution
    • Messages may be executed in a different order than they were scheduled
    • It is possible to send messages with identical content multiple times, each a different message
  • Identification:
    • A message must be uniquely identifiable
  • Non-replayability:
    • A message may only be executed on the intended target
    • A message may not be (successfully) executed more than once
• Liveness
  • A message is eventually delivered
    • Tolerates variable gas price at destination
    • Inherits the weakest liveness property of transactions at the source or destination
    • Any number of additional actions may be required in order for the scheduled message to be executed
  • Executability:
    • A Message should be executed only on the intended target
• Observability
  • Scheduling / Execution tracking
    • A standard event should be emitted on the origin chain when a message is scheduled
    • A standard event should be emitted on the target chain when a message is executed
  • Sender notification (not in scope, not desired)
    • The sender may be notified that the message was successfully executed

Message structure

• bytes/string destChain: CAIP-2 identifier, encoding TBD
• bytes/string destAddress: CAIP-10 address (without chain id), encoding TBD
• bytes payload: "calldata"
• bytes params: protocol- & chain-specific metadata that affect message semantics (there could be none)
  • minGasLimit in optimism (but not other gas-payment-related parameters)
  • value or tokens attached to the message

[frangio]

The main takeaway for me is that we should not be focusing on the generic implementation at the moment, we should instead focus on creating an Axelar adapter gateway, and the same for other protocols, as a way to validate the interfaces are generic enough so that we can standardize them.

[ernestognw]

Merging to get the commit hash for the upcoming audit