From Pre-Execution Privacy in PBS:
For example, the proposed design gives the winning builder a headstart in knowing what the next state of the chain will be and an incentive to delay revelation of that state as long as possible. This constitutes a research direction in itself.
I’ve been thinking about this exact issue in the back of my mind for the past several months. It is not only a problem with Ethereum’s PTC proposal, but also with ePBS designs for layer 2s and other layer 1s that use different kinds of consensus/sequencing protocols (such as optimistically responsive or DAG protocols). I don’t have definitive answers, but I’ll share my informal thoughts on this topic. I’d love to start a discussion about this.
Goal: Determine if the information asymmetry problem is actually a problem.
Key questions to answer:
- Does the information asymmetry between the incumbent builder and other builders give the incumbent builder a meaningful advantage over other builders in the market?
- If so, how does this advantage affect the properties ePBS/Ethereum is trying to achieve?
- If so, how can we design ePBS protocols to mitigate this advantage (either through incentives or protocol design)?
- How can we generalize this analysis to more broadly analyze resource asymmetry among builders?
Part I: Does the information asymmetry between the incumbent builder and other builders give the incumbent builder a meaningful advantage over other builders in the market?
First, let’s offer one possible, informal definition of the problem.
Let i represent the index of an arbitrary builder in the system. Let j represent a slot index in Ethereum. Let B_{j_i} represent a block built by builder i for slot j. Let P_{j_i} represent the profit builder i would earn on a block B_{j_i} if it is committed to the network. Let R_{j_i} represent the revenue a builder would earn on said block. Let b_{j_i} represent the bid amount from builder i to proposer of slot j.
P_{B_{j_i}} = R_{B_{j_i}} - b_{B_{j_i}}
Let s_i(\Delta) represent the strategy function of builder i, where \Delta is the duration over which the strategy executes (i.e. the time a builder has to build a block between when they receive the latest Ethereum state from the previous slot to when they must commit to providing a particular block for the current slot). Let \Delta` > \Delta.
R'_{B_{j_i}} = s_i(\Delta)
Let R_{B_{j_i}}' represent the additional profit builder i can earn in slot j with s_i(\Delta’) in comparison to the maximum revenue any builder (including itself) would earn with s_k(\Delta).
R'_{B_{j_i}} = s_i(\Delta’) - \max{\{s_k(\Delta)}\} \text{ : }\forall k \in \{0, n\}
To simplify the problem definition let’s assume the following properties:
- Proposers always choose the highest bid available
- Builders use the same strategy for every slot
- The network is synchronous; builders and proposers have synchronized clocks. We don’t need to worry about builders’ bids / blocks being delayed by the network
- All builders aim to generate the same profit (i.e. P_{B_{l_k}} = c: \forall k \in \{0,n \}
- \forall s_k(\Delta) \text{ where } k \in \{0,n\}: \Delta \rightarrow \infty, s_k(\Delta) \rightarrow \infty; all strategies are rising functions over time \Delta
It should follow: if a builder is able to generate more revenue for some block B, they can bid higher for said block to the proposer.
Next, let’s define what a meaningful advantage might be.
One potential definition of meaningful:
R_{B_{j_i}} is meaningful if it causes builder i to win the next slot’s bid auction more often than it otherwise would without the advantage. Thus meaningful advantage for a single slot (under our simplified model) is when:
\theta(R_{B_{j_i}}) > x
where x is some threshold considered tolerable by the network and \theta is the bid-win-rate of the builder. In the most conservative case x = 0. In reality the network may be comfortable with some small threshold, such as 5% (as averaged over many slots).
An observer might recognize that according to the above definition some profit advantage may exist in Ethereum (and similar systems) already. For example, if the proposer of slot j-1 in current-state Ethereum acts as their own builder, they will have access to slot j - 1 ’s state before the rest of the network. This could give them some advantage in bidding to the proposer of slot j.
It is likely, though, that there exist thresholds of advantage such that only certain values of \Delta` give builders meaningful advantage. It is also possible some builders will be less affected by the advantage of another builder, depending on that builder’s strategy. For example, a builder whose strategy relies heavily on private mempool transactions and little on the latest Ethereum state may be minimally affected by the advantage of the incumbent builder (i.e. their bid-win-rate stays the same regardless of the advantage).
Does this problem affect properties of ePBS or Ethereum?
Some potential ways the information asymmetry problem may play out:
- If the advantage of an incumbent builder is commonly large, the network may centralize on a single builder (or have long bouts where there is a single builder for many slots in a row). In the absence of partial block auctions, this may give the centralized builder monopolistic pricing power during their reign.
- The market may still converge on a single builder if such a builder can consistently outbid others. However, the key difference is that with ePBS the protocol itself is giving a builder this advantage; therefore no longer supporting a fair, competitive market
- If the advantage is at least moderate, we may see more effort to extract multi-block MEV opportunities.
- In optimistically responsive protocols (such as those in use by layer 2s or other layer 1s), the builder has an incentive to delay releasing the block data, which forces a necessary delay in the protocol that optimistic responsiveness tries to avoid.
Finally, how do we find the answer?
Some potential pathways:
- Analyze existing
mev-boostdata from the Flashbots relay.- Can we find signals to meaningful advantage in the case where builders also run proposers?
- Can we analyze block contents to determine the kind of strategies builders use? Are these strategies heavily reliant on the previous slot’s state? Can we approximate a strategy curve for a few prominent builders?
- How much do builder’s bids change over a slot? Do they remain consistent, or can builders offer significantly higher bids given more time to execute their strategy
- Can we approximate the profit margin of different builders?
- Can we analyze current consecutive builder behavior to determine if this advantage meaningfully exists in Ethereum today?
- Pursue a game-theoretic analysis
- Investigate existing economic literature about market competition with information asymmetry (or resource asymmetry in general).
- Can we apply existing economic models to better define/analyze this problem? Do these models capture complexities the simplistic model above does not? Where do the assumptions of existing economic models’ problem space and our problem space differ?
- How do we anticipate builder strategies and resources changing over time, both with and without ePBS? Will builders converge on similar strategy curves in the long run?
- Does this make current multi-block MEV strategies more viable?
- How does this interplay with
mev-burn?
- Investigate existing economic literature about market competition with information asymmetry (or resource asymmetry in general).
Part II: If so, how can we design ePBS protocols to mitigate this advantage (either through incentives or protocol design)?
The answer to this second question relies on how the meaningful advantage is gained, and under what parameters. I have little to offer in this section, but here are a few preliminary ideas:
Let’s quickly look at a strawman solution of using slot auctions instead of block auctions. In a slot auction a builder does not have to commit to the contents of the block until it actually reveals the block data. Builders can submit bids to proposers and hope that by the time the actual block is released, they’ve been able to extract higher block revenue. If a non-incumbent builder is willing to take on additional risk, they may choose to bid competitively with the incumbent builder with the hope that by the time the block data is revealed, they’ve been able to actually extract enough revenue to match the bid they submitted to the proposer. Slot auctions could be an easy way to force the protocol to give other builders a minimum amount of block building time with the latest state. Perhaps the slot auction time can be tuned such that this minimal building time is enough to mitigate incumbent builder advantages. However, balancing the slot auction time with protocol latency will be challenging, particularly since the ideal slot auction time for mitigating the head start problem will change as builder strategies change. The slot auction also requires non-incumbent builders to take on more risk than the incumbent builder.
A second strawman solution could be to disallow the same builder from being selected in conseuctive slots. This would mitigate the information asymmetry problem almost completely. However this doesn’t seem like a good strategy since the same builder entity could easily change their on-chain identity each slot to circumvent this rule. It’s also not clear that consecutive builders with the same identity are always “bad.” (E.g. perhaps SUAVE becomes the incumbent builder; that’s considered a desirable outcome by many.)
Neither strawman, in my opinion, gives a proper solution.
Notes
- The above model is overly simplistic. In reality builders may not use the same strategy for each block, builders do not have equal profit margins among them, and builders may start building blocks before knowing the latest Ethereum state.
- The above model is not at all rigorous. It’s purely meant as a preliminary mental model. We should more explicitly define \theta, “advantage,” etc.
