Skip to content

Conversation

@emhane
Copy link
Member

@emhane emhane commented Oct 10, 2025

  • 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

Copilot AI review requested due to automatic review settings October 10, 2025 08:39
@emhane emhane added the K-debt Kind: debt label Oct 10, 2025
@emhane emhane added the A-db Area: database label Oct 10, 2025
@emhane emhane added the A-exex Area: execution extension label Oct 10, 2025
@emhane emhane added the W-historical-proofs Workstream: historical-proofs label Oct 10, 2025
@wiz-b4c72f16a4
Copy link

wiz-b4c72f16a4 bot commented Oct 10, 2025

Wiz Scan Summary

Scanner Findings
Vulnerability Finding Vulnerabilities -
Data Finding Sensitive Data -
Total -

View scan details in Wiz

To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension.

@emhane emhane changed the title chore(op-exex): Add crate ret-optimism-exex chore(op-exex): Add crate reth-optimism-exex Oct 10, 2025
Copy link

Copilot AI left a 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 ExternalProofExEx to OpProofsExEx in the new optimism exex crate
  • Migrates storage types from reth_exex::external_proofs::storage to reth_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 dhyaniarun1993 linked an issue Oct 10, 2025 that may be closed by this pull request
@emhane
Copy link
Member Author

emhane commented Oct 14, 2025

@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

@emhane emhane requested a review from dhyaniarun1993 October 14, 2025 16:54
@dhyaniarun1993
Copy link
Collaborator

@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

Sure. I will review the PR.

@emhane
Copy link
Member Author

emhane commented Oct 14, 2025

ref commit 8f9b614 @dhyaniarun1993 paradigmxyz#19002

Copy link
Collaborator

@dhyaniarun1993 dhyaniarun1993 left a 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

Let me know what you think @meyer9 @emhane

@emhane
Copy link
Member Author

emhane commented Oct 14, 2025

@mattsse any ideas about these weird failures of unit doc tests and hack check please ?

@emhane
Copy link
Member Author

emhane commented Oct 14, 2025

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.

possibly there is a better place, but let's not block on it for now. the reason I moved it out of reth-optimism-storage is because reth-trie doesn't have no-std support which reth-optimism-storage does, and the tables store reth-trie types.

We probably need to refactor this further. Maybe we can do this in a separate PR since other PRs are waiting for this change

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.

@emhane
Copy link
Member Author

emhane commented Oct 14, 2025

merging to unblock people in IST time zone before I log off 🫡

@emhane emhane merged commit 059d554 into unstable Oct 14, 2025
37 of 41 checks passed
@emhane emhane deleted the emhane/op-exex branch October 14, 2025 18:08
github-merge-queue bot pushed a commit that referenced this pull request Oct 15, 2025
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]>
emhane added a commit that referenced this pull request Oct 20, 2025
…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`
emhane added a commit that referenced this pull request Oct 20, 2025
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]>
meyer9 pushed a commit that referenced this pull request Oct 31, 2025
…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`
meyer9 added a commit that referenced this pull request Oct 31, 2025
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]>
emhane added a commit that referenced this pull request Nov 11, 2025
…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`
emhane added a commit that referenced this pull request Nov 11, 2025
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]>
meyer9 pushed a commit that referenced this pull request Nov 13, 2025
…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`
meyer9 added a commit that referenced this pull request Nov 13, 2025
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]>
emhane added a commit that referenced this pull request Nov 18, 2025
…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`
emhane added a commit that referenced this pull request Nov 18, 2025
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]>
emhane added a commit that referenced this pull request Nov 25, 2025
…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`
emhane added a commit that referenced this pull request Nov 25, 2025
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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-db Area: database A-exex Area: execution extension K-debt Kind: debt W-historical-proofs Workstream: historical-proofs

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Refactor external exex crate

6 participants