-
Notifications
You must be signed in to change notification settings - Fork 7
feat: add external state provider implementation #197
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
Conversation
Wiz Scan Summary
To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension. |
0383453 to
1d82611
Compare
5f2e461 to
74d1ac9
Compare
067c64e to
c365ff3
Compare
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.
Pull Request Overview
Implements proof, root, and witness generation abstractions over OpProofsStorage, enabling trie-based state/account/storage proofs, roots, and witnesses sourced from an external (live-sync) storage backend while reusing existing Reth trie logic.
- Adds OpProofs-backed cursor adapters and factories for trie and hashed views
- Adds overlay_* helper trait extensions for Proof, StorageProof, StateRoot, StorageRoot, and TrieWitness to combine external DB data with in-memory post state / cached nodes
- Exposes the new functionality via a new proof module
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| crates/optimism/trie/src/proof.rs | Introduces cursor wrappers, factories, and overlay trait implementations for proofs, roots, and witnesses over external storage. |
| crates/optimism/trie/src/lib.rs | Exposes the new proof module publicly. |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
| Self::from_tx(storage.clone(), block_number) | ||
| .with_trie_cursor_factory(InMemoryTrieCursorFactory::new( | ||
| OpProofsTrieCursorFactory::new(storage.clone(), block_number), | ||
| &nodes_sorted, | ||
| )) | ||
| .with_hashed_cursor_factory(HashedPostStateCursorFactory::new( | ||
| OpProofsHashedAccountCursorFactory::new(storage, block_number), | ||
| &state_sorted, |
Copilot
AI
Oct 14, 2025
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.
storage is cloned twice (lines 248 and 250) before the original is finally moved (line 254); you can reduce redundant cloning by introducing a single let storage_clone = storage.clone(); and reusing it (same pattern appears in overlay_multiproof at lines 270–273 and overlay_witness at lines 560–563).
crates/optimism/trie/src/proof.rs
Outdated
| ), | ||
| address, | ||
| prefix_set, | ||
| // #[cfg(feature = "metrics")] |
Copilot
AI
Oct 14, 2025
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.
Leftover commented attribute (#[cfg(feature = "metrics")]) is dead code; remove it or reintroduce proper conditional compilation to avoid confusion.
| // #[cfg(feature = "metrics")] |
ok, thanks, my bad didn't pay attention to that feature |
Based on #197 This PR implements the live state collector on top of the `OpProofsStateProvider` created in the previous PR. This sync process tries to re-execute all blocks from the current block of the external database to tip. --------- Co-authored-by: Emilia Hane <[email protected]>
Based on #203 , #204 This PR implements `StateProvider` given a `OpProofsStorage` instance. It reads most data from the external database, but falls back on the latest provider for block hashes and code by hash similar to the existing historical provider in Reth. This is an important part to implementing live syncing since we're running the sync process on the DB being created. In the Reth implementation, `proof.rs` is contained in `trie/db`, so I think it makes sense to go in our DB crate. The `provider.rs` is in the `reth-provider` crate, but I don't think a separate provider crate helps us here, so I think we should also include that in the trie crate as well. --------- Co-authored-by: Emilia Hane <[email protected]>
Based on #197 This PR implements the live state collector on top of the `OpProofsStateProvider` created in the previous PR. This sync process tries to re-execute all blocks from the current block of the external database to tip. --------- Co-authored-by: Emilia Hane <[email protected]>
Based on #203 , #204 This PR implements `StateProvider` given a `OpProofsStorage` instance. It reads most data from the external database, but falls back on the latest provider for block hashes and code by hash similar to the existing historical provider in Reth. This is an important part to implementing live syncing since we're running the sync process on the DB being created. In the Reth implementation, `proof.rs` is contained in `trie/db`, so I think it makes sense to go in our DB crate. The `provider.rs` is in the `reth-provider` crate, but I don't think a separate provider crate helps us here, so I think we should also include that in the trie crate as well. --------- Co-authored-by: Emilia Hane <[email protected]>
Based on #197 This PR implements the live state collector on top of the `OpProofsStateProvider` created in the previous PR. This sync process tries to re-execute all blocks from the current block of the external database to tip. --------- Co-authored-by: Emilia Hane <[email protected]>
Based on #203 , #204 This PR implements `StateProvider` given a `OpProofsStorage` instance. It reads most data from the external database, but falls back on the latest provider for block hashes and code by hash similar to the existing historical provider in Reth. This is an important part to implementing live syncing since we're running the sync process on the DB being created. In the Reth implementation, `proof.rs` is contained in `trie/db`, so I think it makes sense to go in our DB crate. The `provider.rs` is in the `reth-provider` crate, but I don't think a separate provider crate helps us here, so I think we should also include that in the trie crate as well. --------- Co-authored-by: Emilia Hane <[email protected]>
Based on #197 This PR implements the live state collector on top of the `OpProofsStateProvider` created in the previous PR. This sync process tries to re-execute all blocks from the current block of the external database to tip. --------- Co-authored-by: Emilia Hane <[email protected]>
Based on #203 , #204 This PR implements `StateProvider` given a `OpProofsStorage` instance. It reads most data from the external database, but falls back on the latest provider for block hashes and code by hash similar to the existing historical provider in Reth. This is an important part to implementing live syncing since we're running the sync process on the DB being created. In the Reth implementation, `proof.rs` is contained in `trie/db`, so I think it makes sense to go in our DB crate. The `provider.rs` is in the `reth-provider` crate, but I don't think a separate provider crate helps us here, so I think we should also include that in the trie crate as well. --------- Co-authored-by: Emilia Hane <[email protected]>
Based on #197 This PR implements the live state collector on top of the `OpProofsStateProvider` created in the previous PR. This sync process tries to re-execute all blocks from the current block of the external database to tip. --------- Co-authored-by: Emilia Hane <[email protected]>
Based on #203 , #204 This PR implements `StateProvider` given a `OpProofsStorage` instance. It reads most data from the external database, but falls back on the latest provider for block hashes and code by hash similar to the existing historical provider in Reth. This is an important part to implementing live syncing since we're running the sync process on the DB being created. In the Reth implementation, `proof.rs` is contained in `trie/db`, so I think it makes sense to go in our DB crate. The `provider.rs` is in the `reth-provider` crate, but I don't think a separate provider crate helps us here, so I think we should also include that in the trie crate as well. --------- Co-authored-by: Emilia Hane <[email protected]>
Based on #197 This PR implements the live state collector on top of the `OpProofsStateProvider` created in the previous PR. This sync process tries to re-execute all blocks from the current block of the external database to tip. --------- Co-authored-by: Emilia Hane <[email protected]>
Based on #203 , #204 This PR implements `StateProvider` given a `OpProofsStorage` instance. It reads most data from the external database, but falls back on the latest provider for block hashes and code by hash similar to the existing historical provider in Reth. This is an important part to implementing live syncing since we're running the sync process on the DB being created. In the Reth implementation, `proof.rs` is contained in `trie/db`, so I think it makes sense to go in our DB crate. The `provider.rs` is in the `reth-provider` crate, but I don't think a separate provider crate helps us here, so I think we should also include that in the trie crate as well. --------- Co-authored-by: Emilia Hane <[email protected]>
Based on #197 This PR implements the live state collector on top of the `OpProofsStateProvider` created in the previous PR. This sync process tries to re-execute all blocks from the current block of the external database to tip. --------- Co-authored-by: Emilia Hane <[email protected]>
Based on #203 , #204
This PR implements
StateProvidergiven aOpProofsStorageinstance. It reads most data from the external database, but falls back on the latest provider for block hashes and code by hash similar to the existing historical provider in Reth.This is an important part to implementing live syncing since we're running the sync process on the DB being created.
In the Reth implementation,
proof.rsis contained intrie/db, so I think it makes sense to go in our DB crate. Theprovider.rsis in thereth-providercrate, but I don't think a separate provider crate helps us here, so I think we should also include that in the trie crate as well.