feat(flashblocks rpc): Full revamp of X Layer custom flashblocks RPC layer

[sieniven]

Summary

This PR revamps the entire flashblocks rpc layer design, similar to the previous Realtime-feature (RTA) cache capabilities on the since discontinued xlayer-erigon (refer to: https://github.com/okx/xlayer-erigon/tree/dev/zk/realtime).

Essentially, this revamp implements the full solution 2 mentioned in the upstream reth's issue discussion thread: paradigmxyz/reth#20491, which is a more elegant design to the complex op-reth's flashblock rpc layer that is still dependent on the canonical chainstate.

Motivations

The best design for allowing minimal latencies is to allow a full state accumulation from incoming flashblocks that are ahead of the canonical chainstate, while allowing for a hybrid sync approach that:

1. State accumulated from incoming flashblocks that are ahead of the canonical chainstate are stored in memory
2. Optimize default CL sync from the state accumulation through a pre-warming mechanism of already executed flashblocks sequence (skip payload re-validation entirely)
3. Automatic flushing of flashblocks state layer once canonical chainstate catches up
4. State queries (pending and confirmed states, also supporting latest tags) on flashblocks rpc tries to read from both the flashblocks state cache and underlying canon provider
5. State queries handle edge cases automatically such as chain re-orgs, flashblocks re-orgs, and flashblocks state layer lagging behind canonical chainstate

New flashblocks rpc design

1. Flashblock cache layer

• Adds the new FlashblockStateCache layer which includes both the pending state and confirm state caches
• Confirm state cache indexes and stores full block data (state and stateless) in moemory
• Pending state cache stores the current flashblocks sequence state received from the sequencer
• On cache misses on the flashblocks state cache, all state queries are proxied to the underlying canon provider
• To handle edge case where canon provider is ahead of flashblocks state cache and cache reorg has not yet been triggered, if state retrieval hits on both underlying canon provider and flashblocks cache, we prioritize canon provider as the source of truth

2. Flashblocks eth rpc extension

• Adds the new flashblocks-eth rpc extension (and maintaining compatibility with upstream OpEthApi)
• Override all eth json-rpc APIs to support using the new flashblocks state cache layer and the underlying canon chainstate provider

3. Revamp worker

• Change logic to by default always calculate state root. Merklization on payload validation has been optimized greatly on reth's v1.11 release onwards with the new sparse trie implementation (feat: sparse trie as cache paradigmxyz/reth#21583) and is no longer a bottleneck here
• Align worker logic to the default reth's payload validation logic
• TODO: add support for flashblocks block access list for faster flashblocks sequence execution and validation

4. Remove sequence manager, revamp to RawCache

• Removes the sequence manager entirely and its overly complicated updating logic from the execution task completion thread (updating calculated SR near target flashblocks count and re-broadcasting the same sequence)
• Simplifying to use a raw cache, which accumulates the raw flashblocks received by the sequencer
• Raw cache maintains similar logic to get the next best build-args, while tracking the last fully executed flashblocks sequence index

5. Add handlers for flashblocks state update logic

• Add handle_flashblocks handler - handle receiving a raw flashblock, and updating the raw cache
• Add handle_flashblocks_state handler - handle spawning task execution for flashblocks sequence validation and updating the flashblocks state cache
• Add handle_canonical_block - logic to handle canonical chainstate updates to flush flashblocks state cache layer, and also handle extreme cases like chain reorgs, etc

Supported flashblocks eth APIs

Block apis
[✅] eth_blockNumber
[✅] eth_getBlockByNumber
[✅] eth_getBlockByHash
[✅] eth_getBlockReceipts
[✅] eth_getBlockTransactionCountByNumber
[✅] eth_getBlockTransactionCountByHash

Transaction apis
[✅] eth_getTransactionByHash
[✅] eth_getRawTransactionByHash
[✅] eth_getTransactionReceipt
[✅] eth_getTransactionByBlockHashAndIndex
[✅] eth_getTransactionByBlockNumberAndIndex
[✅] eth_getRawTransactionByBlockHashAndIndex
[✅] eth_getRawTransactionByBlockNumberAndIndex
[✅] eth_sendRawTransactionSync

State apis
[✅] eth_call
[✅] eth_estimateGas
[✅] eth_getBalance
[✅] eth_getTransactionCount
[✅] eth_getCode
[✅] eth_getStorageAt

TODO:
Support eth_getLogs in the future

Design flaws on op-reth flashblocks rpc

1. The flashblocks rpc layer is tightly coupled to the canonical chainstate height. Thus, although they have since added optimistic builds to advance the pending state, however confirmed chainstates (using "latest" tags) are still dependent on the canonical chainstate
2. Flashblocks consensus sync mode does not make sense since flashblocks finality is less probably than default blocks. Flashblocks consensus sync also cannot currently account for rollbacks
3. Lack of support or design consideration for hybrid sync approach - tightly coupled with reason 2. Using a hybrid sync approach (CL sync + flashblocks state updates) is ideal for flashblocks design. However, full payloads from CL driven sync are currently re-executed on the default payload validator on engine_newPayload (even though the flashblocks sequence had already executed and validated the exact same payload)
4. SR calculations are triggered based on configurable values instead of a more deterministic approach, which can be a point of failure on rpc consensus. Also with reth's sparse trie async task feature implemented on reth v1.11 onwards, incremental SR calculations on payload validation becomes much cheaper
5. No flashblocks BAL implemented