parallaxBackgroundSize: '100% 100%'
# In-protocol PBS
* Why PBS?
* What kind of PBS?
* How to improve PBS?
## Why PBS?
* Literal meaning: any value that the block proposer can extract (incl priority fees)
* De-facto meaning: value that requires sophisticated algorithms (optimized TX selection, DEX arbitrage, claiming on-chain bounties...)
* Result is economies of scale in block construction
Economies of scale risk creating incentives for centralization.
PBS separates "being a validator" into two roles:
<li style="color:#ffff88"> A low-economies-of-scale "boring" notary function</li>
<li style="color:#ff8888"> A high-economies-of-scale block construction role
Goal: allow the block construction role to become more centralized (it's okay if one actor chooses > 50% of all block contents!), to preserve decentralization of the critical consensus layer.
## What kind of PBS?
PBS is structured as an _auction_:
* Each block builder makes a _bid_ for the next slot
* The block proposer chooses the highest bid
* The block builder publishes the corresponding block
Key properties we must preserve:
* Builder can't cheat proposers
* eg. builder can't refuse to publish and deny the proposer their revenue
* Proposer can't cheat builders
* eg. proposer can't look at the builder's block and replace it with their own block "stealing" the builder's strategy
MEV Boost (depends on trusted relayers)
Do builders have to pre-commit to block contents?
* Advantage if yes:
* Builder profits are deterministic and guaranteed, making it easier to participate
* Advantages if no:
* More compatible with cross-domain MEV systems
* Winning builders could offfer pre-confirmation services
## How to improve PBS?
Censorship in PBS is still expensive. But it's much less expensive than censorship today.
Idea 1: secondary blocks
* Proposers can select "auxiliary blocks" which contain transactions censored by the main block
* Transactions now have many parallel opportunities to get included. Censors have to outbid the transactor many times
Idea 2: crLists
* Proposers can create lists of transactions, which the builder must include unless the block is too full to include all of them
Internally decentralized builders
* Builders can decentralize internally, accepting "bundles" from an open market of "searchers"
* Key challenge: preventing builders (and other searchers) from cheating searchers
* Solution path: searcher bundles encrypted until block is "locked in"
* Challenge: requires either a trusted builder, SGX or fast ZK-EVM
* Agree on the in-protocol PBS design (may depend on single-slot finality!)
* Maximally solve censorship resistance
* Make it easier to build market-winning internally-decentralized builders
* More exploration into cross-domain MEV