Transaction order in block

[grantweii]

Did you check the documentation?

• Yes

Did you read the specs?

• Yes
• No

Did you check for duplicate questions?

• Yes

Issue Description

It is not clear to me how the sequencer orders transactions within a block.
The docs specify

The OP Mainnet sequencer will prioritize transactions with a higher priority fee

however, I have seen competing transactions (calls the same function) have a higher position in block with a higher max priority fee but lower max base fee. This suggests that the ordering does not just depend on the max priority fee but also max base fee. What is the a calculation that determines the order?

Additional Information

No response

Feedback

No response

[ajsutton]

Transactions are ordered based on the payment to the block builder. For 1559 transactions, that's the GasTipCap value, for non-1559 transactions that's the difference between the GasFeeCap and the current base fee. Note however that transactions must be included in nonce order for each account. You can see the code used for this starting at https://github.com/ethereum-optimism/op-geth/blob/8e15470125ba3689dd7288e2aa7bbdca8730701b/miner/worker.go#L1072 (tx pool management is one of the more complex areas of an Ethereum client unfortunately). When looking at that code, two things to note:

1. The sequencer is configured to treat all transactions as remote.
2. There is no guarantee that this algorithm won't change in the future. The tip paid to the block builder is always going to be the key thing to prioritise but the exact details of the algorithm may change. One example of that is that currently geth uses the time between blocks to repeatedly build complete blocks from scratch. That allows it to add new transactions that arrive after the first template block are received. It could be made more efficient in the future though to build with the available transactions and then simply append transactions received later to that block if there's gas left. There's a number of other potential optimisations like that where its still prioritising transactions with a higher priority fee but not necessarily including them in strict priority fee order.

[grantweii]

Hi Adrian, thanks for responding. Correct me if I'm wrong, ordering is currently min(max_base, base + max_priority) with higher values being lower in the block.

[ajsutton]

Yeah I think you may be right about that except that it's min(GasTipCap, GasFeeCap - BaseFee). The code is attempting to handle the legacy transaction case where the miner is paid the GasPrice - BaseFee but it winds up applying the same logic to 1559 transactions and may prioritise a transaction that has a high MaxFeeCap but low MaxTipCap which is sub-optimal. That code comes straight for upstream geth I believe and potentially reduces the value of blocks geth produces on L1 so probably should be fixed there.

[grantweii]

makes sense now, thank you!

[github-actions[bot]]

Hey @grantweii, We hope your recent question was resolved to your satisfaction. Your feedback is invaluable and helps us improve our support services. Could you spare a moment to fill out a short feedback survey. Thank you for helping us improve our developer community.