Hyperlane’s AVS module for EigenLayer
IRemoteChallenger
interface.
IRemoteChallenger
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.
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.
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.