OP Stack

arbitrum

there’s fast

then there’s 250ms fast

That is fast! We’re looking forward to bringing that type of speed to the Superchain

That is fast! We’re looking forward to bringing that type of speed to the Superchain https://writings.flashbots.net/introducing-rollup-boost

crypto

You can farm out transaction ordering to multiple people, and then re-assemble them as the sequencer to save time

You also can ensure they don't do anything fishy because they assemble the partial blocks in the TEE

Yo, had a discussion about this yesterday and wanted to confirm my understanding: https://warpcast.com/androidsixteen.eth/0xccdb540d

The lower latency is due to being able to stream “flash blocks” from builders with TEEs right?

And is that due to parallelizing block building, or some other reason?

While you likely do gain speed from outsourcing block building, the external block builders are less about lower latency and more about detecting sequencer equivocation. The TEE makes sure that the transaction ordering the sequencer posts on L1 is tamper evident from the point of view of the external block builders.

Here's a diagram to help illustrate this flow we're talking about. Red is the sequencer and green is the block builder separation.

Gotcha -- some follow-up questions (if you dont mind 🙏):

- who runs the sidecar and the builder-op-geth node? The builder entity?
- the green `builder-op-geth` square would be run in a TEE? Which enforces certain rules on block building that even the proposer (née sequencer) wouldn't be able to tamper with
- `4. validate block` -- why would the proposer need to validate the block if it was built in a TEE?
- What stops a proposer / sequencer from ignoring the output of the builder and just posting their own bundle regardless?
- What is the net benefit of the tamper resistance? If it's just reducing MEV taken by the proposer / sequencer, then why not just have the sequencer itself run a TEE... why the separation of entities here?