Skip to content

Conversation

@0x00101010
Copy link
Contributor

@0x00101010 0x00101010 commented Nov 4, 2025

Towards: #18255, see bottom for follow up needed.

feat(op-reth): integrate flashblocks with consensus engine

Summary

This PR completes the integration of flashblocks with the consensus engine by:

  • Adding structured conversion infrastructure from flashblock sequences to execution payloads
  • Automatically spawning the consensus client when flashblocks are enabled
  • Improving error handling and observability with detailed logging

Integration

crates/optimism/rpc/src/eth/mod.rs

  • Added automatic spawning of FlashBlockConsensusClient when flashblocks are enabled
  • Wired up beacon_engine_handle to enable payload submission

crates/node/builder/src/rpc.rs

  • Exposed beacon_engine_handle in EthApiCtx for RPC builders to access

examples/custom-node/src/engine.rs

  • Added example implementation of From<&FlashBlockCompleteSequence> for custom execution data types
  • Shows how to derive custom extensions from flashblock sequences

Dependencies

crates/optimism/flashblocks/Cargo.toml

  • Added: op-alloy-rpc-types-engine (required for OpExecutionData)
  • Removed: ringbuffer (no longer needed with simplified FCU logic)

Testing

  • All existing tests pass
  • New unit tests for conversion functions
  • Clippy clean with all features enabled

Follow up needed

  • handle optional state root calculations scenario Done
  • handle Jovian upgrade situation where blob_gas_used is not 0, need to update rollup-boost, op-rbuilder, and this repo for consistent types. Done
  • ideally we move all the flashblocks relevant data structures into op-alloy-rpc-types-engine Done
  • add functionality to work with different forks

@github-project-automation github-project-automation bot moved this to Backlog in Reth Tracker Nov 4, 2025
@0x00101010 0x00101010 force-pushed the fb-engine-sidecar branch 2 times, most recently from e28c5bc to 1f7443c Compare November 4, 2025 02:12
@0x00101010 0x00101010 marked this pull request as ready for review November 4, 2025 03:11
//! The goal is to have the conversion logic in one place to avoid missing steps.
use crate::{
ExecutionPayloadBaseV1, ExecutionPayloadFlashblockDeltaV1, FlashBlockCompleteSequence,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mattsse what's your thoughts on moving above data structures into op-alloy-rpc-types-engine?

Currently they're defined in rollup-boost and imported by op-rbuilder, etc.

If we're making reth to support flashblocks natively, it seems reasonable to move those into op-alloy-rpc-types-engine and update all other repos to refer to it.

This helps with

  1. centralize commonly shared data structures
  2. also we can move this convert.rs functionality directly into op-alloy-rpc-types-engine and sit alongside with OpExecutionData to share the same block / flashblock -> ExecutionData conversion logic

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mattsse what's your thoughts on moving above data structures into op-alloy-rpc-types-engine?

yeah that would be ideal, even if the format changes we can still make that work

Copy link
Collaborator

@mattsse mattsse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually pretty simple, very nice

imo we should first offload all things flashblock types to op-alloy and then merge this

@github-project-automation github-project-automation bot moved this from Backlog to In Progress in Reth Tracker Nov 5, 2025
@codspeed-hq
Copy link

codspeed-hq bot commented Nov 9, 2025

CodSpeed Performance Report

Merging #19479 will not alter performance

Comparing 0x00101010:fb-engine-sidecar (691d226) with main (95b8a85)

Summary

✅ 81 untouched

@0x00101010 0x00101010 force-pushed the fb-engine-sidecar branch 2 times, most recently from 4ddf3ff to 1ae3b3b Compare November 9, 2025 19:57
@0x00101010 0x00101010 requested a review from mattsse November 10, 2025 02:21
@klkvr
Copy link
Member

klkvr commented Nov 11, 2025

do you mind rebasing this on top of #19608 so that it's easier to review?

@mattsse
Copy link
Collaborator

mattsse commented Nov 11, 2025

@0x00101010 released new op-alloy patch with alloy-rs/op-alloy#606

@0x00101010 0x00101010 force-pushed the fb-engine-sidecar branch 3 times, most recently from 31a28cf to 919edf7 Compare November 11, 2025 18:47
@0x00101010
Copy link
Contributor Author

do you mind rebasing this on top of #19608 so that it's easier to review?

Done

@klkvr
Copy link
Member

klkvr commented Nov 12, 2025

this needs rebase again

@0x00101010 0x00101010 force-pushed the fb-engine-sidecar branch 2 times, most recently from 06db091 to 0bb1d9e Compare November 12, 2025 15:57
@0x00101010
Copy link
Contributor Author

this needs rebase again

@klkvr done

Copy link
Member

@klkvr klkvr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this does make sense, left some questions

defer to @mattsse for final review

Comment on lines +96 to +97
safe_block_hash: B256::ZERO,
finalized_block_hash: B256::ZERO,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what's the motivation for setting those to zero? not sure how to properly set those if the only source of truth we have are flashblocks but maybe we could keep the head-32?

Comment on lines +132 to +135
// Replace payload's state_root with the calculated one. For flashblocks, there was an
// option to disable state root calculation for blocks, and in that case, the payload's
// state_root will be zero, and we'll need to locally calculate state_root before
// proceeding to call engine_newPayload.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if we should somehow remove the need to compute state root here entirely?

engine will anyway end up computing it when verifying the payload, so this would just mean we do the work twice? cc @mattsse

though I guess it's kind of tricky because engine relies on the newPayload to come with a computed block hash


ctx.components.task_executor().spawn(Box::pin(service.run(tx)));

info!(target: "reth::cli", "Launching FlashBlockConsensusClient");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be optional? e.g if you want to run op-node and a flashblocks engine client

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: In Progress

Development

Successfully merging this pull request may close these issues.

3 participants