---
type: slide
slideOptions:
transition: slide
parallaxBackgroundImage: 'https://i.imgur.com/pvPDNWD.png'
parallaxBackgroundSize: '100% 100%'
parallaxBackgroundHorizontal: 0

---

## 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)" />

---

### Challenges

&nbsp;

* 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

&nbsp;

* 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

&nbsp;

* 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

&nbsp;

* 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:

&nbsp;

* <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...

&nbsp;

* 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!

&nbsp;

* 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?

&nbsp;

* 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?

&nbsp;

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