-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
base: main
Are you sure you want to change the base?
Conversation
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 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>>); |
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.
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> { |
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.
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 |
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 believe this is a merge artifact?
Ref #13537
revm::Database
is a subset of theStateProvider
behaviour (EvmStateProvider
). The database passed to execution in reth, implementsStateProvider
, so this PR simply delays the step where the db is limited to therevm::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.