feat: pass evm config to pool components builder#8
Conversation
| + FromRecoveredTx<TxTy<Self::Primitives>> | ||
| + FromTxWithEncoded<TxTy<Self::Primitives>>, | ||
| Precompiles = PrecompilesMap, | ||
| Spec: Into<SpecId>, |
There was a problem hiding this comment.
this is enforced by revm's Cfg trait so practically any evm spec likely implements this
mattsse
left a comment
mattsse
left a comment
There was a problem hiding this comment.
while this changes some apis, I think this is the right deisgn because pool validation is kinda closely coupled with the evm now or at least we want to make this easy
| // Get EVM limits from evm_config.evm_env() | ||
| let evm_env = self | ||
| .evm_config | ||
| .evm_env(new_tip_block) | ||
| .expect("evm_env should not fail for executed block"); | ||
|
|
||
| self.fork_tracker | ||
| .max_initcode_size | ||
| .store(evm_env.cfg_env.max_initcode_size(), std::sync::atomic::Ordering::Relaxed); | ||
| self.fork_tracker | ||
| .tx_gas_limit_cap | ||
| .store(evm_env.cfg_env.tx_gas_limit_cap(), std::sync::atomic::Ordering::Relaxed); |
| // Get EVM limits from evm_config.evm_env() | ||
| let evm_env = self | ||
| .evm_config | ||
| .evm_env(new_tip_block) |
There was a problem hiding this comment.
q: is there an off by 1 error on fork blocks?
if the next block after new_tip_block is the fork block with a new evm_env, then the mempool will not correctly reject transactions.
This is still fine if the reth builder correctly discards the invalid txs at a later stage and it's only 1 block of potentially excess work/suboptimal block.
No way around it without knowing/predicting next block timestamp
(this concern wasn't introduced in this PR)
3 participants
This passes the EVM config to the pool components builder, allowing pool validation to use configurable EVM execution limits.
targets paradigmxyz#21088