Skip to content

feat: extensions for EvmEnv#193

Merged
klkvr merged 3 commits intomainfrom
klkvr/env-ext
Oct 13, 2025
Merged

feat: extensions for EvmEnv#193
klkvr merged 3 commits intomainfrom
klkvr/env-ext

Conversation

@klkvr
Copy link
Copy Markdown
Member

@klkvr klkvr commented Oct 13, 2025

Motivation

Allows defining and propagating arbtirary extensions for EvmEnv

Solution

PR Checklist

  • Added Tests
  • Added Documentation
  • Breaking changes

Copy link
Copy Markdown
Member

@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 makes sense, a nicer way would be to entirely type def the evmenv but given that revm only operates on these this is fine and we could still add type Cfg, type BlockEnv separate and then there's still a use case for additional context that isnt blockenv of cfgenv

Comment on lines +17 to +18
#[deref]
#[deref_mut]
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

hmm, I think this seems okay, but could also move this to dedicated .ext_mut functions instead?

Copy link
Copy Markdown
Member

@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.

this is better than the extension imo

pedantic nits

/// Trait for types that can be used as a block environment.
///
/// Assumes that the type wraps an inner [`revm::context::BlockEnv`].
pub trait BlockEnvironment: revm::context::Block + Debug + Send + Sync + 'static {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I guess this trait wouldn't be necessary if the revm trait would also have setters, but we could consider adding those separately

but maybe it's a good idea to not have setters on that trait

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

yeah also not sure whether it makes sense

technically we also don't need revm's trait as supertrait here because we can just call inner but it also feels somewhat wrong to heavily rely on it even for number/timestamp queries

@klkvr klkvr merged commit 085ad53 into main Oct 13, 2025
27 checks passed
@klkvr klkvr deleted the klkvr/env-ext branch October 13, 2025 19:00
klkvr added a commit to tempoxyz/tempo that referenced this pull request Oct 15, 2025
Adds `timestamp_millis_part` field to `TempoHeader` defining
milliseconds portion of the timestamp.

For now it is not propagated to EVM as this would require some more
upstream changes alike to alloy-rs/evm#193
theochap pushed a commit to ethereum-optimism/optimism that referenced this pull request Jan 16, 2026
* BlockEnv AT

* fix

* review fixes
unbalancedparentheses pushed a commit to unbalancedparentheses/tempo that referenced this pull request Feb 23, 2026
Adds `timestamp_millis_part` field to `TempoHeader` defining
milliseconds portion of the timestamp.

For now it is not propagated to EVM as this would require some more
upstream changes alike to alloy-rs/evm#193
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants