Cannot land a tx in block 1

[m-quigley]

Bug Description

Not really a bug as I've found out from other sources that it is intended behaviour. Do forgive me, and if there's a more appropriate place to ask this question, close this issue and please let me know.

I am trying to troubleshot a more complex tool, but to simplify the issue I wrote a simple script that:

• subscribes to block headers
• on new block (block0) -> send a valid tx
• expect to see the tx land in block1

I've tried this with a range of gas/tip, and 2 paid RPC urls. One being a dedicted Chainstack node that I have ~3ms latency to. I've tried sending the tx via go-ethereum, op-geth, and via raw http.

Here's my log output

2025-01-18T04:04:17Z INF ================ Block 25191854 ================
2025-01-18T04:04:17Z INF 0ms: built tx
2025-01-18T04:04:17Z INF 26ms: sent tx. block [25191854]
2025-01-18T04:04:19Z INF ================ Block 25191855 ================
2025-01-18T04:04:21Z INF ================ Block 25191856 ================
2025-01-18T04:04:21Z INF 4169ms: tx success. block [25191856]

In all scenarios, I never land in block1, only block2. Despite the tx being submitted 26ms into the current block.

Steps to Reproduce
Outlined above. I'm happy to provide the full debug script if that helps.

Expected behavior
Transaction mined in block1

Environment Information:
Have tried on both Ubuntu and MacOS

Configurations:
N/A

Logs:
See above

Additional context
Havent been able to find much direct info on line, but as mentioned above, I've been told by the AI overlords that this is normal L2 behaviour. Not sure I buy it so would like to hear it from the source.

From the overlords

The behavior you're seeing is actually expected on BASE (and most L2s) due to how their block production and transaction inclusion works:
- When you submit a transaction in block N, even if done immediately when the block is received:
- The transaction first needs to be included in the mempool
- Then it needs to be picked up by the sequencer for the next block
Due to timing of block production and sequencer batching, your transaction typically lands in block N+2

---

⚠️ Notice: Issues that do not include the following sections will be subject to closure:

• Bug Description
• Steps to Reproduce
• Environment Information

Please ensure all required sections are filled out accurately to expedite the debugging process and improve issue resolution efficiency.