General PBS idea:

• Builders are highly specialized actors that construct candidate blocks and make bids to get them included
• Proposers are validators that naively accept the highest bid
• Goal: builders absorb economies of scale, proposers stay decentralized

Why decentralize builders?

• Even though this may greatly improve validator decentralization, it risks leaving builders very centralized
• One builder may well produce >50% or even >90% of all blocks
• We can mitigate the consequences of this with transaction inclusion lists, but it's still not a very nice thing.
• Could we make the winning builder itself decentralized?

What to decentralize?

• Algorithms for choosing transactions
• Resources for block construction (particularly in full danksharding)
• Mechanisms for providing "extra builder services" (eg. pre-confirmations)

What do we mean by "could"?

• Technical feasibility
• Would a decentralized builder be a market-winning actor?

Algorithms for choosing transactions

Builder / searcher architecture

Challenges

• How to protect searchers from MEV stealing?
• How to allow the aggregator mechanism to combine searcher inputs?
• How to ensure that the aggregator mechanism can actually publish the block (without assuming searcher honesty)
• How to protect searchers against aggregator + proposer collusion? (!!)

Idea 1: trusted hardware

• Searchers send bundles encrypted to TPM key
• Aggregator runs merge algorithm inside TPM
• TPM unlocks decryption upon seeing proposer signature plus proof of availability
  • Attesters (requires properties of ETH protocol)
  • M-of-N assumption within the aggregator
  • Low-security real-time DA oracle (chainlink? 😛)

Idea 2: merge disjoint bundles

• Searchers send bundles encrypted to threshold key, along with access lists, and a ZK-SNARK of correctness
• Aggregator chooses globally total-bid-maximizing disjoint set of bundles
• When to compute state root?
  • One aggregator node decrypts then computes -> can collude with proposer
  • Compute after proposer agrees - requires eigenlayer technique or protocol change

Block construction post-danksharding

Challenges

• A full block is 16 MB, and likely more in the future
• Publishing the block requires publishing across a huge number of subnets
• We want to avoid requiring a single node to do all this

Distributed erasure coding!

• Whoever includes each data tx is responsible for encoding it and propagating the blobs
• Aggregator can use real-time DA oracle
• Network can fill in the columns

"Filling in the columns" can be done with KZG math:

• \(com(A) + com(B) = com(A + B)\)
• Let \(Q_A\) prove \(A(z)\) and \(Q_B\) prove \(B(z)\)
• Then, \(cQ_A + dQ_B\) proves \((cA + dB)(z)\)
• Because of this linearity, proofs for existing rows can be combined into proofs for missing rows

In a non-KZG setting…

• Builder must provide row commitments \(R_1 ... R_h\) and column commitments \(C_1 ... C_w\) , where \(R_i(x_j) = C_j(x_i)\)
• And a proof that the commitments are equivalent
• This can be done distributed, but requires a 2+ round protocol

Extra builder services

Builders can provide pre-confirmations!

• Builder publicly agrees that if user sends tx with prio fee >= 5, builder will immediately send an (enforceable) message agreeing to include it
  • If prio fee >= 8, the user gets a post-state root
• This can be done either with builder reputation, or with a third-party DA oracle

Can a distributed builder do this?

• Yes! Just run tendermint internally
• Final signing is done threshold style
• Penalize builders for:
  • Double-finality in the tendermint
  • Contributing to a final signature that is incompatible with the tendermint
  • This requires abstracted final signing for max security, as threshold BLS is unattributable
• The more participants, the more security!

So, can a distributed builder be economically viable?

• Competitive advantages:
  • More easily trusted by searchers
  • Censorship resistance
  • Huge security deposits behind the pre-confirmation service
• Weaknesses:
  • Latency
  • Slower adaptability