Home  >  Article  >  Rethinking the market structure of PBS and improving the design of ePBS

Rethinking the market structure of PBS and improving the design of ePBS

王林
王林forward
2024-03-25 17:26:44625browse

Original title: "Reconsidering the market structure of PBS"

Written by: Barnabé Monnot, researcher at Robust Incentives Group

Compiled by: Tia, Techub News

In the current In the trading market, the block generator directly decides which transactions to package into the next block by reviewing the transactions in the memory pool, especially those that pay high-priority fees. This practice allows block producers to use various strategies to select transactions to be packaged, sometimes even including their own transactions, to maximize MEV for profit.

To solve this problem, Proposer-Builder Separation (PBS) separates the block construction and proposal roles. In this model, the builder is responsible for constructing the execution block (i.e., the ordered transaction list) and submitting bids, while the proposer's task is to accept the execution block with the highest bid. In this way, responsibilities and functions are clearly divided between different roles, thereby increasing the efficiency and security of the system.

It’s been a while since I touched on the topic of PBS, and seeing the new developments regarding PBS in recent months, I thought now would be a good time to revisit PBS. I'd like to share some thoughts that haven't been fully sorted out yet, aren't very clear, but are worth discussing.

Rethinking the market structure of PBS and improving the design of ePBS

ePBS is back

Recent proposals for ePBS (Potuz,Terence) is seeking support from MEV-Boost, which has triggered a discussion about "What does PBS do?"

In order to make the following discussion more structured, I will split the components of PBS into two parts:

  1. Market structure: The idea now is to Split the role of the validator into a proposer and a builder, and exchange these two split roles, just like what Potuz wants to satisfy in his article "Design Limitations of ePBS".

  2. Distribution mechanism: PBS defines the space that proposers and third parties can enter. Today, with MEV-Boost, proposers give up the right to execute payloads.

I think it may be dangerous to use a special distribution mechanism like ePBS. We are likely to let the validators perform programmable fair transactions and try to let the validators enter the role of proposers as much as possible. Committee, in this article I will explore this in depth and question the market structure of validators as proposers, such as the recent Execution Tickets proposal. The recently proposed ePBS inherits the special market structure and distribution mechanism of MEV-Boost. The market structure determines the space of possible allocation mechanisms, and I think some of MEV-Boost's limitations, such as guiding a "healthy" builder market, may be caused by the market structure of validators as proposers.

Next, I will use "payload" instead of "block" to limit the discussion to the execution of the payload. This article will not discuss the responsibilities of the validator: the sending of the beacon block.

The Proposer’s Pain as a Verifier

The core of MEV-Boost is that the verifier will be given the right to propose the execution of the payload and receive benefits from these rights. However, validators want to contract out the construction rights and let others (one or more builders) decide the content of the block on their behalf. MEV-Boost allows this to happen. Proposers sell their entire payload, while builders commit to valid payload content when bidding. This is a specific allocation mechanism, and other designs exist, such as slots or hybrid auctions , which promise to use a payload from a specific builder.

The most important thing at this point is that validators must continue to be payload proposers, they must sign a process that has nothing to do with their construction, which feels like a protocol limitation. In this sense, the proposer's signature feels almost purely decorative, a technical necessity. At the same time, this technology still requires the fair exchange complex mechanism at the heart of MEV-Boost. The exchange in question is a builder's promised output (a block), corresponding to the signature of a validator, who assigns construction rights while retaining his own proposal rights.

The complexity of operating this exchange cannot be eliminated, so certain trust assumptions will change depending on whether the complexity exists outside or within the protocol. If we think it's right to assign build rights, it might be worth taking on this complexity. By implementing this exchange, the validator becomes the proposer of executing the payload, and the protocol uses a specific distribution mechanism to perform the exchange, or a recent proposal from Potuz, "wholesale PBS", aka slots auction.

Therefore, the question now is to decide whether to establish an agreement mechanism for validators as proposers and builders to sign a mutually binding agreement with each other, that is, validators as proposers have the right to sell their constructions. One argument made during the recent (e)PBS Breakout Call was that this mechanism would cleanse the supply side of this market, namely the relays and builders. For relays, the argument is that now that a protocol approval mechanism exists, we can now take the responsibility of figuring out the economics of sustainable relaying off our shoulders. For builders, the idea is that we now have a level playing field to get into services because there is a trustless, in-protocol way to build.

My question is that neither hypothesis calls into question whether it is the allocation mechanism or the market structure itself that creates what we consider to be an overly concentrated market. The existence of relays is to allow fair exchange between validators and builders as proposers. Under different structures with the same economic mechanism, there is no indication that relays will still exist. Builders are also likely to be influenced by centralized forces due to the wholesale and spot nature of the distribution mechanism. So implementing ePBS would solve what problems we want to solve. So, while ePBS does improve the MEV-Boost status quo by increasing the action set of all market participants, does it perpetuate a market that has yet to adapt? Are these improvements worth it relative to development costs? Have they set the right boundaries for the agreement?

Are validators good proposers?

We first question the market structure: Why should the right to propose a payload execution be granted by default to the verifier in the first place?

Rethinking the market structure of PBS and improving the design of ePBS

Let’s try to think about the reasons why validators should be the default payload proposer. Censorship resistance may be a reason to keep validators active in builds that execute payloads. We want the validator set to be decentralized, which is key, so that payloads can be used during the build process. However, validators completely give up this ability today when using MEV-Boost, or they may completely give up this ability tomorrow when using ePBS. Proposals such as Inclusion lists or derivatives (e.g. Multiplicity) could address this situation, allowing validators to impose binding constraints on payload construction without lowering the constraints. efficiency. However, these proposals are somewhat orthogonal to the problem of assigning proposal rights, in that they are binding on anyone who happens to hold that right, whether another validator or other party.

Why do we care about giving proposal rights to validators by default? The answer may also be: we care about self-constructing validators who will build the payload content in the order they like best or as they wish, that is, we want They reserve the right to build as well as the right to propose. The fact that a decentralized group of participants (validators) takes turns building payloads suitable for them can be seen as a feature. Alice may want her payloads to be sorted fairly, but fairness here is relative to Alice and may be completely different from what Bob thinks is fair. In this case, removing the built execution payload from the validator will be a problem: we will no longer guarantee that the validator can build the execution payload at will. I personally don't think this is a major problem. First, the market indicates that most validators prefer not to exercise that construction right themselves, but instead delegate construction to other parties. Secondly, while it may be good for validators to handle payload content by building their own, in my opinion, validators have no more reason than anyone else to build "ordered payloads" (already addressed in the previous chapter to isolate the issue of censorship resistance). Note that early designs such as MEV-Burn retained the default allocation of validators’ proposal rights while forcing them to give up their build rights.

Verifier-Proposer Separation (aka Prover-Proposer Separation, aka Execution Ticket)

So, if the protocol decides to no longer default to the right to propose and build payloads validator, but rather assign it via some mechanism to other parties that may be different from the validator? If the validator is a simple "pass-through" intermediary for a set of third-party entities that construct the payload, doesn't it make sense for the protocol to only care about the distribution of proposal rights?

Rethinking the market structure of PBS and improving the design of ePBS

That’s the point of Execution Tickets (ETs), a permissionless marketplace that allows buyers to purchase the rights to propose execution payloads. These rights give ticket holders randomly assigned rights, and holders can know in advance (at a specific time to decide the parameters) when their ticket will allow them the opportunity to propose execution of the payload.

The protocol may then no longer care about a fair exchange of construction rights between protocol-legitimate validators as proposers and protocol-illegitimate builders. It is still clear to the protocol that the bearer is a proposer, although the bearer may not be staked. In particular, the protocol may no longer be responsible for a fair exchange between ticket holders and builders as proposers (if any): the protocol has performed its distribution function when selling tickets.

Many questions remain regarding the viability of execution tickets as a distribution mechanism for a market structure that separates validators from proposers. My personal view is that if ET is indeed not the correct mechanism, then giving us confidence in the correctness of the market structure would lead us to believe that there is some mechanism to perform allocations correctly, whether ET or otherwise.

The most powerful argument I have seen questioning the validator-proposer-separated market structure comes from Quintus Kilbourn and Conor McMenamin's article "When to Sell Your Blocks". Here, they distinguish between passive monopolist and active monopolist. In the Validator-as-Proposer model, one might think of the validator as a passive monopolist who simply listens to builders' bids for the right to build a payload. In a validator-proposer-separated model, such as that implemented by ET, the ticket holder would become an active monopolist who, according to Quintus and Conor, "cannot be To circumvent, you need to pay some fees to be included in the block (Monopoly Pricing) and to get a head start when resources are limited."

Quintus and Connor further pointed out :

There is no rational model for the difference between active monopolies and passive monopolies. This distinction stems more from the behavior observed by the verifier. In the long run, validators may act as active monopolies and act rationally. On the other hand, external reputational issues may prevent this from happening.

In other words, if validators tend to be rational in the long run, the difference between validators as proposers and ticket holders as proposers may not remain very large. This accelerationist argument for rational tendencies is well established in practice, but do the fundamental properties possessed by validators prevent them from becoming active monopolies outright? This is still an open question in my opinion, and I've recently addressed it by trying to further break down the role of validators under the Rainbow Staking Framework. If there is no complementarity between the different roles that a validator may embody (as a prover, as a censorship resistance producer, as a payload producer), then there is a stronger argument for why a validator is essentially nothing What can stop them from heading towards active monopoly, and why unbundling these roles might be a good idea. Conclusion

When in a world with validator-proposer separation, proposers recruited by the protocol can again delegate the role of the build to another entity, the builder (if the proposer uses There is a fractal structure when different allocation mechanisms, such as partial block auction

)

. So in summary, when we talk about market structure or allocation mechanisms, we need to be clear about which market we are interested in: the market that allocates proposal rights, or the market that allocates construction rights?

Rethinking the market structure of PBS and improving the design of ePBSI believe that implementing ePBS should be considered across the board compared to other options such as broader enforcement tickets and validator-proposer separation. ePBS does improve some aspects of the current MEV-Boost market, such as providing access to trustless paths and enabling us to employ different mechanisms (such as slot auctions). However, ePBS is mainly concerned with the distribution of building rights, and perhaps this is not what the protocol should be concerned about. Assigning proposal rights may be sufficient.

The above is the detailed content of Rethinking the market structure of PBS and improving the design of ePBS. For more information, please follow other related articles on the PHP Chinese website!

Statement:
This article is reproduced at:panewslab.com. If there is any infringement, please contact admin@php.cn delete

Related articles

See more