-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
op-reth: deposit type txs are skipped when building block due to GasPriceLessThanBasefee
- possibly due to revm 4/5+
#6592
Comments
ptal @rakita |
The issue seems to be with the evm config reth/crates/payload/optimism/src/lib.rs Lines 304 to 321 in 11dbd08
Reth creates a handler config via The Note Going back to if cfg.handler_cfg.is_optimism {
new.enable_optimism()
} so
ultimately it fails to call Instead it uses mainnet logic which checks the gas price against the base fee and returns a just seen a new PR was submitted as I was typing this lol - will post anyway just in case this doesn't fix #6593 |
|
#6598 fixes the block/payload building issue, but now there's an error during block validation after receiving
here's the trace logs:
The stateroot, transactions root, receipts root, etc are all correct in the built sealed block. i think the error lies in configuration of the EVMProcessor::new_with_db(
self.chain_spec.clone(),
database_state,
self.evm_config.clone(),
)
within let mut cfg: CfgEnvWithHandlerCfg =
CfgEnvWithHandlerCfg::new(self.evm.cfg().clone(), self.evm.spec_id());
EvmConfig::fill_cfg_and_block_env(
&mut cfg,
self.evm.block_mut(),
&self.chain_spec,
header,
total_difficulty,
); probably needs the same fix as applied in #6598 |
Describe the bug
Running op-reth on v0.1.0-alpha.18
rollup node sends
engine_forkchoiceUpdatedV2
with 2 x0x7E
deposit type txs, and 5 regular txs.Op-Reth receives, but fails to execute the 2 deposit type txs. The remaining 5 txs are successfully executed and included in the built block/payload.
The end result is a new payload is built that is missing the deposit txs, which is then sent to the rollup.
Subsequent derivation then fails due to the built block being an invalid parent for future blocks.
I'm still trying to figure out where this bug was introduced. Previously was running on v0.1.0-alpha.16 with no issues, so it's possible that this revm version bump caused it #6357, or the bump to revm 5.0 #6560.
This could maybe be solely an revm issue, or it may be due to reth not being configured properly for the latest revm versions.
The issue was also occurring on commit 0e166f0.
note - I'm running a very lightly modified version of op-reth to support an additional chain (mode) which is a vanilla op-stack rollup. Only reth modifications are adding the genesis, chain spec, etc and dependencies such as alloy-chains already support this chain. Reth has been working fine for this chain up until upgrading reth versions.
Steps to reproduce
can possibly replicate via
reth debug build-block
using an op-stack db + chain and the transaction param as follows:Node logs
engine receives forkchoiceUpdatedV2 message with attributes:
engine returns payload ID to rollup:
reth begins building the block:
Platform(s)
Linux (x86)
What version/commit are you on?
v0.1.0-alpha.18
What database version are you on?
Current database version: 1
What type of node are you running?
Full via --full flag
What prune config do you use, if any?
default
If you've built Reth from source, provide the full command you used
cargo build --profile release --locked --bin op-reth --features "optimism,jemalloc,asm-keccak"
Code of Conduct
The text was updated successfully, but these errors were encountered: