Proposer-Builder Separation from the protocol's perspective

Barnabé Monnot

Robust Incentives Group, Ethereum Foundation

Columbia Cryptoeconomics workshop — Columbia University

Today’s plan

1. Block construction in Ethereum

2. Proposer-Builder Separation …

a. … in practice

b. … in theory

3. PBS and everything else

Block construction in Ethereum

Section 1

What a blockchain is

Blockchain = data structure, chain of blocks

Blocks contain:

• Consensus data (e.g., hash of previous block)
• Executable transactions

Consensus layer

Execution layer

hash(A)

hash(B)

A

B

C

Block construction in Proof-of-Stake Ethereum

Validators deposit 32 ETH in the staking contract,� get activated to participate in consensus formation

Every 12 seconds, new opportunity to make block, containing:

• Votes from previous committee(s)
• Execution payload, containing transactions

Execution Engine

Users

Consensus client

Transactions

Execution payload

Block proposer is free to make the execution payload however they like� No inclusion or ordering consensus, only one inclusion constraint:� All transactions must pay the prevailing EIP-1559 basefee

Order transactions in decreasing order of gas price is ~incentive-compatible� “First spot” in block has great value (capture arbitrage, react to market)� => Induce higher value payments to proposer

Daian, Philip, et al. "Flash boys 2.0: Frontrunning, transaction reordering, and consensus instability in decentralized exchanges." arXiv preprint arXiv:1904.05234 (2019).

Ordering matters!

There is value to acting upon some state of the world on-chain� Proposer controls the state transition, best-placed to realise this value!

v(s) = Value of transaction executed on state s

Example:

• v({ arbitrage exists }) = 1,000,000
• v({ arbitrage is gone }) = 0

Whoever attempts to capture arbitrage is willing to spend up to 1,000,000

PBS in practice

Section 2

Block construction in Proof-of-Work

“Top-of-block” state has value, but PGAs are inefficient.� Let searchers bid for bundle inclusion at top-of-block

Private auction between block proposers and searchers� Searchers trust proposers to not “bundle theft”

Searchers

Execution Engine

Consensus client

Users

Transactions

Bundles

Block construction in Proof-of-Stake

In PoS, trusted relationship doesn’t work, solo validators in the system� Can’t send bundles “in the clear” to everyone…

Idea: Validators receive full blocks from builders

Searchers

Execution Engine

Users

Builders

Blocks

Consensus client

mev-boost

Out-of-protocol solution for external block-building: mev-boost� Proposer commits to using a builder block without seeing the contents

Relays broker the relationship

• Validate block contents (transaction validity + declared bid)
• Forward bids to proposers
• Reveal block once proposer commitment is obtained

Block construction with mev-boost

Execution Engine

Consensus client

Users

PBS in theory

Section 3

MEV trickle down (J. Charbonneau)

Block-building tomorrow? (In-protocol PBS)

Execution Engine

Consensus client

Users

PBS

Searchers

Builders

An allocation mechanism

What does the proposer outsource exactly?

What is the space of contracts the protocol imposes to proposers?

Many ways to do PBS!

Asymmetry between cost of block construction and block verification

Cost of block construction is potentially high (in resources, or expertise), but one-shot

Cost of block verification remains low

Proposer-Builder Separation:�The proposer outsources block construction to third-parties

​

A market structure

“Proposer-Builder Separation” separation

Allocation mechanism

Whole block auction: The proposer sells off their entire rights to make a block.

Proposer selects bid they would like to use.

Protocol is the “broker”

• Builder bids are binding, whether they deliver a valid good or not
• Valid good: Valid block made by selected builder

Consequences:

• Remove relays from the system
• Guaranteed payments for the proposer

Market structure

“In-protocol” PBS

Allocation mechanism

Slot auction: The proposer sells off the right to make a block, but the bid doesn’t commit the builder to any specific block.

Proposer selects bid they would like to use.

Selected builder can release any block they want.

Protocol is the “broker”

• Builder bids are binding, whether they deliver a valid good or not
• Valid good: Valid block made by selected builder

Market structure

“In-protocol” slot auction

PBS and the principal-agent problem

Outsourcing block construction means proposer’s preferences may not be satisfied by the builder…� We have a principal-agent problem

Strength of the decentralised validator set: censorship-resistance� But builder network is centralised, and best builder may be censoring…

Idea: Let proposer inject some input into block construction

• Inclusion lists: Builder must include some txs, or produce full block
• Partial blocks: Proposer makes part of the block, builder fills the rest

PBS and everything else

Section 4

Builders for data availability

Making big blocks is costly: Need powerful machines, high bandwidth etc.� Verifying big blocks fully is also costly

But what if partial verification is enough? Sharding!� Especially true for data availability sampling => Danksharding!

Then builder can make the big block,� while the network verifies data availability piecewise

See Dankrad’s talk!

Incentive-compatibility of PBS

Is PBS bid an objective oracle of block value to proposer?�Proposer runs an auction, is it a credible auction?�Possible to enter into off-chain agreements, no side-contract-proofness� Bid less at the protocol auction, enter into side-contract…

EIP-1559 / transaction fee mechanisms have looked at such properties� + (Im)possibility results

See Elaine’s talk!

PBS from the user’s perspective

Protocol PBS is an optimiser for proposer value� Not always to the user’s benefit! e.g., sandwiches, failed trades etc.

User originates proposer extractable value… why can’t they capture it?� (or at least protect themselves)

We have cryptography + ways to make credible commitments + game warping

See Phil’s talk!

Thank you!

Barnabé Monnot

Robust Incentives Group (RIG), Ethereum Foundation

barnabe@ethereum.org

@barnabemonnot