3

I have seen primitives around Merkle Trees and Merkle Proofs a bit everywhere across the Substrate, Polkadot, and Smoldot repos. I was wondering what the right choice would be for the following use case:

At the end of each block, read from a storage map in a pallet a series of values, and for each of them generate a fresh Merkle Root (no information on previous roots is stored anywhere) and deposit an event with the value identifier and the new Merkle Root. What about verifying this proof with access only to the Merkle root, the proof itself, and the revealed leaves?

So far, I've found in the sp_trie::{generate_trie_proof, verify_trie_proof} the best candidate, but I have seen Merkle stuff also in the beefy pallet, the mmr-pallet does something similar, and Smoldot has also support for Merkle proof generation and verification.

Improve this question

1 Answer 1

Reset to default
3

Rather than using a storage map, you should use a child trie, which automatically tracks the storage root of the data inside of it.

The DevEx around child tries are not really developed yet, but it should be perfectly usable via the raw APIs.

You can see an example in the Crowdloan pallet: https://github.com/paritytech/polkadot/blob/master/runtime/common/src/crowdloan/mod.rs#L684

Full API docs here: https://crates.parity.io/frame_support/storage/child/index.html

Improve this answer
2
  • The pallet is already used in production and the elements under consideration are already part of a quite large storage map. What's an alternative to using child tries?
    – Antonio Antonino
    Commented Jan 9, 2023 at 7:55
  • I don't know of another option. You can always migrate the data to the child trie using some custom functions or upgrade.
    – Shawn Tabrizi ♦
    Commented Jan 9, 2023 at 12:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.