PBS Guild Proposal [v3 WIP]
tldr: PBS Guild is a non-commercial ecosystem R&D funding vehicle with decentralization as its mandate. It is proposed as a memberless foundation incorporated in the Cayman Islands governed by independent non-executive directors and a grants council.
PBS Guild funds will primarily come from community donations from key beneficiaries of the PBS ecosystem and will be used to support neutral relays and R&D proposals. Phase 1 of PBS Guild will target 1m in commitments to cover grants and operations for the initial 6 months.
PBS Guild is jointly proposed by the mev-boost community. Thanks to the helpful feedback and comments and the inspiring research work shared at PBS.salon and PBS.day in Paris: Alex Stokes, Butta, Chris Hager, Hasu, Hudson Jameson, James Parillo, Jon Charbonneau, Justin Drake, Ken Ng, KuDeTa, Matt Cutler, Max Wilde, Mike Neuder, Praneeth Srikanti, Quintus Kilbourn, Robert Drost, Robert Miller, Sarah Allen, Simon Brown, Terence Tsao, Tim Beiko, Tomasz Stanczak, Trento Van Epps, Yaz Khoury, Viktor Bunin, Vitalik, and to everyone who joined in the co-curation of the PBS ecosystem R&D map during EthCC Paris.
I. Motivation
PBS in Ethereum R&D
Proposer-builder separation (PBS) is a protocol design philosophy emphasizing the relationship between protocol and non-protocol actors for the maintenance and operation of a blockchain. It was first put forth in Vitalik’s 2021 ethresear.ch post: Proposer/block builder separation-friendly fee market designs, as a market structure design that leverages the power of specialization to mitigate the centralizing pressure on the validator set from MEV by enabling the block construction process to be outsourced to highly specialized non-protocol actors.
PBS is an important module on the Ethereum roadmap, with a large design space. Here is a roadmap delineating the potential paths of PBS R&D at this stage.
Note: from PBS.day presentation Co-creating the PBS Ecosystem R&D Treasure Map (slides) by TINA.
The Role of PBS in Ethereum Decentralization
The current state of decentralization (slides) has a few key issues including geographical concentration, client diversity issues, rollup centralization, and stablecoins, as Consensys researcher Simon Brown shared in an analysis at PBS.salon. MEV-Boost’s success has largely prevented the centralizing forces of MEV from eroding the decentralization of the validator set.
Note: chart from Simon Brown’s talk in Jul 2023 Measuring the Concentration of Control in Ethereum.
Note: screenshot taken from Project Sunshine (ethsunshine.com) in Aug 2023.
PBS Ecosystem Market Competitiveness Since The Merge
So, where are today’s actors within the PBS ecosystem along the axis of decentralization?
Here is a visualization of the market dynamics from MEVBoost.pics on relays, block builders, and validators since the Merge.
- Block Builders: the total number of block builders has grown to 30+, with the top 5 builders building over 80% of the Ethereum blocks.
- MEV-Boost relays: there are 11 relays operated by 9 teams, with at least 2 more announced entering the race starting August 2023 that are not yet operational.
- Validators: there are currently 713,632 active validators, with an entrance queue of over 71,000.
MEV-Boost Relay Ecosystem Dynamics
Block Builder Ecosystem Dynamics
In his paper, Measuring the Concentration of Control in Contemporary Ethereum Simon Brown presented analysis of market concentration and competitiveness in the nascent PBS ecosystem. Overall, the relay ecosystem is more concentrated compared to the block builders ecosystem, yet there is still significant competition especially within the block builder ecosystem.
Herfindahl-Hirschman Index (HHI)
- Dots: blocks by MEV-Boost relays;
- Triangles: blocks by block builders.
Note: Figure 7 in Measuring the Concentration of Control in Contemporary Ethereum (Draft).
Jensen-Shannon Divergence (JSD)
Blocks by Builders’ JSD indicates winning builders change radically during 24h range.
Note: Diagram from Measuring the Concentration of Control in Contemporary Ethereum (Draft).
Putting These All Together…
Here is a highly subjective attempt at mapping this out using Vitalik’s framework in his 2017 The Meaning of Decentralization:
Note: decentralization spectrum is a highly subjective view, silicon valley AI ecosystem is placed on the chart as an extra reference point for calibration of mental models 
Architectural (de)centralization — how many physical computers is a system made up of? How many of those computers can it tolerate breaking down at any single time?
Political (de)centralization — how many individuals or organizations ultimately control the computers that the system is made up of?Logical (de)centralization— does the interface and data structures that the system presents and maintains look more like a single monolithic object, or an amorphous swarm? One simple heuristic is: if you cut the system in half, including both providers and users, will both halves continue to fully operate as independent units?
The block builder ecosystems today are logically decentralized, but the significant players within the 30+ builders clustered around a few geographical regions are architecturally centralized and politically half-decentralized.
The Risks of Vertical Integration
The purpose of PBS is to prevent centralization pressure on the validator set and relays from colluding with or integrating with other actors. Here is a thorough forum thread on the risks of the Vertical Integration of MEV-Boost:
Scenario #1: Builder-Relay
The block builder and relay are run by the same party. In general, there is an information advantage here as long as other builders are sending their blocks to the relay.
If the party is acting maliciously, the biggest risk is that the relay communicates information about competing blocks and bundles back to the builder, which then uses this knowledge to front-run other builders.
Malicious Party
Case 1
Bundles are sent to a single builder that uses a single relay, both are controlled by the same entity
Is it possible for the party to front-run other builders? Pre-PBS, this seemed to be possible, as the Builder API 2 allowed validators to make a request to the relay when they were ready to receive a block for a particular slot. It’s possible that the malicious relay can accept blocks from other parties, and then make their own blocks that front-run these.
How likely is this to happen in practice? In this scenario, it would be easy to detect if the competing builders had some exclusive orderflow that the relay-builder shouldn’t know about. This would likely lead to the relay being blacklisted after a short time. If this is done with only public transactions, it is less clear how this could be mitigated.
Case 2
Bundles are sent to multiple builders, which then send blocks to multiple relays. Some of these builders and relays are controlled by one party.
The same malicious behaviour as in Case 1 is possible, however now it is much more difficult to detect and blacklist a malicious relay.
Honest Party
If the builder and relay are operated together by an honest party, there are still some advantages and issues here that do not require them to behave badly.
If the builder and relay are operated by the same party, they could be co-located, so that this builder’s blocks consistently reach its own relay faster than blocks from other builders.
This scenario is particularly important to pay attention to because it is the one that Flashbots is proposing to run.
Scenario #2: Builder-Proposer
The builder and proposer are run by the same party, relay is independent. Under PoS without PBS, it is a normal and expected scenario that the block building and proposal functions will both be performed by the validator, as the validators are expected to build their own blocks and then propose them to the network. However, issues arise when the proposer is also running a mev-boost style block builder.
Case 1
Proposer owns the current slot and also owns a block builder
The proposer could bypass mev-boost, and just get blocks directly from their own builder. This may be economically sub-optimal, but may have other advantages such as allowing them to have private deals with others looking for inclusion guarantees, or promotional deals in order to gain customers.
Even if the proposer does not bypass mev-boost, the builder can game the auction by just bidding the maximum amount possible to the proposer so that their block is guaranteed to be picked. It doesn’t matter how much they bid as both are controlled by one party.
Case 2
Proposer does not own the current slot
If the proposer does not have the current slot, this should not be an issue. However, we are aware of players that have a lot of stake in the system, so that they propose blocks regularly. Is mev-boost economically the right choice for them, versus running their own builder?
Scenario #3: Relay-Proposer
In this scenario, the validator that has been chosen to propose a block and the relay are both run by the same party.
If the party is malicious, the relay could send full blocks to this proposer. The proposer is then able to see, censor, and steal transactions from other parties. Builders who submit their blocks to this relay could also be front-run.
- If relay start charging fees, this will push builders - relays - validators to integrate.
- if done in-protocol, it can be bypassed easily
- If out of protocol via a cartel, will push rational actors to vertically integrate.
How do we prevent it from getting worse before getting better?
As of today, 3 out of 7 active relay operators are operating independent relays, not vertically integrated with other parts of the MEV supply chain (eg. running builders, searchers, validators).
The latency game amongst block builders is pushing block builders towards co-locating with relays, or considering running relays themselves. Co-location between relays and block builders will further increase geographical centralization, whereas direct vertical integration, breaks the guarantee of PBS. If unchecked, can tip the scale and go into a downward spiral toward centralization, due to the superlinear return on capital and scale economy of MEV.
Can we do something to contribute to the PBS ecosystem?
This begs the question of: how much longer do we need to fend off the vertical integration pressure while waiting for in-protocol PBS? Can we as a community contribute towards PBS R&D? Can we support independent relays economically without accelerating the vertical integration within the MEV-Boost ecosystem?
II. What is PBS Guild?
PBS Guild is a non-commercial ecosystem R&D funding vehicle with decentralization as its mandate. At its core, it’s bringing together a proactively contribute to the present and future research, development, and operations of PBS on Ethereum (MEV-Boost protocol today, and enshrined PBS the future), as well as the Ethereum L2 to protect the decentralization of all actors within the Ethereum ecosystem.
Since the Merge, in-protocol PBS research had been primarily spearheaded by the Ethereum Foundation researchers thus far, while the development of today’s interim out-of-protocol PBS - MEV-Boost had been a shared responsibility across the MEV-Boost core maintainers as well as the growing set of MEV-Boost relay operators.
At its inception, PBS Guild is about surfacing the most pressing issues with those who are already doing the most relevant work out of silos, by co-creating an ecosystem R&D map for legibility, accountability, and collaboration. We aim to invite the broader community from the MEV space and the academia, who are interested in digging deep into the highly context-specific realm of protocol R&D, and contribute to working in the open.
With this introduction to the high-level structure and aims of the PBS Guild, the rest of this Section dives into some of the thorniest challenges around PBS. First with a deep dive on Relays, then a nod to L2 PBS, and finally a crowd-sourced PBS R&D ecosystem map co-curated by researchers who attended PBS.salon.
1. Current Challenges in Ethereum PBS R&D
The Choke Point of MEV-Boost Design: Relays
The wide adoption of MEV-Boost based on the Builder-API spec post-Merge was an important early step for PBS, as an interim out-of-protocol PBS design that inherited the trust assumption from the Flashbots auctions from POW days. It functions primarily via a commit-reveal scheme between the block builders and the block proposers.
However, MEV-Boost’s functioning requires the role of MEV-Boost relays, trusted by the block builders to not steal MEV, and by the block proposers to provide a valid block header and to publish the full beacon block.
Note: chart taken from Mike Neuder’s PBS.day talk (slides).
The relays are currently the choke point of Ethereum block production: being operated by a handful of centralized entities, which have the power to censoring transactions, as well as the ability to profit from stealing MEV.
Despite its flaws, MEV-Boost has been widely adopted by the majority of validators, responsible for 90%+ of blocks produced since the Merge, and 40% of validator revenue .
The Pain Point of MEV-Boost Operations: Relay Economics
Currently, within the MEV-Boost ecosystem, relays are unaccounted for as an economic actor, despite providing a critical service for the builders and validators. Initially designed as a stop-gap solution, relays are now considered public goods to be run by trusted entities until ePBS R&D catches up.
During PBS.salon in Jul 2023, a piece of under-explained information was shared in PBS.salon that relays will still play a role in the ePBS world in edge cases, caused shock wave amongst the community and relay operators:
- Community: Questions around the direction and viability of PBS, as well as concern over relay entrenchment against Ethereum decentralization.
- Relay operators: Urgency to resolve MEV-Boost relay economic sustainability by rushing to underdeveloped economic experiments that either rely on collective bargaining with validators or an in-protocol fee mechanism.
The fears around that relays will still playing a dominant role post ePBS and questions around PBS subsided as Mike Neuder presented the latest PBS R&D Roadmap and the design tradeoffs within the next few years (slides) on PBS.day , followed by a blog post addressing Relays in a Post e-PBS world. Mike explained that it is most likely that relays post ePBS will play a much-diminished role as ePBS become the reliable automatic in-protocol relayer. Out of protocol relayers will likely be relegated to edge conditions such as EOB payments in high-value blocks and to enable HFT-capable builder bid cancellations during high price volatility periods.
For the relay operators, the question remains: “how do we sustainably fund relays for the next 2-4 years [and maybe longer]. The future utility of relays in a post ePBS world [timeline tbd, but year-years], at least in-part hinges on relative latency advantages (we’re back to the latency game). Or as Mike Neuder puts it: “Hopefully, the value difference between the P2P bid and the relay bid will be small enough that a larger percentage of validators choose to follow the honest behaviour of using the P2P layer to source their blocks (i.e., altruism is less expensive).”
Most of the major relay operators have come to a working group proactively to propose and discuss out-of-protocol or in-protocol (as in MEV-Boost) methods to incentivize relay operations. There have been 4 methods proposed:
- Market competition: Individual relays charge performance-based fees in the market.
- Public goods funding: Relays collectively or individually seek public goods funding from the MEV community.
- Relay collective that experiment with out-of-protocol fees: collectively bargain with validators to take a cut from validator’s MEV revenue, and pools risk and sell slot insurance.
- MEV-Boost in-protocol economic mechanism: proposes MEV-Boost in-protocol changes to enable payment to relays across all validators.
None of these funding methods is perfect. The first push relies on a centralizing latency-centric and co-location game and further crowds out independent relays that do not have ways to charge fees in a competitive market. The second source of funding is ad hoc, tend to be unreliable, and relatively small in size. The third approach relies on an unstable coalition of relays charging the same fees based on collective bargaining power, which can easily dissolve if any relay defects from the coalition and new relays pop up charging lower or no fees. It may also lead to additional legal risk on the individual relays, as well as threatens the base layer neutrality of Ethereum. Both the third and the fourth approaches can lead to the fracturing of the ecosystem while accelerating builder-relay vertical integration - what PBS design explicitly aims to prevent.
PBS R&D: In-Protocol PBS Designs (Two-slot PBS, PTC & PEPC)
There have been a number of non-mutually exclusive PBS proposals put forth by the EF researchers. These are some of the top-down designs put forth (full list of proposals here):
- Two-slot proposer/builder separation -Vitalik, 2021
- Unbundling PBS: Towards protocol-enforced proposer commitments (PEPC) -Barnabe, 2022
- PEPC FAQ - Barnebe, 2023
- Payload Timeliness Committee (PTC) - Mike Neuder & Francesco, 2023
Design Trade-offs
Note: from Mike Neuder’s PBS.day talk (slides).
How do they relate?
Note: from Mike Neuder’s PBS.salon talk(slides).
There is also an out-of-protocol, iterative approach from MEV-Boost to ePBS: Optimistic Relaying defined in Why enshrine Proposer-Builder Separation? A viable path to ePBS.
Removing relay responsibilities
Note: from Mike Neuder’s PBS.day talk (slides)
Optimistic relaying end game
Note: from Mike Neuder’s PBS.day talk (slides)
There are still plenty of open research and development questions (see PBS wiki) that remain for the various ePBS designs and how they may interoperate with the rest of the modules on the Ethereum roadmap, as well as the paths to implementation.
Uncharted Water in L2 PBS Research & Experimentation
In 2023, multiple L2s started to seek proposals to decentralize their sequencers. There are plenty of questions and not enough answers as to how PBS design philosophy applies to the various flavors of rollups within their respective architecture, as well as across L2 ecosystem. See Georgios K’s PBS.day talk (slides) for open R&D questions for the L2 researchers, as well as proposals and presentations by researchers from L2 and shared sequencers (see PBS.day).
3. Scope of PBS Guild R&D Funding
Here is a list of research questions to start out PBS wiki. There will be a grants application process inviting experienced researchers and PBS core contributors to work on specific R&D questions.
- Research: architecture work and privacy research, economic mechanism design audit (similar to the EIP-1559 report), etc.
Note: this is a mindmap co-curated by PBS.salon attendees, outlining some potential areas of involvement, reference only for scope illustration only.
- Development: while MEV-Boost development had stabilized, there are changes such as around 4844, along with much more open-ended experimentation, there is ePBS research and prototyping ahead, and work with a more open-ended nature such as moving validator registration on-chain (note), support cross-client diversity, proposer-payment standardization. etc. (see Alex Stokes’ PBS.salon slides).
Note: this is a mindmap co-curated by PBS.salon attendees, outlining some potential areas of involvement, reference only for scope illustration only.
- Operations: within the MEV-Boost ecosystem, MEV-Boost Relay economic sustainability is the main issue, and multiple proposals had been proposed by the current set of relay operators in the Relay Funding Working Group.
Note: this is a mindmap co-curated by PBS.salon attendees, outlining some potential areas of involvement, reference only for scope illustration only.
III. How does it work?
Operations
PBS Guild operations will necessitate a legal entity for legal and tax compliance for both entities receiving funds and those making donations. A best practice for initiatives such as PBS Guild is to establish a memberless foundation in the Cayman Islands. A memberless foundation is typically administered by non-executive directors and governed by a member-led governance function, such as a grants council.
Timeline
- Preparation Phase (0-1 months):
- Designate a Pilot Phase grants committee (3 or 5 members) and define Pilot Phase funding objectives;
- Start raising Pilot Phase funding round (target threshold: minimum $1mn).
- Pilot Phase (1-6 months):
- Select 1 independent non-executive director & 1 supervisor, and establish a Cayman Memberless Foundation;
- The director will appoint the grants committee members as the Council of Cayman Foundation and as the multi-sig signer;
- Announce PBS Guild (target date Sep 14, 1-year anniversary of the Merge);
- Distribute grants towards Pilot Phase projects while continuing to fundraise;
- Continue to update the PBS ecosystem open R&D map to reflect the latest progress, and identify gaps and challenges;
- Review Pilot Phase at the end of 6 months, update the objective for the next phase and iterate PBS Guild governance structure.
Source of Funding
The source of funding of the PBS Guild will primarily come from community donations from key beneficiaries of the PBS ecosystem, primarily validators, builders, applications, and L2s.
PBS Guild targets to start with at least $1M upon launch for the Pilot Phase, with no cap.
Destination of Funding
PBS Guild will consist of multi-phase funding initiatives that are open to support individual contributors and projects, designed to streamline decision-making process and open to funding mechanism experimentation.
Provided below are initial proposals for PBS Guild grants, which will be further developed in collaboration with the grants council and PBS Guild members.
Pilot Phase
- Independent Relay Ecosystem Booster Grant
- Funding up to 5 independent relays: $20,000/month per relay.
- Basic Qualifications
- Not vertically integrated with any builder or relay
- Advancing infrastructure resilience and neutrality
- Additional criteria for the grants selection process may include performance, operational track record, technical capabilities, among other criteria.
- PBS R&D Grant
- MEV-boost relay economic sustainability proposals
- MEV-boost Improvement Proposal (MIP) governance proposals
- Research the design space for improving the MEV-Boost censorship resistance, e.g. exhaustive exploration of trade-offs of inclusion list vs. partial block auctions
- Research and prototype PBS on L2s
- Research and prototype: relay privacy (e.g. SGX-relay)
- Data Transparency Grant
- Operate a public good data relay
- Create a public data dashboard tracking the order flow supply map
- Research MEV-Boost modification
- Build a public data dashboard monitoring builders’ strategic bidding behaviors
- PBS Education Grant
- Improve MEV-Boost documentation, create PBS education material
- Position paper on Validator Neutrality and PBS