Epic: road to AVS mainnet #3799
Comments
github-merge-queue bot
pushed a commit
that referenced
this issue
Aug 12, 2024
### Description Implements 4 categories of checkpoint fraud proofs for use in future validator slashing protocol: 1. **premature**: if a checkpoint index is greater than the corresponding mailbox count, it is fraudulent 2. **non local**: if a checkpoint origin does not match the checkpoint's mailbox domain, it is fraudulent 3. **message id**: if a checkpoint message ID differs from the actual message ID (verified by merkle proof) at the checkpoint index, it is fraudulent 4. **root**: if a checkpoint root differs from the actual root (verified by merkle proof + root reconstruction) at the checkpoint index, it is fraudulent Notably this is implemented independently from signature verification to allow for multiple checkpoint signing schemes to reuse the same checkpoint logic. ### Related issues - Touches #3799 - See #2431 for previous discussions ### Backward compatibility Yes ### Testing Unit testing with fixtures in `vectors/merkle.json` that are generated by the rust merkle tree and proof code
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is the successor to #3588. Given that Hyperlane AVS is live on testnet and operators are now able to register/deregister from the AVS, there are additional steps required for mainnet use. Some of these are concrete sprint tickets and some of them are more open-ended discussion topics.
Challengers
Fraud proofs will be mainly for:
Once the challenge is successful on the origin chain (not L1), we need to dispatch it to ethereum via the deployer's preferred method, ie, native bridge in the case of rollups. The
IRemoteChallengerimplementation will be access controlled by the L2 challenger address.Given that a single deployer like AW may want to run several origin chains, it is cumbersome for an operator to signup for multiple chains for multiple deployers which means if a deployer is running validators for n chains and there are upto m deployers you want to support, you'll need to enroll into mxn challengers. Maybe there's a preferred challenger pairwise contracts which most deployers may end up using?
For mainnet, it'll be useful to deploy an example challenger (say, for Arbitrum outbound messages) even though slashing wouldn't be live for a while. Ideally, the challenger can be reused for native staking too.
Key custody solutions
Eigenlayer CLI currently only supports local keystores. But, operators may want remote signers with better security patterns, like Fireblocks, Web3Signer, etc., or Cubist, which is a more custom build solution for AVS operators.
Tasks
The text was updated successfully, but these errors were encountered: