feat: Add support for verification of aggregated BLS signatures#2
feat: Add support for verification of aggregated BLS signatures#2MalteHerrmann wants to merge 3 commits intonoble-assets:mainfrom
Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing touches🧪 Generate unit tests (beta)
Tip Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
keyleu
left a comment
keyleu
left a comment
There was a problem hiding this comment.
preliminary input! Looks promising!
| /// @notice The canonical interface for a Hyperlane Interchain Security Module, which verifies | ||
| /// incoming messages based on a provided BLS12-381 signature from Noble's validator set, and | ||
| /// a provided SP1 proof for the inclusion of a given message in the Hyperlane Merkle Tree. | ||
| interface INobleISM is IInterchainSecurityModule, IVersioned, IVkUpdatable { |
There was a problem hiding this comment.
I recently added a new interface to unify some of the core logic that doesn't require duplicating some of the things. We can make it inherit IEvmISM and then this interface is much smaller
| import { IVersioned } from "./IVersioned.sol"; | ||
| import { IVkUpdatable } from "./IVkUpdatable.sol"; | ||
|
|
||
| interface INobleLightClient is IVersioned, IVkUpdatable { |
There was a problem hiding this comment.
Same as above, we can make this one inherit IEvmLightClient
There was a problem hiding this comment.
This contract is not needed. We can reuse EvmISM, which is the one that will store the hyperlane merkle roots validating against the state roots that we have in the noble light client
| // TODO: make pausable? | ||
| contract NobleLightClient is INobleLightClient, OwnableUpgradeable, UUPSUpgradeable { |
There was a problem hiding this comment.
Yeah, let's make it pausable like the other one. The idea of being able to pause is if there is an exploit in the zkVM and we need to pause all proof verifications / updates until we can update the VK
|
|
||
| /// @notice The latest block number that was verified. | ||
| uint64 latestBlockNumber = 0; | ||
|
|
There was a problem hiding this comment.
| uint256 public latestBlockNumber; |
| sketch = sketch.with_genesis(Genesis::Sepolia); | ||
| SEPOLIA_MERKLE_HOOK_CONTRACT | ||
| } | ||
| NOBLE_DEVNET_CHAIN_ID => NOBLE_DEVNET_MERKLE_HOOK_CONTRACT, |
There was a problem hiding this comment.
here we'd also need to use the chain config for Noble
|
|
||
| // Generate proof | ||
| println!("Generating proof..."); | ||
| debug!("Generating proof..."); |
There was a problem hiding this comment.
| debug!("Generating proof..."); | |
| info!("Generating proof..."); |
|
|
||
| // Verify proof | ||
| println!("Verifying proof..."); | ||
| debug!("verifying proof..."); |
There was a problem hiding this comment.
| debug!("verifying proof..."); | |
| info!("Verifying proof..."); |
| message NobleHyperlaneRootResponse { | ||
| // The Hyperlane Merkle Tree root. | ||
| bytes hyperlane_root = 1; |
There was a problem hiding this comment.
we'd need to return the same as for the EthereumHyperlaneRootResponse, the 2 proofs and the 2 public inputs
| tracing-subscriber = { workspace = true, features = ["env-filter", "json"] } | ||
| dotenvy = { workspace = true } | ||
| sp1-sdk = { workspace = true } | ||
| sp1-cc-client-executor = { workspace = true } |
2 participants
This PR adds the implementation to verify aggregated BLS signatures from the validator set on the Noble EVM, based on @keyleu's original approach and @johnletey's PoC for signature verification.
It's still work-in-progress and the PR is only opened to gather early feedback while I'm out of office 🙏