WIP: Builder Separation Design Doc #53
Conversation
| ``` | ||
| To break down the components of this diagram: | ||
|
|
||
| **Transactions are sent to the Execution Engine and Block Builder via Proxyd**. Today, the Execution Engine is responsible for being informed of Transactions and maintaining a mempool. With PBS, the Block Builder would have the same responsibilities. The Sequencer *does not* forward Transactions. This is because the Sequencer is not involved in the block building activities directly, and does not benefit from acting as a pass-through |
There was a problem hiding this comment.
We don't necessarily need to be opinionated about the orderflow. This architecture makes sense for an OP Mainnet style network, but you could imagine many architectures around the order flow
There was a problem hiding this comment.
I agree, referencing proxyd here is an over-constraint of the design which makes it OP Mainnet specific. The purpose of calling that mechanism out is:
proxydis the reference standard for delivering transactions to Execution Engines today, and the way in which transactions are delivered to Execution Engines should be matched when delivering to Block Builders.- Sequencers
op-nodeshould not have to process or route transaction traffic to other components.
I will expand on this to make it clear, though it may still be useful to reference proxyd as the entry-point for customer transactions.
| ProxyD->>+Execution Engine: Forward Transaction | ||
|
|
||
| Note over Sequencer: On a regular basis... | ||
| Sequencer->>Block Builder: Start Building <Attributes> |
There was a problem hiding this comment.
I am not sure what makes the most sense here with the particular flow to be honest, i naively thought that the block builder would ask the sequencer for the same info that the sequencer pushes to the EL when it tells it to build a block, then the block builder would push a block to the sequencer and the sequencer would then have a choice to seal either the local block or the block builders block
There was a problem hiding this comment.
Yeah, all sorts of sync/async push/pull permutations are possible for sure, and none of them are outright wrong. However, I think this particular arrangement is good and I justify it as:
Sequencer should Push Block Attributes to BBs because the sequencer has the most timely information regarding a new block needing to be built. If a Block Builder was expected to pull attributes from the Sequencer, it might accidentally do it too late, wasting time at the start of the block-period.
BBs should Push Payloads to the Sequencer because the sequencer should not add extra delay in the creation of blocks waiting for the BB. If the BB delivers a payload in time, great. If the BB is unperformant, it should not impact block production. This also gives the BB the opportunity to send out blocks iteratively, or to send the block early if it is done building. We could make this a pull from the sequencer instead, doing the call in a separate thread, and abandoning if the payload doesn't come back, but seeing as we have this nice Event-Driven Derivers architecture, I wanted the builder to be able to trigger an event workflow within the sequencer to consider the BB payload.
The "Notification of Deadline" message is a timing mechanism meant to help synchronize the BB and keep it from spending too long building, only to find that the sequencer has moved on.
We could totally consider other arrangements of these responsibilities, I would just want to consider what advantages they give us.
the sequencer would then have a choice to seal either the local block or the block builders block
This might be a gap on my understanding of block-sealing. It was my impression that the BB could seal blocks it creates, and therefore both the EE and BB would be sealing their own blocks. But now that you point it out, I bet that there's a signing authority thing that has to happen with blocks, and in that case: yes, we should rearrange this diagram somewhat. The BB and EE should both provide unsealed payloads to the Sequencer, and then the sequencer chooses which one gets sealed by the EE, and all other steps continue as normal.
|
It could be good to read + link the following doc: https://gov.optimism.io/t/optimism-pbs-proof-of-concept/6718 |
|
Closing in favor of #86 |
WIP