-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement compact trie proofs #1166
base: main
Are you sure you want to change the base?
Conversation
Oops, I must also verify that hashes match, otherwise it's completely unsecure. |
We can still find inline nodes and hashes in the proof. Hashes can only be found for nodes that aren't interesting for what we want to prove. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Automatically approving tomaka's pull requests
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Automatically approving tomaka's pull requests. This auto-approval will be removed once more maintainers are active.
twiggy diff reportDifference in .wasm size before and after this pull request.
|
Necessary in order to finish #1166 Right now we can decode items from Merkle proofs. This PR implements encoding back these items. While implementing encoding, I've discovered several cases where the decoding was too lenient and was accepting as valid things that shouldn't really be valid. I've fixed this as part of this PR. See the changes in `src/util.rs` and at the bottom of `src/trie/proof_node_codec.rs`. When I say "shouldn't really be valid" I mean that there were multiple different sequences of bytes that could lead to the same decoded struct. Since we're hashing things a lot here and there, it is important that there is a bijection of decoded <-> encoded. The Substrate implementation does the same. cc paritytech/substrate#12417
Fix #910
PR is ready, but two questions remain to be solved before merging: