-
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
Decode Merkle proofs entirely at once #3013
Merged
Merged
Conversation
This file contains 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
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.
|
This was referenced Nov 18, 2022
Substrate sometimes sends back an empty response to light client requests
paritytech/substrate#12727
Closed
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.
cc #2973
This PR rewrites the code that verifies Merkle proofs. Instead of iterating through the proof while decoding it to find one specific element, we now fully decode and verify the proof then later find the elements from that decoding. This means that we no longer need to verify the proof multiple times.
In terms of API, this means that decoding the proof no longer returns any "entry missing" error. The errors about a missing entry have thus been added at a higher level.
The logic of the code keeps track of all the entries found in the proof. Later, in order to find an element, we actually iterate "upwards". So for example to find
0xf00bab
, we first try0xf00bab
, then for example0xf00b
and then0xf00
. The vast majority of the time there should be a precise hit, so it seems better to me to try to find0xf00bab
first and then iterate upward in order to prove that the requested key doesn't exist or isn't in the proof.I've removed the existing code. Despite the fact that it works, I think it's a strictly worse way of doing it than the code in this PR.
As I've reached the end of this PR and my brain is fried, I realized that using a
BTreeMap
is kind of stupid since the proof is already a tree, and we should instead just keep a parallelVec
adding some information that avoids having to recalculate hashes when decoding the tree. However I don't have the courage to do this anymore and I've just left aTODO
instead. Since this is purely an implementation detail and that the complexity would remain the same, it can be changed later without breaking anything.I also had in mind to immediately add a
next_key
and aprefix_key
function to the proof, but again I don't have the courage to do so now.