Hyperlane AVS

This guide will help you understand the Hyperlane’s AVS (Actively Validated Service) module built atop EigenLayer, the Ethereum restaking protocol.

Hyperlane currently employs a Proof of Authority model for security, in which a trusted group of validators is chosen to maintain security. However, if any validator signs erroneously or with malicious intent, there are no repercussions, as these validators have no economic stake. This is the gap that the AVS module is designed to address.

The AVS module uniquely enables economic security within the Hyperlane protocol with minimum cost to bootstrap a new validator network for each chain it supports. This is achieved by leveraging the shared pool of stake that can secure outbound messages from and between rollups. The main stakeholders in this process are:

• Operators - EigenLayer operators who opt into the Hyperlane AVS service and start validating outbound messages from the chain(s) specified
• Stakers - EigenLayer stakers who delegate their stake to the operators to secure the network
• Applications - Applications leveraging Hyperlane seeking to economically secure their messages across chains

​

Architecture

The above class diagram describes the architecture of the current AVS module contracts. Crucially, it describes the “metaAVS” design pattern which we support with the IRemoteChallenger interface.

​

IRemoteChallenger

Operators on Hyperlane have the flexibility to operate on their chosen chain(s), making the AVS module adaptable to any chain or challenger. However, this flexibility may result in the absence of a universally accepted ‘canonical’ source of truth for slashing on the Mainnet. This is due to the fact that fraud can only be proven on the origin chain, and so there needs to be a way to transmit that information to the chain on which the stake lives.

Embracing the ethos of permissionless interoperability, we believe that application developers should have the ability to define their own source of truth and establish guarantees for their application’s economic security. This includes the ability to program challenge conditions and slashing windows.

To enable this level of customization, we have introduced the IRemoteChallenger interface. The handleChallenge function will only be invoked if ism.verify() successfully executes on the L1 originating from the chain where the fraudulent signature was detected. As mentioned above, it’s critical to set up robust security measures for this underlying ISM.

interface IRemoteChallenger {
    /// @notice Returns the number of blocks that must be mined before a challenge can be handled
    /// @return The number of blocks that must be mined before a challenge can be handled
    function challengeDelayBlocks() external view returns (uint256);

    /// @notice Handles a challenge for an operator
    /// @param operator The address of the operator
    function handleChallenge(address operator) external;
}

This configuration should be immutable and accessible for any AVS operator to view and opt into. The handleChallenge function explicitly encodes how you expect the challenge from the source chain (say Arbitrum) is delivered to Ethereum Mainnet where the AVS contracts and the IRemoteChallenger live.

For Arbitrum, it can be the rollup’s native bridge and for another L1, it can be a committee-based solution. Our interface is challenger implementation agnostic to allow for flexibility in this design area. This allows for us to reuse the existing hook-ISMs setup by calling handleChallenge() once ism.verify() is successful on the L1. A reasonable challengeDelayBlocks would be slightly longer than a week in the case of using a rollup’s native bridge.

As an operator, you are expected to review the different IRemoteChallenger contracts and assess their risk and rewards. If interested, you can enroll into one or multiple challengers directly from the HyperlaneServiceManager contract.

​

Workflow for registering

Prerequisite: operator has to be registered as an EigenLayer Operator (through their CLI)

Operators need to enroll into specific challengers to allow for economic security with permissionless slashing. As an operator, you can inspect every remote challenger and choose for yourself which ones you want to opt into depending on risk. This also means there is no centralized permissioning or whitelisting that would be the bottleneck for adding challengers for different rollup stacks. The operators will be able to unenroll after the unenrollment delay blocks has passed.

​

Workflow for deregistering

Operators can only deregister themselves after unenrolling from all challengers they are enrolled in, each of which can have its own delay period. This is to ensure that the operator is not able to withdraw their stake before the challenge period has passed for any of the challengers.

​

Workflow for staking

In EigenLayer’s design, staker funds are safeguarded as they are not made accessible to the AVS until slashing is activated. This ensures that no funds are at risk prematurely. Additionally, this design does not allow users to selectively opt into the Hyperlane AVS alone, as staking is managed through the StrategyManager and directed towards a specific operator.

​

Workflow for slashing

The slashing mechanism is designed to be permissionless and flexible. The IRemoteChallenger interface allows for different implementations of the slashing mechanism. As an example, the postChallenge function is called by the native challenger on the origin chain, which then calls the handleChallenge function on the HyperlaneServiceManager contract. The HyperlaneServiceManager contract then checks if the operator is enrolled in the challenger and calls the freezeOperator function on the Slasher contract to freeze the operator’s stake.

​

Contract deployment

​

Ethereum

​

Holesky