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.
Overview
Adjusts the MPT crate to copy-on-hash rather than hash-in-place when computing the root hash of the trie.
This is less efficient, but is needed for completing execution of Optimistic blocks in the interop proof. Doing this enables for us to not rely solely on the
L2AccountProof
hint for output root computation, which depends on the block the proof is fetched within being canonical.Benchmarks
The slowdown isn't crazy significant, but more
keccak256
operations may not be amazing for users runningkona
on zkVMs. Native wallclock benchmarks don't directly translate to prover cost, but do give a rough indication on the hit (Benchmark: "Compute root, fully open trie - 65,536 nodes"):Asterisc
Interestingly, doesn't really affect
asterisc
cycle count nor wallclock time (but note, we only ran one block, not a range proof):main
(61ed1419
) -~4610000000
cycles.cl/mpt/copy-when-sealing
(37c8dae
) -~4630000000
cycles.If we care about this hit, we can look into adding some additional caching that preserves the full cache of the trie in-memory, but prevents re-hashing nodes whose cache has not been invalidated by a write.
Meta
closes #981