Optimism PBS proof of concept

Technical Proposals 📃
1

We are presenting an engineering solution (a GitHub PR with all the necessary changes), a proof-of-concept for an MEV-Boost enabled Optimism PBS model.

BedrockPBS
BedrockPBS1693×588 84.9 KB

6 Likes
2

Ethereum uses trusted relays and payload blinding mechanisms which are designed to prevent Proposers from stealing MEV. Since in Optimism the centralized sequencer is trusted by the network, no payload blinding mechanism is needed, reducing the latency resulting from the two stage approach (→ send header, ← sign header, → reveal payload).

PBS after sequencer decentralization

We suggest / assume a Proof of Governance selection of sequencers on the Optimism chain. Since each sequencer is selected and monitored by governance, we treat each of the sequencers as trusted in the context of PBS. Similarly to the case with a single centralized sequencer we suggest no use of relays leading to builders connecting directly to the sequencers.

BedrockDecentralizedPBS
BedrockDecentralizedPBS1372×644 105 KB

We suggest an idea of a sequencing policy / a sequencing mandate agreed on between the sequencer and the governing body. The policy may define censorship resistance mechanisms, L1 / L2 ordering rules, builders whitelists, etc.

5 Likes
3

We introduce some new names for the components:

  • BlockMarketAPI (instead of MEV-Boost)
  • Governed Sequencer (in place of Centralized Sequencer)
  • Relay Module (relay when running on the same infra as the sequencer)

OpRelayModuleOne

4 Likes
4

We treat relay as a module / component that is open to builders but running on the sequencer infrastructure (it makes sense when sequencers are permissioned parties with more responsibilities and more powerful infrastructure than in Ethereum case) - each sequencer maintains its own relay module:

OpRelayModuleMany
OpRelayModuleMany1075×411 32.1 KB

Since permissionless builders can send invalid blocks or make invalid claims about blocks profitability, the relay module needs to support a few correctness and DDoS protection mechanisms:

  • in case blocks are to be accepted from builders optimistically (without verification by the sequencer) - bonding similar to the one used in optimistic relays, described in more details here (link_limit://github.com/michaelneuder/optimistic-relay-documentation/blob/main/proposal.md).
  • in case when blocks are verified by the relay module - DDoS protection in the form of reputation queues - more information can be find here → Running Relay at Scale
4 Likes
5

Shared Sequencers support

We allow for some of the builders (or all of the builders) to be replaced by shared sequencers.

OpPbsWithSharedSequencer
OpPbsWithSharedSequencer839×735 36.8 KB

3 Likes
6

Similarly to the OP stack chains, on the Superchain level we also assume decentralization of sequencers (or shared sequencers) via Proof of Governance leading to a multilayer decentralized-by-governance set of sequencers with a separation of block building and block proposal.

BedrockPbsMultilevel
BedrockPbsMultilevel1542×1115 185 KB

Team

For any questions related to the PBS on L2s R&D please reach out to the team:

flashbots:

  • product management: Tomasz K. Stańczak
  • design review: Hasu, metachris
  • project management: Kailin Rutherford

Nethermind:

  • engineering: Jorge Mederos, Paweł Nowosielski
  • interns: Jake Kim, Jinsuk Park
  • architecture review: Swapnil Raj,
  • project management: Cameron Loo

Optimism:

  • tech guidance and review: Mark Tyneway
4 Likes
7

Hey @tkstanczak,

Appreciate your insights on distinguishing between OP stack-based chains and OP Mainnet within the Superchain vision (including for instance Base and Zora). To expand on that, as far as I’m aware, the idea of decentralizing the sequencer using proof of governance as leader election mechanism specifically applies to OP chains that integrate with the Superchain under the Law of Chains. This isn’t necessarily true for all OP stack-based chains.

Gotta ask some dumb questions here:

Considering that shared sequencers (e.g Espresso) are run by lightweight nodes performing primarily stateless operations (i.e., state ordering) and given that builders are sophisticated entities with significant hardware requirements. How can they effectively replace builders?

Used to have that mental model when thinking about PBS for L2s: perceiving shared sequencer as shared proposer and let’s say SUAVE as shared builder :upside_down_face:

On a general note, agree that PBS will be essential, specially to prevent the negative externalities that happened during Ethereum’s pre-PBS days, such as :

  • Failed transactions
  • Lower proposer revenue
  • Priority gas auctions
  • Sandwich attacks

It’s crucial to learn from it to avoid these issues from reoccurring. Clearly defining the roles of builders and proposers can:

  • Boost protocol revenue
  • Reduce negative repercussions for the network and the users.
2 Likes