-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
feat(l2-withdrawals): Withdrawals storage root verification in execution #14124
Conversation
2485b74
to
3c715de
Compare
looked into possibility of making this |
CodSpeed Performance ReportMerging #14124 will not alter performanceComparing Summary
|
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'd like to get all of the consensus related functions in separately.
I'm no longer sure about the StateProvider vs Database changes, which will clash with the new revm wip.
I do like that these now operate just on StateProvider which gives the user more flexibility, but want to hear what @klkvr thinks
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.
could we submit all of these separately?
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.
hm, I don't see the need for this hassle, since the feature is already tested in kurtosis, and we're starting to run out of time to upstream
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.
isthmus code cut is Monday, meaning we have 3 days left
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.
deadline has been extended to wait in op-reth. will open a separate pr for consensus functions and change the function args to be as generic as possible since it isn't clear if the verification should be done in execution or post-execution at this point
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.
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.
// isthmus verification | ||
if self.chain_spec.is_isthmus_active_at_timestamp(block.timestamp) { | ||
let state_updates = mem::take(&mut evm.db_mut().bundle_state); | ||
drop(evm); | ||
isthmus::verify_withdrawals_storage_root( | ||
&state_updates, | ||
&*self.state.database, | ||
block.header(), | ||
) | ||
.map_err(OpBlockExecutionError::Consensus)?; | ||
} | ||
|
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.
we can't do this in executor because storage root verification requires StorageHashingStage which is happening only after execution
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.
right, forgot about this, this won't work in backfill sync because storage hashing comes after.
this is similar to state root which we also don't check during execution.
the only way we can do this is with a new stage that checks this or we only do this in live sync because we only trigger backfill towards a finalized range
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.
let hashed_storage = HashedStorage::from_plain_storage( | ||
account.status, | ||
account.storage.iter().map(|(slot, value)| (slot, &value.present_value)), | ||
); | ||
storage_root_prehashed(hashed_storage.storage) |
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 hashing is done here @klkvr re: https://github.com/paradigmxyz/reth/pull/14124/files#r1941840549
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 mean is that we need values from tables::HashedStorages
here. this table will be empty until StorageHashingStage runs
reth/crates/trie/trie/src/trie.rs
Lines 400 to 405 in 08285c9
let mut hashed_storage_cursor = | |
self.hashed_cursor_factory.hashed_storage_cursor(self.hashed_address)?; | |
// short circuit on empty storage | |
if hashed_storage_cursor.is_storage_empty()? { | |
return Ok((EMPTY_ROOT_HASH, 0, StorageTrieUpdates::deleted())) |
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.
ah you mean in pipeline sync specifically it's a problem
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.
does this mean we are ok with adding a field with to the type ExecuteOutput
for the state updates in order to verify l2 withdrawals root after execution and only for live sync? this is what I was working on initially, so just want to make sure the change to accommodate for OP in shared reth code is tolerated
reth/crates/evm/src/execute.rs
Lines 167 to 174 in b955551
/// Helper type for the output of executing a block. | |
#[derive(Debug, Clone)] | |
pub struct ExecuteOutput<R = Receipt> { | |
/// Receipts obtained after executing a block. | |
pub receipts: Vec<R>, | |
/// Cumulative gas used in the block execution. | |
pub gas_used: u64, | |
} |
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.
alt we can just hash the storage for that account in pipeline sync and pass a custom db wrapper type to execution which stores the storage hashed only for account at 0x42..16
in a separate field
closing since established that storage root verif cannot be done for pipeline sync anyhow this way because storage hashing happens after execution stage in pipeline. new approach, verify storage root post execution, pre-req: #14464 |
Ref ethereum-optimism#19, https://github.com/ethereum-optimism/op-reth/actions/runs/13064293936
Ref #14175