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

evm: wider use of RethEvmBuilder #9944

Merged
merged 15 commits into from
Aug 22, 2024

Conversation

tcoratger
Copy link
Contributor

Follow up of #9813

Wider use of RethEvmBuilder in the code.

Another follow up will aim to use RethEvmBuilder in the examples as well with the possibility to add precompiles directly.

crates/evm/Cargo.toml Outdated Show resolved Hide resolved
Comment on lines 121 to 130
fn evm_with_env<DB: Database>(
&self,
db: DB,
env: EnvWithHandlerCfg,
) -> Evm<'_, Self::DefaultExternalContext<'_>, DB> {
let mut evm = self.evm(db);
evm.modify_spec_id(env.spec_id());
evm.context.evm.env = env.env;
evm
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

remind me, why do we need to impl this trait function now?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because in the old version, evm_with_env took as first line the result of self.evm() with a .optimism() component inside for the Optimism case.

But since now we use our RethEvmBuilder, we can no longer count on the same methodology, the implementation of evm_with_env being:

/// Returns a new EVM with the given database configured with the given environment settings,
/// including the spec id.
/// /// This will preserve any handler modifications fn evm_with_env<DB: Database>( &self, db: DB, env: EnvWithHandlerCfg, ) -> Evm<'_, Self::DefaultExternalContext<'_>, DB> { RethEvmBuilder::new(db, self.default_external_context()).with_env(env.into()).build() } ` and not taking into account `self.evm()` where the dependency on `.optimism` is present.

I wanted to tackle this in a follow up to propose something more unified or in this PR if you prefer.

Copy link
Collaborator

Choose a reason for hiding this comment

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

hmm, tbh I'm very confused by this, not obvious to me what this pr achieves.
In general I find it hard to reason about what to invoke on evm and I don't fully get why we now need to override this function when it previously wasn't the case.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes I understand, let me proposed something better in this pr in a bit :) will be clearer I think

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@mattsse I just proposed a very small change. I think we can merge like that. It's already a first path forward.

But to summarize for the rest, the problem I encounter here is with the .optimism() which only intervenes under the optimism cfg but which pollutes my construction with the Reth EVM builder because it intervenes before the build and in the three functions evm, evm_with_env and evm_with_inspector. This is what prevents for the moment to use the Reth EVM builder here.

@emhane emhane added this pull request to the merge queue Aug 21, 2024
@emhane emhane removed this pull request from the merge queue due to a manual request Aug 21, 2024
@emhane
Copy link
Member

emhane commented Aug 21, 2024

pending @onbjerg or @mattsse

@emhane emhane added the C-debt Refactor of code section that is hard to understand or maintain label Aug 21, 2024
@mattsse mattsse added this pull request to the merge queue Aug 22, 2024
Merged via the queue into paradigmxyz:main with commit 82f41c5 Aug 22, 2024
32 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-debt Refactor of code section that is hard to understand or maintain
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants