test(#17): validator checkpoint-signing parity for Midnight-origin - #33
Merged
Conversation
The validator's checkpoint-signing path is chain-agnostic upstream and the Midnight crate already supplies every trait it needs (#14/#15/#33), so #17 is verification, not new wiring. Add a node-free test that drives the full sign path against #15's dispatch fixture plus a committed EVM reference vector (generated by the independent @hyperlane-xyz/utils oracle): asserts local-vs- chain root parity, signing_hash/EIP-191 digest byte-identity with EVM, and that a standard Hyperlane signature recovers to the validator address. Enable the hyperlane-core `ethers` feature in dev-deps only for `SignedType::recover`.
Localises a domain-hash divergence one layer earlier instead of only surfacing through the inner-digest assert. Pure addition.
… messages Two bugs surfaced by running the outbound flow live (a real transferRemote dispatch), which the simulator-based #15/#16 tests had masked: 1. build_provider returned Err("not yet implemented") for Midnight, so the validator's metrics-updater failed to build and any origin=midnight validator exited at startup. Wire the existing MidnightProvider, matching every other chain's arm. 2. decode_dispatched_messages (used by MidnightMerkleTreeHook::fetch_logs_in_range and the dispatch indexer) required exactly 141 bytes. The runtime trims trailing zero bytes from the Bytes<141> leaf, so a real dispatch whose decimal-scaled amount ends in zeros (a 6->18 route scales 10^5 to 10^17, ending in 0x0000 -> 139 bytes on chain) was rejected. Right-pad back to 141, matching the singular decode_dispatched_message. The #15 fixture used an identity scale (non-zero tail), so it never hit this. Adds a regression test for the batch right-pad path.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Implements #17 (validator checkpoint signing for Midnight-origin messages) on the agent side.
Research confirmed the validator's checkpoint-signing pipeline is entirely chain-agnostic upstream, and the Midnight crate already supplies every trait the validator needs (
MidnightMerkleTreeHook#15,MidnightValidatorAnnounce#33,MidnightIndexerClient#14). The validator binary builds and runs withHYP_ORIGINCHAINNAME=midnightunchanged. So #17 is verification + test coverage, not new wiring.What's here
merkle_tree_hook.rs: new node-free testcheckpoint_signing_matches_evm_reference_vector. It decodes feat: igp rpc endpoint #15's dispatch fixture, rebuilds the localIncrementalMerkle, builds the tipCheckpointWithMessageId, and asserts:current_root== the EVM vector's root input (drift guard between fixture and vector),signing_hash()== EVM inner digest andeth_signed_message_hash()== EVM digest (byte-identity => format parity),tests/fixtures/hyperlane-checkpoint-vector.json: committed reference vector (generated in the contracts repo by the independent@hyperlane-xyz/utilsoracle).Cargo.toml: enable hyperlane-coreethersfeature in dev-dependencies only (gatesSignedType::recover).This covers the offline half of the acceptance criteria ("format identical to EVM" + "standard destination verifies the signature"). The live large-host run (real
transferRemote+ spawned Midnight-origin validator) lands in the contracts repo's E2E harness; the full dispatch->relay->destination round trip is #26.Verification:
cargo test -p hyperlane-midnight(58 pass, 3 ignored live),cargo build --release --bin validatorsucceeds.