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

feat(l2-withdrawals): Withdrawals storage root verification in execution #14124

Closed
wants to merge 26 commits into from

Conversation

emhane
Copy link
Member

@emhane emhane commented Jan 31, 2025

@emhane emhane added A-execution Related to the Execution and EVM A-consensus Related to the consensus engine A-op-reth Related to Optimism and op-reth labels Jan 31, 2025
@emhane emhane marked this pull request as draft January 31, 2025 13:35
@emhane emhane force-pushed the emhane/exec-verif-storage-root branch from 2485b74 to 3c715de Compare January 31, 2025 17:27
@emhane emhane requested a review from clabby February 1, 2025 00:12
@emhane emhane marked this pull request as ready for review February 1, 2025 00:26
@emhane
Copy link
Member Author

emhane commented Feb 4, 2025

looked into possibility of making this reth-optimism-consensus and reth-optimism-evm wasm compatible, but it is way out of scope of this pr. isthmus requires HashedStorage type from reth-trie as well as StateRootProvider, StateRootProviderFactory and StorageRootProvider. cc @Rjected @shekhirin

Copy link

codspeed-hq bot commented Feb 4, 2025

CodSpeed Performance Report

Merging #14124 will not alter performance

Comparing emhane/exec-verif-storage-root (2acf3f6) with main (29e6e5c)

Summary

✅ 77 untouched benchmarks

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'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

Copy link
Collaborator

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?

Copy link
Member Author

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

Copy link
Member Author

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

Copy link
Member Author

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

Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link
Member Author

Choose a reason for hiding this comment

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

@emhane emhane requested a review from mattsse February 4, 2025 17:56
Comment on lines +274 to +285
// 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)?;
}

Copy link
Member

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

Copy link
Collaborator

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

Copy link
Member Author

Choose a reason for hiding this comment

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

first of all I was implementing it to happen post execution, then @mattsse told me to do it in execution because otherwise we won't be able to verify the storage root in pipeline sync, same as for state root, based on that convo I opened this issue #13537 and closed #13214

Comment on lines 35 to 39
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)
Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link
Member

@klkvr klkvr Feb 5, 2025

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

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()))

Copy link
Member Author

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

Copy link
Member Author

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

/// 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,
}

Copy link
Member Author

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

@emhane
Copy link
Member Author

emhane commented Feb 15, 2025

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

@emhane emhane closed this Feb 15, 2025
@emhane emhane deleted the emhane/exec-verif-storage-root branch February 15, 2025 22:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-consensus Related to the consensus engine A-execution Related to the Execution and EVM A-op-reth Related to Optimism and op-reth
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants