-
Notifications
You must be signed in to change notification settings - Fork 2.2k
feat(flashblocks): Flashblocks engine sidecar #19479
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
e28c5bc to
1f7443c
Compare
| //! The goal is to have the conversion logic in one place to avoid missing steps. | ||
| use crate::{ | ||
| ExecutionPayloadBaseV1, ExecutionPayloadFlashblockDeltaV1, FlashBlockCompleteSequence, |
There was a problem hiding this comment.
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
- centralize commonly shared data structures
- also we can move this convert.rs functionality directly into
op-alloy-rpc-types-engineand sit alongside with OpExecutionData to share the same block / flashblock ->ExecutionDataconversion logic
There was a problem hiding this comment.
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
mattsse
left a comment
There was a problem hiding this 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
1d7ba92 to
a7d2396
Compare
CodSpeed Performance ReportMerging #19479 will not alter performanceComparing Summary
|
4ddf3ff to
1ae3b3b
Compare
|
do you mind rebasing this on top of #19608 so that it's easier to review? |
|
@0x00101010 released new op-alloy patch with alloy-rs/op-alloy#606 |
31a28cf to
919edf7
Compare
Done |
919edf7 to
10c1564
Compare
|
this needs rebase again |
06db091 to
0bb1d9e
Compare
0bb1d9e to
bde015c
Compare
@klkvr done |
klkvr
left a comment
There was a problem hiding this 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
| safe_block_hash: B256::ZERO, | ||
| finalized_block_hash: B256::ZERO, |
There was a problem hiding this comment.
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?
| // 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. |
There was a problem hiding this comment.
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"); |
There was a problem hiding this comment.
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
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:
Integration
crates/optimism/rpc/src/eth/mod.rsFlashBlockConsensusClientwhen flashblocks are enabledbeacon_engine_handleto enable payload submissioncrates/node/builder/src/rpc.rsbeacon_engine_handleinEthApiCtxfor RPC builders to accessexamples/custom-node/src/engine.rsFrom<&FlashBlockCompleteSequence>for custom execution data typesDependencies
crates/optimism/flashblocks/Cargo.tomlop-alloy-rpc-types-engine(required forOpExecutionData)ringbuffer(no longer needed with simplified FCU logic)Testing
Follow up needed
handle optional state root calculations scenarioDonehandle Jovian upgrade situation where blob_gas_used is not 0, need to updateDonerollup-boost,op-rbuilder, and this repo for consistent types.ideally we move all the flashblocks relevant data structures intoDoneop-alloy-rpc-types-engine