<center> <img src="https://hackmd.io/_uploads/H1-nlEtE2.png" width="350" height="300"> </center> [ToC] # PBS ECOSYSTEM R&D ![](https://hackmd.io/_uploads/HJ8iVeP52.png) . ## **Research** ### **Architecture** - **Ethereum L1** - **Protocol Designs** - **Enshrined Proposer-Builder Separations (ePBS)** - TODO summary: seperate the proposer and the builder - [ePBS-PTC: relay is replaced with in-protocol committee](https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054) - **Protocol-Enforced Proposer Commitments (PEPC)** - Original proposed [here](https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879), PEPC is an alternate version of in-protocol PBS (IP-PBS) wherein the proposer entirely gives up their right to create the block. This differs from the traditional MEV-boost model, where a proposer could lose an opportunity to create a block if a relay fails to publish on time. The post raises questions regarding the IP-PBS system's ability to handle scenarios like the advanced selling of block creation rights, arguing that this could undermine trust and encourage out-of-band agreements. The author concludes that rather than attempting to create a single, prescriptive mechanism, Ethereum might be better served by establishing a system for general "credible signaling" that allows for the possibility of new protocol duties that proposers could outsource in the future. Open Questions and Future Discussions: - How can we address the challenges associated with economic value for the proposer selling the rights to make their block in advance? - How can we design a system that effectively discourages out-of-band agreements and maintains the integrity of the IP-PBS system? - How can we prevent a potential increase in the discrepancy between what IP-PBS returns to an unsophisticated proposer and what trusted proposers can achieve? - Could Ethereum develop a mechanism for credible signaling that is not tied to one specific signal, to accommodate for future protocol duties which proposers may wish to outsource? - What would be the potential impacts on Ethereum's overall network security and liveness with the implementation of such a mechanism? - **Censorship Resistance** - **Inclusion Lists**: - The mechanics to enable inclusion lists in current PBS flows exists today, with perhaps the exception of fast arbitrary zkp's. The difficulties as eloquently stated in ["How much can we constrain builders without bringing back heavy burdens to proposers"](https://ethresear.ch/t/how-much-can-we-constrain-builders-without-bringing-back-heavy-burdens-to-proposers/13808) are: 1. Who computes the post state root - proposer, builder, or some third party ? 2. When are the transactions included - at time of commitment, or in the next block ? 3. Where does the inclusion list exist relative to execution payload - before or after ? - [Proposer suffixes](https://ethresear.ch/t/how-much-can-we-constrain-builders-without-bringing-back-heavy-burdens-to-proposers/13808) - [Forward Inclusion Lists](https://notes.ethereum.org/@fradamt/forward-inclusion-lists) <details open> <summary>Visual Representation</summary> <br> Proposer Provided Tx List ![](https://hackmd.io/_uploads/rkQJ6x-S3.png) Proposer Commitment w/ 3rd Party ![](https://hackmd.io/_uploads/S1j-6gbSn.png) </details> - The simplest approach would be: proposer adds a list to mev-boost registration for it's slot + transaction trie root. The builder who wins the auction will only be included if they provide a merkle proof of tx inclusion. So why dont we go with this approach? It's not incentive compatible for starters. A builder can chose to simply ignore a proposer if they are requiring an OFAC txn and not build on that block. This actually maybe isn't the worst because someone will offer the txn. But even worse, all of these designs expose surface area for MEV. A suffix inclusion list can get probabilistically sandwiched and same with a prefix. If the builder has full control over the transaction, they can also play ordering games. - Single Slot Finality (SSF) Dependency - Is single slot finality a dependency on in protocol PBS (ePBS)? Current take is no, but it goes back and forth. The existing Ethereum ledger, driven by LMD-GHOST, [was shown by Neu et al. to be insecure via balancing attacks](https://ethresear.ch/t/a-balancing-attack-on-gasper-the-current-candidate-for-eth2s-beacon-chain/8079). A subsequent mitigation technique, proposer boost, did not fully deliver dynamic availability. To address these issues,[ D’Amato et al. proposed Goldfish](https://arxiv.org/abs/2209.03255), a synchronous protocol providing safety and liveness under variable participation. It uses view-merge and vote expiry techniques but was deemed not practical for Ethereum due to vulnerability to temporary asynchrony. A solution, [RLMD-GHOST](https://arxiv.org/abs/2302.11326), was created to address these limitations. [Another simple single slot finality protocol](https://ethresear.ch/t/a-simple-single-slot-finality-protocol/14920) was created using (RLMD), [view-merge](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739), and [vote expiry](https://arxiv.org/abs/2209.03255). - Ethereum L2 Ecosystem - Sequencer Decentralization - Optimistic Rollups - ZK Rollups - [Aztec Request for Proposals: Decentralized Sequencer Selection](https://discourse.aztec.network/t/request-for-proposals-decentralized-sequencer-selection/350) - [B52 — PBS with a federated prover network](https://discourse.aztec.network/t/proposal-sequencer-selection-b52-pbs-with-a-federated-prover-network/351) - [Sequencer Selection: Fernet](https://discourse.aztec.network/t/proposal-sequencer-selection-fernet/533) - Shared Sequencing - Shared sequencer is a solution to two key problems introduced by rollups. These problems are potential monopoly pricing and censorship, due to relying on a single party for transaction ordering and inclusion, and fragmentation within the Ethereum ecosystem due to the development of multiple rollup solutions. A shared sequencer not only decentralizes the component of a rollup in charge of transaction ordering and inclusion but also is shared between rollups, thus addressing both issues. The shared sequencer benefits cross-rollup bridging and enhances security by mitigating systemic risks arising from bridges between independent consensus protocols. It also enables fair atomic transactions and complex cross-rollup atomicity. The shared sequencer combined with proposer-builder separation allows for greater interoperability and composability between rollups, potentially driving more activity to rollups that share the sequencer. - [Espresson Shared Sequencing: Defragmenting the L2 Rollup Ecosystem](https://hackmd.io/@EspressoSystems/SharedSequencing) - [Astria](https://blog.astria.org/introducing-astria/) - More? - Alternative Mempools - Privacy - TEE-based - [Block Building inside SGX](https://writings.flashbots.net/block-building-inside-sgx) - Threshold Encryption - [Threshold Decryption for Mempool Privacy in BFT networks](https://eprint.iacr.org/2022/898.pdf) - FHE - Account Abstraction - ERC4337 will create alternate “user operation” mempools, fragmenting public sources of MEV opportunities. OFAs will also most likely provide support for user operations. 2 new actors are added to the supply chain, “bundlers” and “paymasters”, both of which have functionality that may be subsumed by searchers, builders, and OFAs. - [4337 MEV Supply Chain](https://hackmd.io/pyIZdHG1RoCYAlK55fKbwA) - Proof Aggregation - Decentralized Block Building - Programmable Privacy - [Mev share: a protocol for programmable privacy to share mev with users](https://collective.flashbots.net/t/mev-share-programmably-private-orderflow-to-share-mev-with-users/1264) - Collaborative Building - [FRP 10: Distributed Blockbuilding Networks via Secure Knapsack Auctions](https://collective.flashbots.net/t/frp-10-distributed-blockbuilding-networks-via-secure-knapsack-auctions/1955) ### **Economics** - Auction Design - Dynamic Bidding (Status Quo) - Combinatorial Auction - Programmable Bids - MEV-time Oracle - [sxysun mevtime oracle](https://hackmd.io/@sxysun/suavespec#V-Solution) - Bundle Bids - Block Bids - Sealed Bid Auctions - 1st Price Sealed Bid - 2nd Price Sealed Bid (Vickery Auction) - Slot Auction - MEV Distribution - Protocol Discretion in Redistribution - ["Sybil-Proof rebates"](https://arxiv.org/abs/2306.17024) - MEV redisitribution in the presence of sybils is not incentive compatabile. This work explores rebates for liquidity provision of constant function market makers, with an approximate max-min operator and a maximum welfare operator introduced under specific conditions. Despite progress, the identification of Pareto-optimal operators, their efficient valuation, and the analysis of MEV-sharing in complex settings, including the study of cost-sharing Sybil-proof mechanisms, remain open challenges. - Protocol Security & Sustainability - Burn (Decrease supply) - [MEV Burn](https://ethresear.ch/t/mev-burn-a-simple-design/15590) - One key aspect of mev burn is that it removes a key incentive imcompatibility issue that allows malicious validators to write off the cost of equivocation. - MEV-Smoothing (Sharing between validators) - Retroactive Public Goods Funding - In-protocol (e.g. Tezos style) - [Retroactive Public Goods Optimism Style](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c) - Ex-protocol (e.g. Zcash style, Protocol Guild style) - [Protocol Guild](https://protocol-guild.readthedocs.io/en/latest/) - Market Dynamics in Redistribution - Bargaining Power across MEV ecosystem actors - Proposers - Executors (e.g. Builders, Searchers, Bundlers) - Users - Bargaining Power across Modular Stack - L1 vs. L2s: Where do most MEV activities take place? - Independent vs. Shared Sequencing: how large is cross-domain MEV? - [Unity is Strength: A Formalization of Cross-Domain Maximal Extractable Value](https://arxiv.org/abs/2112.01472) - - Based vs. Sequenced Rollups: Does L1 capture L2 MEV? - Decentralization - Market Competitiveness - Structural Measures - Concentration - [Measuring the Concentration of Control in Ethereum](https://docs.google.com/presentation/d/16DRyl_s_jnx34F9KbMFkFCfb4eXjLOg7gTWAJqkojps/mobilepresent?slide=id.p) - Concentration Ratios (CR) - Herfindahl-Hirschman Index (HHI) - Entry Barriers - Sunk Costs - Economies of Scale - Regulatory Barriers - Dynamic Measures - Entry and Exit Rates - Average Age of Firms - Volatility of Market Share - Performance Measures - Mark-ups - Profits - Firms Performance within Industries - Panzar-Rosse model (the H-statistic): transmission of input prices to firm’s revenues - Boone indicator: profit elasticity - Key Stakeholder Sentiment - Degree of Optionalities - Level of Switching - User Complaints - Confidence in the Market - Other Measures - Price - Productivity - Innovation - Vertical Integration - Builder-Proposer Integration - Builder-Searcher Integration - Geographical Decentralization - ["Decentralized crypto needs you: to be a geographical decentralization maxi"](https://collective.flashbots.net/t/decentralized-crypto-needs-you-to-be-a-geographical-decentralization-maxi/1385) - [Post on relay latencies](https://frontier.tech/optimistic-relays-and-where-to-find-them) ## **Development** ### **MEV-Boost Ecosystem** - MEV-Boost Software - OSS Maintainance - [Development Philosophy](https://collective.flashbots.net/t/mev-boost-development-philosophy/505) Primary development goals: - Stability, security and performance. - Safe and reliable upgrades for proposers. - Deliberate, considerate and calm (slow) development. - MEV-Boost Relay Software - OSS Maintainance - [mev-boost relay](https://github.com/flashbots/mev-boost-relay) - [dreamboat](https://github.com/blocknative/dreamboat) - Performance Optimization - [Optimistic Relay](https://github.com/michaelneuder/optimistic-relay-documentation/blob/main/proposal.md) - PBS Research Features - Censorship Resistance Improvement - Inclusion List ### **PBS Research Prototypes** - Ethereum L1 PBS - ePBS - Spec - EIP - Testnet - PEPC - Spec - EIP - Testnet - Ethereum L2 PBS ## **Operations** ### **MEV-Boost Ecosystem** - MEV-Boost Relay - Economic Sustainability of Relay Ops - Community Donation - Relay-Specific Grants - MEV-Boost Ecosystem Grants - PBS R&D Ecosystem Grants - Fees - Social Agreement (Relay Guild) - Performance-based Fees - Security Audits / Bounty Programs - Software Accessibility/UX Improvement - Geographical Distribution - Latency Game - [Post on relay latencies](https://frontier.tech/optimistic-relays-and-where-to-find-them) - Data Transparency Infrastructure - MEV-Boost Relay Monitor - [mevboost pics](https://mevboost.pics/) - [mevboost.org](https://www.mevboost.org/) - [relay monitor](https://hackmd.io/@ralexstokes/SynPJN_pq) - Censorship Detection - [Tornado warning](https://tornado-warning.info/) ### **Builder and Searcher Toolings** - [eigenphi](https://eigenphi.io/)