eth_callBundle implementation has a bug (wrongly validating maxFeePerGas using state's baseFee) #9112
Closed
1 task done
Labels
A-rpc
Related to the RPC implementation
C-bug
An unexpected or incorrect behavior
D-good-first-issue
Nice and easy! A great choice to get started
Describe the bug
reth node's eth_callBundle's implementation has a bug.
It falsely raises 'RpcInvalidTransactionError::FeeCapTooLow' when transactions are valid.
Explanation
reth currently validates for the incoming transaction's baseFee using the following code
(1) fetch the block environment given by the state block number
(rpc/rpc/src/eth/bundle.rs)
(2) for each incoming transaction, it uses block's basefee to check whether tx has set sufficient gas fee.
But it is 'INCORRECT' in that, [target block]'s base fee could be lower than the [state block]s base fee.
If [state block]'s utilization rate is low, its next block will have lower base fee (london fork).
i.e. it should be calculated, rather than just copying the raw value of the state block.
(rpc/rpc/src/eth/bundle.rs)
Suggestion
below suggestion is how flashbots-mev-geth's implementation handles above situation.
link to original source
Steps to reproduce
Steps to reproduce:
(1) call eth_callBundle with the following transaction with the parameters
tx: 0x024edcc98eccbae9fb5ef859d101abafd50baa9ba668c79aa8333c4db173fa92
block_number: 20172628
state_block_number: 20172627
block (20172627)'s basefee is 2507760629
block (20172628)'s basefee is 2440794978
and reth uses state block's basefee to reject the tx simulation.
Node logs
No response
Platform(s)
Linux (x86)
What version/commit are you on?
1.0.0-rc.2
What database version are you on?
Current database version: 2
Which chain / network are you on?
mainnet (1)
What type of node are you running?
Full via --full flag
What prune config do you use, if any?
No response
If you've built Reth from source, provide the full command you used
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: