One of the fundamental problems of Proposer Builder separation is the centralized role played by the Builder. This creates 3 tradeoffs (possibly more):

• Regulatory choke-point

• Builder consolidation

• Vertical integration of supply chain

Proposal

Can we conceive of a decentralized block builder?

Conjecture: considering Near’s Nightshade design, loosely, for inspiration we can conceive of a decentralized builder design where multiple builders compete to propose a chunk or a portion of the execution block.

Inspiration - Near Nightshade (2019 White Paper)

Design

In this proposal there would be four distinct auctions, 3 competitive and 1 non-competitive. The Auctions could be run sequentially, metered by time. For instance auction n lasts x seconds. The MEV competitive auctions include both bundles and mega bundles. The target gas limit of these three auctions in total is 15M gas, 5M each. The fourth auction is the censorship resistance list. The crList target gas is 0M gas. The MEV competitive auctions have a max gas limit of 10M each. If all three auctions reached the 10M gas limit, the crList auction would not submit a bid chunk and begin again the following block.

The Sharded Builder - Hypothetical Ethereum with PBS

• Builders can only compete in 1 MEV competitive auction per execution block

• 1 auction is exclusively for Mega bundles capped by auction gas limit

• Proposer selects highest chunk bid for each auction.

• Winning chunk headers are aggregated by proposer to create singular block header

• Sequential auctions mitigate risk of overlapping txs or requiring state access lists

Conclusion

The proposed sharded block builder design creates a highly decentralized and competitive builder market. In addition, builder competition ensures exclusive order flow does not lock into a handful of centralized builders. This is because of the proposed limitation on the number of auctions a single builder can compete in per block. Time based auctions keep top of the block opportunities competitive and reduce the risk of builders holding blocks until more order flow is revealed. crList chunks have the opportunity to be included in every block. Exclusion occurs only if the MEV competitive auctions reach their max gas limits respectively.

Open Questions

• New DOS attack vectors?

• Can proposal be implemented as middle-wear or does it require both execution and consensus client upgrades?

• How will this affect Danksharding? If full Danksharding is not possible with a sharded builder, does the community pivot to PDS (EIP 4844) then done?

• How will this affect stateless client implementation? Will chunks require additional witness data to verify?

• Is additional validator overhead (chunk header aggregation) cost neutral?

• Compatible with single slot PBS or two slot PBS?