Skip to content
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

chore(sync): Delay shrinking db abstraction to revm::Database in execution #13538

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

emhane
Copy link
Member

@emhane emhane commented Dec 24, 2024

Ref #13537

revm::Database is a subset of the StateProvider behaviour (EvmStateProvider). The database passed to execution in reth, implements StateProvider, so this PR simply delays the step where the db is limited to the revm::Database subset of behaviour. This way we can now compute the state root (and storage root (OP)) in execution directly, which means we can verify the corresponding values in the block header against the correct state also in batch execution.

@emhane emhane added A-staged-sync Related to staged sync (pipelines and stages) C-debt Refactor of code section that is hard to understand or maintain A-execution Related to the Execution and EVM C-security Issue or pull request related to security. labels Dec 24, 2024
Copy link
Collaborator

@mattsse mattsse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a pretty good change, offloading all the revm::Db stuff to the actual executor and instead provide the State, the fn get_state(State<) getters a re bit horrible but we had to add those, but I assume we could simplify these a bit later.

very supportive here

@@ -60,7 +60,7 @@ pub trait Executor<DB> {
state: F,
) -> Result<Self::Output, Self::Error>
where
F: FnMut(&State<DB>);
F: FnMut(&State<StateProviderDatabase<DB>>);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what I wanted to do for this for a while now is introduce a trait for State, which would make this a lot more ergonomic. so for now I'm fine with that

@@ -152,6 +166,221 @@ impl<DB: DatabaseRef> Database for CachedReadsDbMut<'_, DB> {
}
}

impl<DB: AccountReader> AccountReader for CachedReadsDbMut<'_, DB> {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need these?

ah we need these to satisfy the stateprovider trait?

but why do we need this traits now?

@@ -164,6 +164,7 @@ where

let EvmEnv { cfg_env_with_handler_cfg, block_env } =
self.eth_api().evm_config().cfg_and_block_env(block.header());
// Note: we assume the block has a valid height
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this is a merge artifact?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-execution Related to the Execution and EVM A-staged-sync Related to staged sync (pipelines and stages) C-debt Refactor of code section that is hard to understand or maintain C-security Issue or pull request related to security.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants