Fix Flashblock state lookups for future blocks

[danyalprout]

Hey guys, maybe here is not the ideal place to ask, but it is likely related to the same component.

I am running a devnet with op-node+op-geth in the sequencer side and with rollup-boost+flashblocks enabled and using base-reth I am running in the scenario of Flashblocks arriving 50-60ms BEFORE the current head gets inserted. How to solve that? Needs some implementation in the client side? I could work in some PR if needed. Thanks!

2025-08-04 13:52:58.196Z opstack-validator-reth 2025-08-04T13:52:58.196463Z  INFO base_reth_flashblocks_rpc::flashblocks: previous block processed flash_blocks_count=5
2025-08-04 13:52:58.196Z opstack-validator-reth 2025-08-04T13:52:58.196572Z ERROR base_reth_flashblocks_rpc::flashblocks: Unable to execute flashblocks transactions. Eth call override is empty. error=no header found for Number(2897021)
2025-08-04 13:52:58.196Z opstack-validator-reth 2025-08-04T13:52:58.196650Z DEBUG base_reth_flashblocks_rpc::flashblocks: no active subscribers for receipt broadcast tx_hash=0xb80fb76d39e4b36c7b105ca2603e75bcfb38de6f079aa9e97f0e2c6ec3223a60
2025-08-04 13:52:58.196Z opstack-validator-reth 2025-08-04T13:52:58.196668Z  INFO base_reth_flashblocks_rpc::flashblocks: block processing completed processing_time=227.626µs
2025-08-04 13:52:58.247Z opstack-validator-reth 2025-08-04T13:52:58.247289Z  INFO reth_node_events::node: Received block from consensus engine number=2897021 hash=0x9a6f5be253520de436c4c19570b765b2126b78b1c8c5831de91c280bdca9d26e
2025-08-04 13:52:58.251Z opstack-validator-reth 2025-08-04T13:52:58.251533Z  INFO engine::tree: State root task finished state_root=0x4a5cdf6473746c01b11f6913a10906b87dcc122bba017dca552fc8a599f36354 elapsed=2.366464ms
2025-08-04 13:52:58.251Z opstack-validator-reth 2025-08-04T13:52:58.251649Z  INFO reth_node_events::node: Block added to canonical chain number=2897021 hash=0x9a6f5be253520de436c4c19570b765b2126b78b1c8c5831de91c280bdca9d26e peers=1 txs=1 gas=43.81 Kgas gas_throughput=15.49 Mgas/second gas_limit=60.00 Mgas full=0.1% base_fee=0.00gwei blobs=0 excess_blobs=0 elapsed=2.828198ms
2025-08-04 13:52:58.252Z opstack-validator-reth 2025-08-04T13:52:58.252391Z  INFO reth_node_events::node: Canonical chain committed number=2897021 hash=0x9a6f5be253520de436c4c19570b765b2126b78b1c8c5831de91c280bdca9d26e elapsed=21.003µs
2025-08-04 13:53:00.186Z opstack-validator-reth 2025-08-04T13:53:00.186303Z  INFO base_reth_flashblocks_rpc::flashblocks: previous block processed flash_blocks_count=5
2025-08-04 13:53:00.186Z opstack-validator-reth 2025-08-04T13:53:00.186425Z ERROR base_reth_flashblocks_rpc::flashblocks: Unable to execute flashblocks transactions. Eth call override is empty. error=no header found for Number(2897022)
2025-08-04 13:53:00.186Z opstack-validator-reth 2025-08-04T13:53:00.186497Z DEBUG base_reth_flashblocks_rpc::flashblocks: no active subscribers for receipt broadcast tx_hash=0xf6d251e5afd781a4d16545dd79309f6a2e8a727fc9201e6490c5392e4c3104a9
2025-08-04 13:53:00.186Z opstack-validator-reth 2025-08-04T13:53:00.186514Z  INFO base_reth_flashblocks_rpc::flashblocks: block processing completed processing_time=233.679µs
2025-08-04 13:53:00.246Z opstack-validator-reth 2025-08-04T13:53:00.246775Z  INFO reth_node_events::node: Received block from consensus engine number=2897022 hash=0x0198ef2eaabbf321e91a0c837baf1e0f293b5ff0c0bbd712135c02b14e09e8e7
2025-08-04 13:53:00.251Z opstack-validator-reth 2025-08-04T13:53:00.251058Z  INFO engine::tree: State root task finished state_root=0x62c3f4ef2c692a9968bad9f8876b7c94911e0e567a22f76fe43fa20da9e43fe1 elapsed=2.398626ms
2025-08-04 13:53:00.251Z opstack-validator-reth 2025-08-04T13:53:00.251170Z  INFO reth_node_events::node: Block added to canonical chain number=2897022 hash=0x0198ef2eaabbf321e91a0c837baf1e0f293b5ff0c0bbd712135c02b14e09e8e7 peers=1 txs=1 gas=43.81 Kgas gas_throughput=15.49 Mgas/second gas_limit=60.00 Mgas full=0.1% base_fee=0.00gwei blobs=0 excess_blobs=0 elapsed=2.827428ms
2025-08-04 13:53:00.251Z opstack-validator-reth 2025-08-04T13:53:00.251905Z  INFO reth_node_events::node: Canonical chain committed number=2897022 hash=0x0198ef2eaabbf321e91a0c837baf1e0f293b5ff0c0bbd712135c02b14e09e8e7 elapsed=19.226µs```
 

The logic to get the current state to build on top of is happening prior to the insertion of the previous block. This causes the whole Flashblock insertion to fail.

I think here we need to:

1. Make the Flashblock processing aware of canonical block changes (will happen as part of Invalidate Flashblocks when canonical blocks are more recent #51)
2. Handle multiple blocks worth of Flashblocks building on current unsafe, for example

<block 10 (unsafe)> ==> <block 11, all made of flashblock data> ==> <block 12, all made of flashblocks>

Block 10 is the lastest unsafe block, when we process block 12 we should build on top of the pending block 11 if we don't have a canonical block 11. When we receive a canonical block 11, we would validate it against flashblocks block 11 and if different invalidate subsequent Flashblocks.

cc @cody-wang-cb

Originally posted by @0xVasconcelos in #51

[0xsimulacra]

Hello,

I was about to post something similar before I found this issue.

With the current main branch (correct me if I’m wrong), the whole flashblock fn process_flashblock(&self, flashblocks: Vec<Flashblock>) will fail if we don’t find the state of previous_block in the database in order to build the state overrides on top of it, which will cause subsequent calls to fn on_flashblock_received(&self, flashblock: Flashblock) for the same block’s flashblocks to fail as well.

Meaning, unless we have the state of block n-1 (previous_block) in the database (which is not uncommon) when the flashblock with index == 0 of block n arrives, the flashblock data won’t be processed for that whole block.

A quick solution I experimented with (it is based on the old, non-refactored code from the latest release of this repo) is:

• When a new flashblock is received, if the state of block n-1 isn’t available, I don’t build the state overrides for that flashblock, but I still process the flashblock data as normal.

• When the next flashblock arrives and I have the state for block n-1, I process the flashblock data and also build the state overrides.

My solution had the flaw that I rebuild the state overrides starting from flashblock.index == 0 every time I receive a new flashblock, which is suboptimal. However, I notice that this can be mitigated fairly easily with the current state of the main-branch code.

But, of course, this is just a simpler and less sophisticated solution than what you’re proposing and doesn’t account for having state overrides at all times.

[extradz]

hello, any news about that issue ?
i still running base reth 1.1.5 because i can't run 1.1.6 due to that error

[0xsimulacra]

@extradz

The error doesn't have anything to do with reth version and the latest release of this repo (which uses reth v1.6.0) works as epexcted AFAIK.

This is more of an issue that exist on the main branch and not on the release version.

[danyalprout]

That's right @0xsimulacra

[danyalprout]

Opened #67 to clarify the docs. I'll take a look at fixing this issue

[0xsimulacra]

@danyalprout

Besides my comment about flashblocks building for the current block failing when the state of block n-1 isn’t available, I noticed an issue with how state_overrides are built:

• I really like that we cache the DB and transition_state so we don’t have to replay the whole series of flashblock txs to compute new state_overrides when a new flashblock arrives for the same block.

• However, when a new flashblock arrives, the stored overrides cover only the txs in that last flashblock (i.e., they aren’t merged with the previous state_overrides for the same pending block). As a result, an eth_call with the "pending" block param injects only the overrides for the latest flashblock’s txs, which is probably not what you want ? (you likely want to inject the full pending block’s overrides for the eth_call).

[haardikk21]

Done with #78