Add flashblocks sequence diagram #252
Conversation
avalonche
left a comment
avalonche
left a comment
There was a problem hiding this comment.
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
|
@avalonche this is non-obvious part about our arch, so i need to capture it somewhere |
docs/flashblocks.md
Outdated
| 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 |
There was a problem hiding this comment.
sequence does not render on GitHub, can maybe try mermaid instead?
There was a problem hiding this comment.
no, it doesn't work too
maybe i will recreate it in excalidraw once we iron it out
There was a problem hiding this comment.
what are you using locally to render? it doesn't work in vscode for me either
docs/flashblocks.md
Outdated
| 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 |
There was a problem hiding this comment.
In-memory variable (hash map with payload id as a key)
There was a problem hiding this comment.
it only does this if the builder responds valid right? I think we can clarify it uses the payload id to fetch the flashblocks
There was a problem hiding this comment.
Hmmm, i thnk it would still work in builder won't answer valid
But i need to check the code
There was a problem hiding this comment.
it uses payload_id to validate that flashblocks are from this batch
There was a problem hiding this comment.
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
force-pushed
the
msozin/flashblock-doc
branch
from
d3446e7 to
4dd9e2f
Compare
avalonche
left a comment
avalonche
left a comment
There was a problem hiding this comment.
would add also how the web socket-proxy propagates the flashblocks to the rpc overlay and how nodes responds with flashblocks state
SozinM
force-pushed
the
msozin/flashblock-doc
branch
from
4dd9e2f to
4415640
Compare
|
I will add another diagram for RPC overlay, because it's quite self-contained |
|
btw please check GitHub preview before merge |
SozinM
force-pushed
the
msozin/flashblock-doc
branch
2 times, most recently
from
7d3ab43 to
72d2095
Compare
SozinM
force-pushed
the
msozin/flashblock-doc
branch
from
331d1ae to
e0c42de
Compare
| 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 |
There was a problem hiding this comment.
Call this step instead "Start building flashblocks"?
There was a problem hiding this comment.
But it's block building job
Flashblocks are by-product
Co-authored-by: Julio <[email protected]>
4 participants
📝 Summary
Made a doc with whole flashblocks flow
💡 Motivation and Context
✅ I have completed the following steps:
make lintmake test