Generic transaction and block Environment.

[rakita]

After Evm builder is finished we should generalize the Block and Transaction to the trait, this would allow adding new fields to both of those structs and elevate usage of the External Contexts as it would allow multiple generics and easier integration with other types.

Evn should stay as the default type that we use, and this would be overridable in EvmBuilder.

[rakita]

Make Transaction generic contains tx type so we have a clean difference between transactions, currently we have done it ad hoc if field is Some.

[Rjected]

Yeah, at least for the concrete types we would want something like this:

/// Ethereum tx env
pub struct EthTxEnv {
    // ... the tx env fields for mainnet ethereum
}

/// Data used to calculate the l1 cost of a transaction
pub struct RollupCostData {
    /// The number of ones in the rlp encoding of the signed transaction being executed
    pub ones: u64,
    /// The number of zeroes in the rlp encoding of the signed transaction being executed
    pub zeroes: u64,
}

/// Optimism tx env
pub struct OptimismTxEnv {
    /// The underlying ethereum tx environment
    pub eth_env: EthTxEnv,
    // ... then the optimism specific fields
    // ideally including this:
    pub rollup_cost_data: RollupCostData,
}

And each of these would implement an environment trait with methods to expose what we currently use in mainnet eth execution.

We'd also want some flexibility, for example to let optimism actually use its custom tx env fields.
For example here are some things that optimism currently does with custom fields:

revm/crates/primitives/src/env.rs

Lines 84 to 94 in 7cf937a

	// Do not allow for a system transaction to be processed if Regolith is enabled.
	if self.tx.optimism.is_system_transaction.unwrap_or(false)
	&& SPEC::enabled(SpecId::REGOLITH)
	{
	return Err(InvalidTransaction::DepositSystemTxPostRegolith);
	}
	// Do not perform any extra validation for deposit transactions, they are pre-verified on L1.
	if self.tx.optimism.source_hash.is_some() {
	return Ok(());
	}

revm/crates/primitives/src/env.rs

Lines 207 to 212 in 7cf937a

	// On Optimism, deposit transactions do not have verification on the nonce
	// nor the balance of the account.
	#[cfg(feature = "optimism")]
	if self.cfg.optimism && self.tx.optimism.source_hash.is_some() {
	return Ok(());
	}

revm/crates/revm/src/optimism/handler_register.rs

Lines 125 to 150 in 7cf937a

	// If the transaction is not a deposit transaction, subtract the L1 data fee from the
	// caller's balance directly after minting the requested amount of ETH.
	if context.evm.env.tx.optimism.source_hash.is_none() {
	// get envelope
	let Some(enveloped_tx) = context.evm.env.tx.optimism.enveloped_tx.clone() else {
	return Err(EVMError::Custom(
	"[OPTIMISM] Failed to load enveloped transaction.".to_string(),
	));
	};
	let tx_l1_cost = context
	.evm
	.l1_block_info
	.as_ref()
	.expect("L1BlockInfo should be loaded")
	.calculate_tx_l1_cost(&enveloped_tx, SPEC::SPEC_ID);
	if tx_l1_cost.gt(&caller_account.info.balance) {
	return Err(EVMError::Transaction(
	InvalidTransaction::LackOfFundForMaxFee {
	fee: tx_l1_cost.into(),
	balance: caller_account.info.balance.into(),
	},
	));
	}
	caller_account.info.balance = caller_account.info.balance.saturating_sub(tx_l1_cost);
	}

Not sure how yet we could provide this flexibility, maybe adding some hooks that are run in the beginning of tx validation, or elsewhere

[rakita]

This is imagined to be a TxTrait or TxEnvTrait that you can override if needed. It is up to lib user to specify different generics of the trait and add handlers that use that trait. In reth, this would be just implementing TxTrait over &Transaction and you could use &Transaction directly inside revm without need to populate Env

[Autoparallel]

I'll give this a shot

[rakita]

Done on main