## Decentralizing the builder role --- ### General PBS idea: &nbsp; * **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? &nbsp; * 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? &nbsp; * 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"? &nbsp; * 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
{"type":"slide","slideOptions":{"transition":"slide","parallaxBackgroundImage":"https://i.imgur.com/pvPDNWD.png","parallaxBackgroundSize":"100% 100%","parallaxBackgroundHorizontal":0}}
    1236 views