Native hooks in the mailbox

[nambrot]

Hooks were conceived to support the use of other verification mechanisms to secure a Hyperlane message. E.g. in #2316, a message can be verified via the native L1-L2 Optimism bridge. However to support that, currently, the message sender has to explicitly do so via a hook contract on the origin chain (that the ISM on the destination chain permissions as the sender via the other verification mechanism).

When discussing the hooks, we thought of pulling the hooks into the Mailbox itself. That would allow message senders to not need to make contract bytecode change to support the change of an ISM on the destination. We started with the prototype outside since it would require no upgrade of the Mailbox.

In addition to supporting more ISMs on the desination for a message, there are other potential applications of native hooks in the mailbox:

• There is a 1-to-1 relationship between a Mailbox and Merkle tree at the moment. However, as we learned in Mailbox: Support VMs without keccak/ecrecover #2258, that relationship should probably be an n-to-m one. I.e. depending on the destination of the message, there may be 0-n merkle trees that are suitable. It seems plausible to move merkle tree enqueueing into a hook that senders can opt out of.
• Relatedly message senders may want different semantics for committing to a message on the origin chain. Again, by default they may want rely on the "merkle-tree-enqueueing" default hook, but for destination chains that do not support the hashing function, it may be required to store the whole message in storage to support slashing
• IGPs potentially can be expressed in a hook. That would allow senders to specify different IGPs without needing to make accommodations in the sending contract. It would allow warp route/router contracts to not need that functionality built-in (and thus could support warp route deployments without a IGP as a required input)

Questions:

• Does the native hook interface look the same to the one that is external?
• How to reconcile that different hooks may need additional/different metadata? (i.e. for IGP payments, would need to pass gasAmount and refund address)

Tasks

Preview Give feedback

No tasks being tracked yet.

[nambrot]

How to reconcile that different hooks may need additional/different metadata?

One option would be to use L0's adapter params https://layerzero.gitbook.io/docs/evm-guides/advanced/relayer-adapter-parameters

Another option would be to try to move anything that can't be deduced into the hook itself (i.e. make the hook very sender-specific)