-
Notifications
You must be signed in to change notification settings - Fork 7
chore(op-exex): Add crate reth-optimism-exex and reth-optimism-trie
#204
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. |
ret-optimism-exexreth-optimism-exex
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
This PR adds a new Optimism-specific ExEx crate reth-optimism-exex and reorganizes external proof functionality. It moves the external proof ExEx implementation from the general reth_exex crate to the new Optimism-specific location.
- Moves
ExternalProofExExtoOpProofsExExin the new optimism exex crate - Migrates storage types from
reth_exex::external_proofs::storagetoreth_optimism_storage::proofs - Updates naming conventions to use "OpProofs" prefix for better clarity
Reviewed Changes
Copilot reviewed 6 out of 7 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| crates/optimism/storage/src/proofs.rs | Refactors storage traits and types with OpProofs naming and async-to-impl Future conversion |
| crates/optimism/storage/src/lib.rs | Adds public exports for the new proofs module |
| crates/optimism/storage/Cargo.toml | Adds dependencies for the proofs functionality |
| crates/optimism/exex/src/lib.rs | Implements the renamed OpProofsExEx with simplified constructor |
| crates/optimism/exex/Cargo.toml | Updates package name and dependencies for the new crate |
| Cargo.toml | Updates workspace members and dependencies to include the new crate |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
|
@dhyaniarun1993 random doc test failing, couldn't see any changes to lock file that could possibly trigger this. let's merge anyway and solve separately, could be due to dep interdependency in new crates, and that some feature needs to be enabled for consistency |
dec7df0 to
8f9b614
Compare
Sure. I will review the PR. |
|
ref commit 8f9b614 @dhyaniarun1993 paradigmxyz#19002 |
dhyaniarun1993
left a comment
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.
I am not sure about putting the db definition inside the trie crate since db isn't limited to trie. It also include account and storage state.
We probably need to refactor this further. Maybe we can do this in a separate PR since other PRs are waiting for this change
|
@mattsse any ideas about these weird failures of unit doc tests and hack check please ? |
possibly there is a better place, but let's not block on it for now. the reason I moved it out of
I don't think we should focus on that now. there is also probably changes that the reth guys will want to make to the structure when we're done in process of upstreaming, so I wouldn't try to make it perfect now, cause it will likely change is at least some minor ways anyway. |
|
merging to unblock people in IST time zone before I log off 🫡 |
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]>
…e` (#204) - Adds new crates `reth-optimism-exex` and `reth_optimism_trie` - Moves `reth_exex::external_proofs` -> `reth_optimism_exex` - Moves `reth_exex::external_proofs::storage` -> `reth_optimism_trie`
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]>
…e` (#204) - Adds new crates `reth-optimism-exex` and `reth_optimism_trie` - Moves `reth_exex::external_proofs` -> `reth_optimism_exex` - Moves `reth_exex::external_proofs::storage` -> `reth_optimism_trie`
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]>
…e` (#204) - Adds new crates `reth-optimism-exex` and `reth_optimism_trie` - Moves `reth_exex::external_proofs` -> `reth_optimism_exex` - Moves `reth_exex::external_proofs::storage` -> `reth_optimism_trie`
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]>
…e` (#204) - Adds new crates `reth-optimism-exex` and `reth_optimism_trie` - Moves `reth_exex::external_proofs` -> `reth_optimism_exex` - Moves `reth_exex::external_proofs::storage` -> `reth_optimism_trie`
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]>
…e` (#204) - Adds new crates `reth-optimism-exex` and `reth_optimism_trie` - Moves `reth_exex::external_proofs` -> `reth_optimism_exex` - Moves `reth_exex::external_proofs::storage` -> `reth_optimism_trie`
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]>
…e` (#204) - Adds new crates `reth-optimism-exex` and `reth_optimism_trie` - Moves `reth_exex::external_proofs` -> `reth_optimism_exex` - Moves `reth_exex::external_proofs::storage` -> `reth_optimism_trie`
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]>
reth-optimism-exexandreth_optimism_triereth_exex::external_proofs->reth_optimism_exexreth_exex::external_proofs::storage->reth_optimism_trie