Hyperlane Hooks

Calling all interoperability enthusiasts! Are you tired of one-size-fits-all security for your cross-chain adventures? Buckle up, because Hyperlane Hooks are here to unleash your developer superpowers and tailor your bridge-hopping experience like never before.

Hyperlane V3: Ditch the security monolith and embrace modularity. Think of Interchain Security Modules (ISMs) as your security Swiss Army knives, each offering unique protection. But what if you need a scalpel-level precision for specific transactions? Enter Hyperlane Hooks.

Hooks are your secret weapon: They let you bypass the default settings and fine-tune your interactions with different chains. Choose your transport layer, optimize gas fees, and even activate specific ISMs based on your needs. Think of it like choosing the best route on a road trip – fast and light for basic errands, secure and cautious for hauling precious cargo.

Beyond the ISMs:

Hyperlane V3's Interchain Security Modules (ISMs) provide a robust security foundation. However, Hooks takes things further. They let you customize your security posture for each transaction, based on factors like:

• Transaction value: Tighten security for high-value assets with dedicated ISMs.

• Target chain: Adapt security based on the destination chain's risk profile.

• Urgency: Choose faster, less secure options for time-sensitive transactions.

Developers are advised to prioritize the most effective security measures for their applications, recognizing that a uniform solution may not be suitable for every scenario. In some cases, it may be appropriate to employ security modules developed and maintained by the core team at Hyperlane. On the other hand, developers might opt to create their security solutions, as exemplified by the implementation of fraud proofs for a canonical rollup bridge.

There are also existing message bridges available that can enhance security. In these instances, the Hyperlane message is transmitted over a message bridge to its equivalent Interoperability Security Module (ISM), utilizing the bridge to bolster the security of the message. ISMs play a pivotal role in realizing this vision and operate on the destination chain.

However, a significant challenge was identified on the origin chain, where a message sender still needed to explicitly invoke an external bridge, be it the Arbitrary Message Bridge (AMB) or a canonical bridge. This step was deemed unnecessary, prompting the need for a more streamlined solution.

Hooks as a Solution:

In the context of V3, Hooks enable the routing through alternative dispatch mechanisms seamlessly within the Hyperlane Mailbox interface, eliminating the necessity for a bridge-specific implementation. The key takeaway is the ability to employ distinct hooks for various chains, accommodating different preferences. Although it's technically feasible to send messages through individual transport layers, Hyperlane offers the unique advantage of centralized customization for message routing across different chains within a single interface.

Hooks enable the dispatch of messages through various native or canonical bridges, as well as external bridge providers. Before delving into examples, it's essential to understand the fundamental interaction of Hooks with ISMs (Inter-System Messaging). This involves the presence of an IPostDispatchHook on the origin chain and a corresponding HookISM on the destination chain.

The IPostDispatchHook offers the postDispatch method, which, when passed to the Mailbox, is automatically called after dispatch. This facilitates the transportation of the message across a specific transport layer or bridge to the HookISM. The ISM plays a role in authenticating the msg.sender and storing the messageId. As a result, the message becomes ready for successful delivery by the relayer via the Hyperlane Mailbox.

In every instance of implementing Hooks, all other components remain unaltered, with only adjustments made to IPostDispatchHook and HookISM. Additionally, modifications are made to the External Provider Source and Destination to align with the protocol being utilized by the specific Hook.

Lets us take into considerations where Hooks are changing the interoperability realm:

External Message Bridges

Suppose the intention is to employ an external bridge rather than solely relying on the rollups' current bridge. Hyperlane supports the utilization of all interoperability protocols compatible with ERC-5164 for this purpose.

Interchain Gas Payments

Within the Hyperlane stack, the InterchainGasPayMaster is responsible for managing gas payments to relayers engaged in transporting and processing user transactions. The introduction of Hooks streamlines Interchain Gas Payment (IGP) interactions, effectively reducing both the complexity of the gas payment process and the corresponding code by fifty percent.

Looking at the implementation example:

Before Hooks:

uint256 gasAmount = ...;
IInterchainGasPaymaster igp = ...;
IMessageHook hook = ...;

uint256 quote = igp.quoteGasPayment(destination, gasAmount);
bytes32 messageId = mailbox.dispatch(destination, recipient, body);
igp.payForGas{value: quote}(messageId, destination, gasAmount, msg.sender);
hook.postDispatch(destination, messageId);

We had to lookup for gas amount , and the IGP contract, and the hook for destination.

The old interface would not let the hook.postDispatch() to work.

After Hooks:

uint256 quote = mailbox.quoteDispatch(destination, recipient, body);
mailbox.dispatch{value: quote}(destination, recipient, body);

By default, the Hook is configured to cover the cost of 200,000 units of gas, enhancing the convenience for developers when sending messages, particularly during the initial stages. For a more detailed control over the process, developers have the option to override the gasAmount using metadata.

In order to format the metadata you can use the StandardHookMetadata :

bytes memory metadata = StandardHookMetadata.formatMetadata(
    1, // msg.value
    uint256(300000), // gas limit
    msg.sender, // refund address,
    bytes("")
);

Native Rollup Bridges:

Utilizing Hooks for Native Rollup Bridges represents a direct and uncomplicated application, making use of the rollups' internal bridge for transmitting messages between L1 and L2, or vice versa.

An example is demonstrated with the OpStackHook designed specifically for OpStack chains. In this scenario, the OpStackHook seamlessly integrates as the IPostDispatchHook, and the OpStackISM serves as the corresponding HookISM.

Simultaneously, the L1CrossDomainMessenger and L2CrossDomainMessenger serve as External Providers on the OpStack chain.

Example usage for this hook is given below:

bytes32 messageId = mailbox.dispatch(opStackDomain, recipient, payload, bytes(""), opStackHook);

This will retrieve the message ID to dispatch using the opstackHook .

Conclusion:

In conclusion, Hyperlane hooks empower developers to go beyond default settings and tailor their interactions with diverse chains. These hooks offer the flexibility to select a preferred transport layer, optimize gas fees, and activate specific ISMs based on unique requirements. Analogous to choosing the optimal route for a road trip—swift and efficient for routine tasks or secure and cautious for transporting valuable cargo—Hyperlane hooks provide a versatile toolkit for developers navigating the complexities of cross-chain interactions. With the various implementations explored in this blog, developers can now navigate the Hyperlane ecosystem with precision and customization, ensuring a seamless and efficient cross-chain experience.