You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, a ledger batch proof is a slice of inclusion proofs, this can be optimized by storing values of the common branches only once. especially for larger batch proofs, the very first few levels of the trie would be the same, another improvement might be that if both children of the same hight is included, both hash values should be computable so we could skip including hash values for those levels.
The text was updated successfully, but these errors were encountered:
We talked about this last time, IIRC, but I can't recall the details you gave about it.
If I understand correctly, the proofs are essentially the list of hashes that go from the root to the paths that we want to prove exists, and so the optimization there is that if in a batch, multiple paths share common parts, we could just include those proofs once, right?
As for the second proposal, I am not sure I understand what you mean by:
If both children of the same height are included, both hash values should be computable so we could skip including hash values for those levels.
Could you please expand on it or explain it in a different way? 🙏
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Currently, a ledger batch proof is a slice of inclusion proofs, this can be optimized by storing values of the common branches only once. especially for larger batch proofs, the very first few levels of the trie would be the same, another improvement might be that if both children of the same hight is included, both hash values should be computable so we could skip including hash values for those levels.
The text was updated successfully, but these errors were encountered: