## Decentralizing the builder role
### 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
<img src="https://i.imgur.com/O4EXz3Z.png" style="filter:invert(1)" />
* 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
* 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!
<img src="https://i.imgur.com/UJrhdSL.png" style="filter:invert(1)" />
* 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:
* <span style="color:yellow"> $com(A) + com(B) = com(A + B)$ </span>
* Let <span style="color:yellow"> $Q_A$ </span> prove <span style="color:yellow"> $A(z)$ </span> and <span style="color:yellow"> $Q_B$ </span> prove <span style="color:yellow"> $B(z)$ </span>
* Then, <span style="color:yellow"> $cQ_A + dQ_B$ </span> proves <span style="color:yellow"> $(cA + dB)(z)$ </span>
* 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 <span style="color:yellow"> $R_1 ... R_h$ </span> and column commitments <span style="color:yellow"> $C_1 ... C_w$ </span>, where <span style="color:yellow"> $R_i(x_j) = C_j(x_i)$ </span>
* 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
* Slower adaptability