Try   HackMD
Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

PBS ECOSYSTEM R&D


.

Research

Architecture

  • Ethereum L1

    • Protocol Designs

      • Enshrined Proposer-Builder Separations (ePBS)

      • Protocol-Enforced Proposer Commitments (PEPC)

        • Original proposed here, 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" 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

        • Forward Inclusion Lists

          Visual Representation
          Proposer Provided Tx List

          Proposer Commitment w/ 3rd Party

          - 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. A subsequent mitigation technique, proposer boost, did not fully deliver dynamic availability. To address these issues, D’Amato et al. proposed Goldfish, 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, was created to address these limitations. Another simple single slot finality protocol was created using (RLMD), view-merge, and vote expiry.

  • Ethereum L2 Ecosystem

    • Sequencer Decentralization

    • 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
      • Astria
      • More?

  • Alternative Mempools

    • Privacy

    • 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

    • Proof Aggregation

  • Decentralized Block Building

Economics

  • Auction Design

    • Dynamic Bidding (Status Quo)

    • Sealed Bid Auctions

      • 1st Price Sealed Bid
      • 2nd Price Sealed Bid (Vickery Auction)
      • Slot Auction

  • MEV Distribution

    • Protocol Discretion in Redistribution

      • "Sybil-Proof rebates" - 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
          • 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

    • Market Dynamics in Redistribution

      • Bargaining Power across MEV ecosystem actors

        • Proposers
        • Executors (e.g. Builders, Searchers, Bundlers)
        • Users

      • Bargaining Power across Modular Stack

  • Decentralization

    • Market Competitiveness

      • Structural Measures

        • Concentration

        • 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

Development

MEV-Boost Ecosystem

  • MEV-Boost Software

    • OSS Maintainance
      - Development Philosophy

      Primary development goals:

      • Stability, security and performance.
      • Safe and reliable upgrades for proposers.
      • Deliberate, considerate and calm (slow) development.

  • MEV-Boost Relay Software

  • 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

  • Data Transparency Infrastructure

Builder and Searcher Toolings

Last changed by 
 
dmarz
7
263

Read more

Constraints API First Pass Comments

a preconfirmation is not defined

Feb 13, 2025
Ethereum Block Building Workload

\begin{align*}& \text{Block Creation Complexity} = \& O(n \cdot k \cdot h + n \cdot s + n \log n) \[2em]

Oct 29, 2024
Subverting the total eclipse (of the heart)

cowritten by Dan Marzec and Louis Thibault

Oct 1, 2024
OSS Developent Coordination Exploration

Upon starting this note, I was hoping to answer two basic questions.

Jun 1, 2024
Read more from dmarz
Published on HackMD