Skip to content

Conversation

SozinM
Copy link
Collaborator

@SozinM SozinM commented Aug 25, 2025

πŸ“ Summary

Made a doc with whole flashblocks flow

πŸ’‘ Motivation and Context


βœ… I have completed the following steps:

  • Run make lint
  • Run make test
  • Added tests (if applicable)

Copy link
Contributor

@avalonche avalonche left a comment

Choose a reason for hiding this comment

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

Is there a need to include the no-tx-pool flow? In practice op-rbuilder does not receive these calls as rollup-boost filters them

@SozinM
Copy link
Collaborator Author

SozinM commented Aug 25, 2025

@avalonche this is non-obvious part about our arch, so i need to capture it somewhere

There is 2 separate cases, for regular block and for block with no-txpool flag. When building no-txpool block we are using only fallback EL to construct the block.
This is done to rely on canonical implementation for such block as they are not compute intensive.
## Regular block building flow
```sequence
Copy link
Contributor

Choose a reason for hiding this comment

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

sequence does not render on GitHub, can maybe try mermaid instead?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

no, it doesn't work too
maybe i will recreate it in excalidraw once we iron it out

Copy link
Contributor

@akundaz akundaz Aug 25, 2025

Choose a reason for hiding this comment

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

what are you using locally to render? it doesn't work in vscode for me either

rollup-boost -> op-rbuilder: FCU w/ attr
op-geth -> rollup-boost: VALID/SYNCING
op-rbuilder -> rollup-boost: VALID/SYNCING
rollup-boost -> rollup-boost: Set that op-rbuilder is building this block
Copy link
Contributor

Choose a reason for hiding this comment

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

how does it do this?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

In-memory variable (hash map with payload id as a key)

Copy link
Contributor

Choose a reason for hiding this comment

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

it only does this if the builder responds valid right? I think we can clarify it uses the payload id to fetch the flashblocks

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Hmmm, i thnk it would still work in builder won't answer valid
But i need to check the code

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

it uses payload_id to validate that flashblocks are from this batch

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

But if FCU returned SYNCING it means that block building won't even start and we won't receive flashblocks
But there is no guarantee code wise

@SozinM SozinM force-pushed the msozin/flashblock-doc branch from d3446e7 to 4dd9e2f Compare August 25, 2025 15:53
Copy link
Contributor

@avalonche avalonche left a comment

Choose a reason for hiding this comment

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

would add also how the web socket-proxy propagates the flashblocks to the rpc overlay and how nodes responds with flashblocks state

@SozinM SozinM force-pushed the msozin/flashblock-doc branch from 4dd9e2f to 4415640 Compare August 25, 2025 15:53
@SozinM
Copy link
Collaborator Author

SozinM commented Aug 25, 2025

I will add another diagram for RPC overlay, because it's quite self-contained

@avalonche
Copy link
Contributor

btw please check GitHub preview before merge
Screenshot 2025-08-26 at 2 57 27β€―am

@SozinM SozinM force-pushed the msozin/flashblock-doc branch 2 times, most recently from 7d3ab43 to 72d2095 Compare August 26, 2025 12:28
@SozinM SozinM force-pushed the msozin/flashblock-doc branch from 331d1ae to e0c42de Compare August 26, 2025 12:51
OR->>RB: VALID/SYNCING
RB->>RB: Mark that op-rbuilder is building this block
RB->>ON: op-geth VALID/SYNCING
OR->>OR: Start block building
Copy link
Contributor

Choose a reason for hiding this comment

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

Call this step instead "Start building flashblocks"?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

But it's block building job
Flashblocks are by-product

@SozinM SozinM merged commit 00a3a7c into main Aug 29, 2025
4 checks passed
@SozinM SozinM deleted the msozin/flashblock-doc branch August 29, 2025 09:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants