Conversation
… the target width
…t and drop the quadratic index check
…erifying multiproof entry point and tighten the canonical form check `ContainerFields::field_roots` now returns a `BalancedFieldRoots` newtype and `generate_multiproof` accepts only that, so handing a progressive container's `FieldRoots` to the balanced builder no longer compiles; a trybuild case pins the error. The previous commit's docs claimed this but the free function still took any slice. `multiproof::verify_merkle_multiproof` compares the recomputed root against the expected one, mirroring `is_valid_merkle_branch`. `calculate_multi_merkle_root` is documented as the prover side whose `Ok` is not a verdict, since a tampered leaf is never structurally invalid. `check_active_fields` also requires a zero root at every inactive position (`InactiveFieldNotZero`), so the raw API refuses states no container produces. `progressive_container_depth` is read off the gindex so the two can never disagree about which indices fit, and `progressive_container_proof` builds each level's subtree once instead of rebuilding the field's own level. `the_top_level_round_trips` now asserts unconditionally on every target rather than being vacuous on 64 bit hosts; the derived `prove_fields` on a balanced container gets an integration test; the stale spec path points at `ethereum/ssz-specs`; and the unused `ContainerFields` import in the integration tests is used again. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…t BalancedFieldRoots iterate Review of the previous commit found two unresolved doc links in the `multiproof` module doc (the names live inside the module) and a redundant link target on `verify_merkle_multiproof`; rustdoc is now clean for proof.rs. The `ContainerFields` doc said the balanced-over-progressive mistake "is a type error", which is only true of the derived impls: a hand written impl or an explicit `BalancedFieldRoots::new` is a deliberate act. The doc says so now, `new` documents that it cannot validate its input, and `progressive_container_root` documents the 256 field limit the single chunk `active_fields` imposes. `&BalancedFieldRoots` implements `IntoIterator`, which `Deref` alone did not give it. Read only, so it opens no construction path. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
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
2 participants
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.
What this does
Adds merkle proof and multiproof generation over the containers this crate already merkleizes, addressed by generalized index.
Why
Verifying Ethereum consensus proofs inside a Substrate runtime needs proofs against progressive container roots.
progressive_merkle_hasher.rsalready computes those roots here, so this builds on it rather than alongside it.What is in it
get_helper_indicesandcalculate_multi_merkle_root, following the consensus-specsssz/merkle-proofs.mdalgorithmsContainerFields/TreeHashFieldsA test asserts the tree the proof module rebuilds matches what
ProgressiveMerkleHasherstreams, so the two cannot drift apart.On the design
There is no proof API here today, so the shape is a proposal, not a convention. If you want it elsewhere, with a different surface, or split further, say so and it will be reworked. The commits are kept separate to make that easy.
Verification
Against the proposed dependency branches via path patches.
cargo testcargo check --no-default-features --features sha2 --target wasm32-unknown-unknowncargo fmt --checkThe
trybuildtest cannot pass under a path patch, since it spawns its own cargo build that does not inherit the patch and resolvesethereum_hashingfrom crates.io. It should pass once ethereum_hashing#23 releases.