HackMD - Collaborative Markdown Knowledge Base

## 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   * 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! <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:   * $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