Today, I am giving you the chance to push that button, without feeling guilty about it.

I’ve moved my operations to a more web3-native platform called Mirror. It’s very much like Substack, so if you meant to continue following me, you can subscribe with your email address there and it will all be kind of the same (except with added goodies like using your Ethereum wallet for signing in). Moving forward, I plan to use Mirror for new posts.

“Is that a rug?? Am I aping into some high-risk subscription for unclear benefits?”

Well, if you want to hedge your bets and evaluate whether this is a good move for you, I am pleased to report that you can browse through all 5 (five!) of my already available posts over there. All you have to do is head over to mirror.xyz/barnabe.eth (that’s my ENS in there! cool right?)

Take me to Web3

You’ll find the following:

• A series of posts, “Semantics of Staking”, on constructing liquid staking and re-staking tokens iteratively, from a balance sheet perspective.

  • Part 1: Liquefaction (November 2023)

  • Part 2: Re-staking (December 2023)

  • Part 3: Advanced constructions (February 2024)

• Two posts on Proposer-Builder Separation (PBS) and newer things that came up, such as Execution Tickets, Attester-Proposer Separation, preconfirmations, recent enshrined PBS developments, as well as old friends such as Protocol-Enforced Proposer Commitments (PEPC).

  • Reconsidering the market structure of PBS (March 2024)

  • More pictures about proposers and builders (April 2024, honestly read that one if you only check one of these out)

You’ll notice that my writing has picked up the pace. It’s just been a few good months. The RIG team is on fire (check out our newsletter on Substack, before we move that too to Mirror 😀) and I owe a lot to the energy they bring. We have a new address for all of our work, so make sure to check that out too:

rig.ethereum.org

Anyways, I do want you to leave with a nice feeling. The next button may have to do with points. It may not. Who knows? No one does, unless those who pushed that button. Will you be one of them?

Points! (maybe)

Love you all ❤️

Ultimately though, the reason why I think PBS is so interesting has more to do with its role as a kind of Rosetta stone for where protocol development is headed. Some of it has to do with the political economy of the protocol versus the layers built on top of it. Should protocol development be purely reactive, and always attempt to run behind the latest ball thrown to it by its upper layers? It’s a gross simplification that overlooks both the virtuous feedback cycle orienting protocol development, and the ability to set the tempo, for instance the case of re-focusing towards a rollup-centric roadmap.1 But it’s a working simplification that is often deployed when people talk about PBS, with a view that the protocol is one step behind where every other player has moved on to, and eternally condemned to follow.

More of it has to do with a fundamental question that I’ve come to think of as the protocol’s boundaries, specifically our ability to define them, and our ability to defend them. To explore this boundary, we need to understand what gives a protocol mechanism credibility, and how this credibility is strengthened or eroded by other mechanisms in the protocol’s environment, beyond its boundaries.

Fence-breaking

I start here from the view that the validator set is a very expensive Schelling fence, the fence representing the common expectation of the protocol’s agents behaviour. Staking is an act of costly signalling, embodying the message “I am willing to lose part or all of this stake, should I act contrary to the protocol’s aims”.

The fence comes with fancy gadgets, automating away the burden of rewarding good behaviour and punishing bad. The rewards and punishments are doled out in graduated measures, treading a line between harshness spooking away more security than it guarantees, and softness allowing bad actors’ influence to act upon the system for longer.2

Yet “protocol aims” extend much further than the gadgets reach. Here is an imperfect way of stating it: There are things that the protocol does not see, but cares about. But this formulation is wrong in the absolutist view of the protocol, where the protocol is only and exactly what it sees. What it does not see, but cares about, resides in the expectations of all agents involved in the execution of the protocol, from validators to users and everyone else in-between, what’s broadly referred to as “the community”.

Case studies of fence-breaking

The community has an oral tradition for what exactly would be seen as breaking the fence (even when the fence itself does not realise it is broken!) and its response in kind. Let’s review some of them, and in doing so, appreciate how much the protocol does not see.

• Producing a safety fault in the finality gadget in an attempt to revert a finalised block
  Definitely breaking the fence, requires social input in the form of selecting the valid finalised checkpoint among available options. After which point the widespread slashing of the double-finalisers is done in the regular protocol logic, by including evidence of faults.

• Bribing attesters to mess with the fork choice and re-org blocks (~ “hard censorship”)
  Very likely breaking the fence, fork out members of the bribed committees.

• Intentionally finalising an invalid and malicious state transition
  Someone is trying to steal something by rewriting the state and hoping it will become canon. Definitely breaking the fence, fork out members of the finalising committee.

• Intentionally finalising an invalid, but honest state transition
  The DAO was one of these, a rare example of the community overruling the protocol it set up in the first place (“well actually, we didn’t mean for you to do that”). To some, this did not break the fence, i.e., it did not require intervention of the miner set to defend against the invalid transition. To others, it was such a break, which was defended against by forking out non-compliant miners and launching Ethereum Classic.

• Unintentionally finalising an invalid state transition, e.g., as a result of a consensus bug in some majority client
  Breaking the fence, but either “reboot” from the last valid state transition, or go along with it, and pretend like the fence had never been broken to begin with, while the faulty clients are fixed?

• Untimely performance of validator duties
  Also known as timing games, validators may have conflicting incentives regarding the timeliness of their duties. They may want to delay proposing a block until the last possible moment to obtain more MEV rewards, or may want to delay voting as attesters to ensure correctness. This silently breaks the fence, as the protocol’s idea of time is entirely based on the rhythm of validators performing their duties, but the community could likely recognise validators who are untimely with statistical significance and do something about it.

• DoS-ing validators to prevent them from proposing, losing rewards accumulating to online non-DoS’d validators
  Breaking the fence, but identifying culprits is hard, unclear what would happen.

• Including transactions which were not gossiped over the public Ethereum mempool
  That fence was probably broken first by miner payments to themselves/their pool (perhaps this was judged to be fine), then by exclusive inclusion agreements offered by mining pools.3

• Ordering block content differently than descending gas price
  Not clear it was the original fence to begin with, some may judge ordering transactions by anything other than receive-time (assuming some reserve price is met when supply is constrained) is fence-breaking. But along with exclusive transactions, that fence was broken with the appearance of MEV on the scene, and allowed non-protocol actors to determine block ordering out-of-band.

  

• Outsourcing block production entirely
  Well that’s the logical endpoint of the two previous fence-breaking examples. There was likely an implicit expectation that validating and block building were not two different things, but it turns out this too can be modularised.

  

• Proposer cartel to bring down the EIP-1559 base fee to ~0, extracting transaction fees for themselves
  In this attack, a cartel of block producers underfills their blocks to drive the base fee to zero over time, capturing congestion fees via priority fees instead of them being burned. This attack is described in Roughgarden’s analysis of EIP-1559, section 7. The attack may be combined with artificial supply constraining to extract monopoly rent out of the latent demand for blockspace.

  • With re-orgs/censorship of blocks deviating from the cartel
    Back to the case above dealing with validators performing hard censorship, this is very likely breaking the fence, fork out members of the cartel.

  • Without re-orgs/censorship of blocks deviating from the cartel
    At any point during the attack, any cartel member has a myopic, greedy incentive to deviate and grab the fees left on the table by other cartel members who underfill their blocks. This creates instability in the collusion dynamics of the cartel. Members of the cartel who are not deviating probably still do break the fence, and the community may fork out these members, unless the cartel implodes before that.

  • With mev-burning activated
    Assuming a competitive builder market, all value extracted is lost to validators anyways, since builders compete to give away as much fees to the protocol, including congestion fees if they are not burned by EIP-1559 in the first place. mev-burning potentially weakens the incentive to run the “base fee to 0” attack in the first place.

    • Bribing attesters to defeat mev-burning mechanism and report 0 to the protocol
      But the mev-burning mechanism relies on an honest majority of attesters, who enforce the credibility of the auction on behalf of the protocol. If this honest-but-rational majority was defeated by bribing, the community could decide to fork them out too.

• Systematic censorship from identifiable validators
  Probably breaking the fence, potentially triggering a fork.

Protocol introspection and protocol agency

Reading through this, we sense a general pattern, or recurring themes:

Protocol introspection

The protocol gains introspection, a measure of legibility of its own operations, via credible signals. For instance, the FFG consensus mechanism provides introspection for the finality of a chain prefix, based on an accountable consensus gadget. The base fee provides introspection for the measure of congestion in the system. mev-burning would rely on consensus bids, which reveal a credible signal of block value to the proposer (in excess of what EIP-1559 removes via the burn).

Based on the signal we receive, when do we know the fence was broken? This signal ranges from unequivocal (the finalisation of two conflicting checkpoints is legible to the protocol) to more ambiguous (a re-org of the available portion of the chain or the base fee being driven to zero may not indicate malicious intent). This knowledge is also viewer-dependent: something unequivocal from the protocol’s perspective is unequivocal to the community, but the converse does not always hold.

Protocol agency

When the fault is legible to the protocol, it may also be actionable. If two conflicting checkpoints are finalised, protocol users only need to coordinate on which side to use as legitimate continuation of the chain, and the protocol’s slashing facility takes care of the rest.4 Not so with the “base fee driven to zero” signal: while unlikely that the demand for Ethereum blockspace is below the target supply, it is not entirely out of the question either. If the protocol cannot make up its mind on the presence of a fault, it also cannot do anything about it.

Agency is enhanced by accountability. If we can recognise the fault, can we unambiguously attribute the fault once it is recognised? Here again, sometimes both the protocol and the community recognise guilty parties, sometimes the community alone does, and sometimes even that is not clear (e.g., DoS-ing the next proposer). For non-attributable faults, e.g., an offline validator, the protocol must rely on a noisy signal (missed slots or wrong votes) to attribute penalties.

Case studies in upgrading the fence

A large number of upgrades found on Vitalik’s yearly roadmaps aim to achieve the following: Push forward the limits of what the protocol sees, and upgrade its arsenal of automated defence systems.

We now revisit the case studies and show how these mechanisms increase protocol introspection and agency.

• Producing a safety fault in an attempt to “unfinalise” a finalised event
  Weak subjectivity is the ultimate limit of the protocol, at some point the choice to restart from a “good” checkpoint versus a “malicious” option lies in a social determination process, unless you believe “good” = “(wall-clock) earliest” and are willing to trust Babylon chain-like constructions to feed you that signal credibly.

• Bribing attesters to mess with the fork choice and re-org blocks
  Single Slot Finality (SSF) pushes most re-org scenarios to the case of a safety fault of the finality gadget, which is assumed to have some measure of automated recovery mechanism, as described in the point above. If not enough validators attest to the finality, the re-org is one of the available chain, for which legibility is not so clear. Yet with SSF, we provide legibility more rapidly than with the current Gasper protocol.

• Intentionally finalising an invalid and malicious state transition
  Enshrined fault or validity proofs could trigger automated punishments against this, at both consensus and execution layers (e.g., slashing validators who propose invalid blocks).

• Intentionally finalising an invalid, but honest state transition
  Here is an example where the protocol’s own introspection of its validity is disabled by the community, an instance of a downgrade.

• Unintentionally finalising an invalid state transition, e.g., as a result of a consensus bug
  Today, the protocol’s introspection of its validity relies on a majority of validators applying the block validity rules when building the chain. The protocol gains further introspection into the validity of its state transitions with validity proofs, e.g., via a native zkEVM, assuming the circuit of the state transition function (STF) is correctly programmed. Should a validator client produce invalid proofs (e.g., if it has misrepresented the STF), the blocks it produces will be ignored.

• Untimely performance of validator duties
  Attesters function as ultimate arbiters of the timeliness, giving weight to forks via their votes, which succinctly express their current view of the chain. Despite this, fork choice upgrades such as (block, slot)-fork choice intend to provide a finer decision space over the outcomes of the available chain, e.g., was the block received on time, if it was received at all?

• DoS-ing validators to prevent them from proposing, losing rewards accumulating to online non-DoS’d validators
  Secret Single Leader Election (SSLE) keeps private the identity of the proposing validator to all but the proposer themselves, until the block is proposed. In this case, the protocol does not see the identity of the next proposers, which prevents some targeted griefing.

• Including transactions which were not gossiped over the public Ethereum mempool
  There is no roadmap item for this attack, but should there be one, it would likely rely on some kind of consensus gadget over mempool contents (“was this transaction seen by most members of the committee?”), allowing only transactions certified as broadly seen by the validating set to enter any block.

• Ordering block content differently than descending gas price
  There are many ways to bind proposers to a specific ordering. Additional block validity conditions could require a certain ordering, e.g., descending gas price. Ordering protocols such as Themis are basically mempool consensus, with the additional property of surfacing an ordered list in addition to a membership set. Block validity could depend on receiving a certificate from a round of Themis.

• Outsourcing block production entirely
  Enshrined PBS attempts to bring back some level of control, regulating the conditions under which block proposers outsource block construction to third-parties. Including consensus bids towards MEV capture and redistribution by the protocol further improves the credibility of the PBS auction signal.

• Proposer cartel to bring down the EIP-1559 base fee to ~0, extracting transaction fees for themselves
  The mempool consensus gadget would surface to the protocol the signal that though there is enough demand meeting the reserve price, blocks are kept artificially empty. This signal could be used to ignore blocks which don’t include all transactions in the mempool consensus set, enabling protocol agency.

• Systematic censorship from identifiable validators
  Inclusion lists prepared by honest validators function as censorship signals and defences. A censoring validator always has the option to not propose a block in case they do not wish to respect the inclusion list, or artificially stuff their block to satisfy the inclusion list fallback requirement. In both cases, the censoring validator profit is hurt, even when the cost of stuffing the block is higher than the revenue received by censoring validators from private order flow. Attesters uphold the validity and the satisfaction of an inclusion list, via the fork choice.

Most gadgets above surface a signal by relying on some form of consensus, supported by honest majority arguments, or supermajority in the case of ordering protocols or gadgets relying on BFT-like constructions. Likewise, these signals may be disabled or made non-credible by a concerted cartel, who additionally must censor attempts from members to defect from the cartel.

In Ethereum Proof-of-Stake, it is relatively easy to summon a committee running any or all of these gadgets. Each slot, a proposer is called upon to make a block, after which a row of attesters, sampled from the larger set of active validators, 1/32nd of the whole set per slot, gets to make a vote embodying their view of the current available chain and finality gadget. Via sampling, committees are assumed to have an honest majority of members with high probability. Various proposals were put forward to overload the attesters with more duties, such as the Shutterized Beacon Chain, which adds a threshold commit-reveal scheme for encrypted transactions to the execution payload.

The protocol must only see what it is willing to defend

We’re starting this section with a title cutting the argument short, giving away its conclusion, but let’s see how we might get there.

The protocol as commitment device

My read on protocol development is that it has been inspired so far by the contrapositive: the protocol cannot defend what it does not see. Indeed, without a credible signal actionable upon by the protocol, there is no way for the protocol to do anything about an act of fence-breaking, though its community might be able to do something about it. Naturally, this view drives the protocol towards ever-greater extension of its boundaries.

I started many recent talks by talking about the “root” Principal-Agent problem (PAP), where the Protocol delegates its execution to Validators, who hopefully follow the letter of the Protocol’s specifications. But as it turns out, this is not even the root PAP, as it is preceded by the Community delegating its will to the Protocol itself. The protocol itself functions as a commitment device, embodying the will of the community. The act of placing agency at protocol-level, rather than in the hands of the community, is how credibility is created.

This sleight of hand engineers credibility: It is not as if the community was powerless—it could always step in and hardwire the outcomes it cares about, as it has done with the DAO—but by setting up an automaton in the shape of a protocol, it stands a step removed from the fray.5 The automaton is given powers via introspection and agency, so we summarise this construction with the following rule:

Protocol credibility = Protocol introspection + Protocol agency

The trade-off with building in credibility is prescriptivity. To adequately defend a particular outcome which is part of the will of the community, the protocol must become opinionated about this specific outcome becoming realised, e.g., transactions being ordered by some receive-time consensus protocol, the base fee being burned, the PBS auction selling the whole block, the built blocks respecting the censorship resistance gadgets etc. This creates risk that the protocol locks in a suboptimal outcome, where welfare is lower, or inadequately distributed. But more importantly, it overloads the validator set, which is two steps removed from the community, with the duty to defend a wider and wider fence.

Two forces act over time, one positive, one negative. As time goes on, the protocol successfully defending the community’s will enshrines the outcome further, a kind of Lindy effect, where the outcome (e.g., keep base fee credible) becomes more and more defensible, or incontestable. On the other hand, as Ethereum matures, as its economy complexifies and becomes further embedded in a wide net of dependencies and interactions, the incentives of validators will be more directly shifted. New domains such as SUAVE or Eigenlayer function as out-of-protocol credibility engines, where validator payoffs may be warped by games over which the protocol has no “extrospection”. With shifting payoffs, the gap between honest and rational behaviour of validators with respect to the protocol’s specifications further widens. This is especially true when suboptimal outcomes are locked in by the protocol, since then the game warper can directly bribe validators from the welfare gap: If censorship gadgets destroy revenue, the game warper can use the lost revenue to subsidise deviations from the gadget, by committing to the bribe ex ante but executing it ex post6, once the revenue was captured.

How protocol credibility is built

Reassessing the exact locus of power of the protocol has shifted my view with respect to protocol development. I do not believe that we only engineer protocol credibility by building in more upgrades and extending the area of protocol introspection and agency. What I believe to be equally correct is that we also engineer protocol credibility whenever we build in upgrades to realise outcomes we know the community would defend once they were built into the protocol.

Protocol credibility = Protocol introspection + Protocol agency + Defence of last resort by the community

Today the community is not enforcing mev-burning. Without building a credible mechanism in-protocol, burning MEV according to the community’s will (if it is indeed the will) is hard. A strawman argument explains it. There could be a broad, non-protocolised agreement that validators must set their fee recipient to the null address, and burn all rewards they receive, under the threat of being ignored and re-orged. But only requiring validators to set their fee recipient to the burn address would not be sufficient to “have mev-burning”, as validators could simply capture MEV with a different address. This deviation is illegible to the protocol, though potentially legible to the community.

The legibility and accountability of a fault is increased when validators are required to build their block with the highest bid they have received from some permissionless auction, the permissionless nature guaranteeing competitivity and thus credibility of the bid as representation of the true value of the block. In all current proposals for mev-capture at protocol-level, this requirement is enforced by an honest majority of attesters who turn down blocks committing to a bid lower than their view of the best offer, creating consensus over the value of the best offer. Protocolising mev-capture is then the act of deputising attesters as data availability oracles and timeliness agents, where the data are the bids. It could be done out-of-protocol, without enshrining deputised protocol agents who function as oracles, by relying on a fuzzier oracle such as the community monitoring a public channel for bids and gathering evidence of deviations (“we’ve all seen the bid in time, but the proposer didn’t use it!”) The former option creates credibility by “defining clear group boundaries” and providing “effective monitoring by monitors who are part of or accountable to the appropriators”, the first and fourth principles in Ostrom’s set for managing the commons, where “the group” is composed of staked parties who commit to enforcing the rules of the protocol, erecting the Schelling fence one Gwei at a time.

So building in mev-burning with a credible mechanism at protocol-level does not technically enable more than we could do today, but it socially engineers credibility by letting our favourite automaton pretend as if it was responsible for mev-burning taking place. Protocolising is an act of commitment, and the commitment is certainly weaker whenever the mechanism embodying the commitment is non-credible, e.g., if it is clear from game-theoretic analysis that even a somewhat weak collusion of players can defeat the mechanism, as protocol-illegible side contracts/off-chain agreements do in naive designs for EIP-1559 or mev-burning. But eventually, even a credible mechanism may be defeated by the honest majority assumption which underpins most of the protocol’s mechanisms. Once the mechanism is deployed, it is a shot in the dark whether the mechanism will eventually be defeated, especially when out-of-protocol incentives shift validator behaviour and the community is not willing to step in to defend it.

The role of protocol development

So we have a protocol which is in constant conversation with its environment, between validators who partly escape the protocol’s purview and a community whose will is imperfectly embodied by the protocol. In this framing, there is no room for a Platonic view of protocol development, where we always move further towards an idealised shape, perhaps what Bitcoin is chasing after. In contrast, protocol development is informed by the political economy of institutions in its environment, where the protocol is one among an ever-expanding web of many other institutions.

To create credibility here, casting the spell of extending the protocol’s boundaries with further introspection and agency is not enough, if other institutions work towards eroding credibility by shifting incentives of the protocol’s agents. Credibility is fully obtained whenever it is clear that the community is willing to defend the protocol’s preferred outcomes in the last resort, forcing the outcomes it cares about even at the cost of forking out part of the validator set. So, rather than the protocol not being able to defend what it cannot see, we may counter that the protocol must only see what it is absolutely willing to defend, lest we be mislead into thinking the protocol ultimately represents our will.

This high bar may be too high. There may be upgrades we build in for which we, as a community, do not entirely gauge how important the outcomes induced by the upgrade are to us. In fact, I would argue that this is probably true of all upgrades done so far, since they are first and foremost researched, implemented and deployed by a fairly small set of people, until they become canon to the rest of the community.

Yet framing the question in these terms (“Is this something we will defend beyond the protocol’s execution if it comes to that?”) may be a forcing function to examine how far the credibility of our upgrade extends. It is also a helpful guide to understand the privilege of the protocol’s position in its environment, as meeting place of the will of a community and of the networked interactions of economic agents and infrastructure who ultimately answer to the validator set. In doing so, we hopefully obtain a more accurate view of the balance of power between the protocol and the larger system in which it lives and evolves, informing the development process further.

Going further

For more, I recommend watching the entire mevconomics.wtf replay. Phil discusses protocol development as “dangling the nuclear option” to backstop the behaviour of out-of-protocol agents, a view in line with the balance of power argument exposed above. Vitalik points out several questions related to figuring out which upgrades to consider with respect to protocol economics (a cute example: SSLE may be partly defeated by validators choosing to reveal their identity in order to capture economic benefits). Tarun discusses a specific “welfare gap” example, for ordering protocols. Sreeram mentions some Eigenlayer applications as well as potential risks. Finally, some of the above-written is discussed in a fireside chat between Davide, Justin, Jon and myself.

Many thanks to Xyn for his work on permissionless credible commitment devices, and to many discussions with teammates and friends on this post.

Proposer-Builder Separation (PBS) is a hotly debated topic, a broad design philosophy emphasising the relationship between protocol and non-protocol actors for the maintenance and operation of a blockchain. While the discussion has now been active for over a year, the Merge first and Devcon second brought much more resources and attention to PBS. In this post, I provide my own take on the state of PBS research, necessarily a partial view but one that I hope helps make sense of where we are and what remains to be done.

What is PBS?

Beyond a single mechanism specification or implementation, PBS is first and foremost a design philosophy, recognising that protocol actors may invoke services from third-parties in the course of their consensus duties. By “protocol actor”, we mean in Ethereum Proof-of-Stake any bonded and active validator, expected to perform duties ranging from proposing a block, producing attestations or participating in the current sync committee.

Pre-Merge: bundle searchers and mev-geth

To some extent, PBS started previous to the Merge and Ethereum turning to Proof-of-Stake. We consider “default behaviour” the block producer behaviour which simply takes a set of transactions from their transaction pool and packs them as efficiently as possible in a block.1 The first deviation from this default behaviour was observed as some miners opened direct, private lines of communication with transaction originators, who would agree off-chain on the conditions for inclusion of the transaction.

While such contracts were established privately, mev-geth, developed by Flashbots, soon after opened up a marketplace between block producers and transaction originators. The marketplace relied on a trusted relationship between miners (organised in PoW as mining pools) and entities known as searchers. Searchers typically obtain a user transaction from the public transaction pool or some private service they operate. The user transaction is bundled with the searcher’s own transactions to extract value from the user transaction, e.g., follow a user trade with arbitrage or sandwiching, or follow an oracle update with a liquidation procedure.

Bundles are communicated in the clear to marketplace participants, along with a promise of payment from the searcher to the block producer should the bundle be included. Yet the marketplace is restricted to known block producers, a whitelist of major mining pools, to prevent bundle theft. A block producer who replicates the searcher’s strategy, replacing the searcher’s payment with full payment to themselves, would be detected and subsequently kicked out of the marketplace, losing potentially substantial payments in the future. PBS here is expressed as block producers receiving bundles from searchers for inclusion at the top of their block.

Post-merge: block builders and mev-boost

After the Merge, and with the introduction of solo validators who are not joining staking pools, maintaining a whitelist for the marketplace proved infeasible. Solo validators infrequently propose blocks, in expectation once every two months with the current number of validators bonded in the protocol. This changes the nature of the game, from a game of repeated interactions with threats of punishment for deviations to a game with players who are often more “single shot”.

A solution to this constraint is to procure a commitment to a specific block content from a validator, without the validator gaining knowledge of what the content is. The marketplace is now known as mev-boost, and forwards to block proposers headers of blocks created by block builders, along with a bid made by the builder, a promise to pay the proposer some amount for choosing the block they made. At the centre of the marketplace sit relays, who are responsible for checking the validity of the blocks made by builders, i.e., if the block is EVM-valid and indeed pays out the promised amount to the proposer.

To receive offers from builders participating in the mev-boost marketplace, validators run the mev-boost program alongside their consensus and execution clients. Validators select which relays to connect to, each relay enforcing its own conditions on the blocks they forward to connected validators (more on this later).

Towards “in-protocol” PBS

Faced with the prospect of relay failures, such as validation or liveness failures, as well as the opportunity to remove a new single point of failure from the system (inherently a centralising factor), “in-protocol” PBS designs were introduced by Vitalik. In these designs, a validator once again blindly commits to use a block provided to them by builders. But instead of a relay brokering the agreement, the protocol itself provides assurances of two kinds:

• To the builder, that a commitment was entered into by the proposer, and that this commitment may only be reverted by a consensus failure, e.g., a re-org, or a safety fault with single-slot finality;

• To the proposer, that the builder’s promise to pay will be honoured no matter what the builder does, e.g., eventually fail to release the block contents or release an invalid block.

PBS and the principal-agent problem

In a recent podcast with AltLayer’s Yaoqi Jia, I argued that instead of PBS being something we need, PBS appeared as a constraint to which the protocol had to react. The willingness of block producers to source parts of their blocks outside of the protocol, pre- or post-Merge, meant that protocol goals could become subverted.

Historically, it wouldn’t be the first time. An important protocol goal is reward fairness, or the ability for protocol actors to all receive in expectation the same amount of rewards, relative to their size. While this held true in Proof-of-Work, with rewards obtained proportionally to the hashrate brought to the network, the reward variance was high enough to incentivise most if not all miners to join mining pools, which share profits with their members. There is however no guarantee that the block made by the pool will respect the preferences of the pool’s members, unless the block’s construction is distributed across members of the pool. Remains the right to exit the pool if the pool acts against its members wishes, another reason why withdrawals are important.

Anytime protocol actors outsource some of their control over block construction, a new instance of the principal-agent problem appears. In such a framing, the principal requires the agent to perform some action, yet the incentives of the principal and the agent may not be fully aligned. An employer wants their employees to perform their job as well as possible, but an employee wants to minimise their effort, so appropriate compensation structures help re-align incentives. A block proposer wants transactions to be included, but the builder may wish to censor these transactions, so mechanisms enforcing proposer preferences help re-align incentives.

Market structure and allocation mechanism

In my opinion, it makes sense to think of PBS in a modular fashion, to better appreciate its design space. This approach lets us consider more clearly the structure of the principal-agent problem, and how far the protocol intervenes to resolve the problem.

• PBS as a market structure/legal system. The protocol defines the conditions under which proposers may engage with third-parties during block construction. For instance, the protocol provides enforceability of agreements, e.g.. enforces the promises to pay made by proposers or third-parties. The protocol also provides a facility for third-parties to recognise that a commitment was made by proposers. This facility comes from the protocol’s consensus mechanism, which makes safe commitments, i.e., prevents the commitment from being reverted.

• PBS as an allocation mechanism/business logic. The protocol defines the space of contracts proposers and third-parties may enter into. For instance, the protocol determines that only the whole rights of making the block can be sold, and organises the auction allocating these rights.

Under mev-boost, the protocol does not intervene into the principal-agent problem. It does not recognise the role of builders as an entity interfacing with proposers. At best, consensus layer clients provide the ability for stakers to blindly sign a block header, and perhaps additional services such as local profit-switching, yet neither of these are part of the protocol (to convince yourself, the word “builder” only appears in preliminary “sharding” parts of the consensus-specs repo).

This non-intervention implies that there does not exist trust-minimised, in-protocol ways for proposers to be made whole when the other side of the market does not honour their agreements. Whether this is the responsibility of the protocol or not is entirely debatable. My views on this are plural:

• On the one hand, proposers seeking maximum profit may engage in risky behaviour, such as delaying block publication or summoning external entities to help them create the block. The protocol may not care to backstop such activities, and in fact, may wish to prevent moral hazard as much as possible.

• On the other hand, the asymmetry between block construction and block verification (discussed in Vitalik’s Endgame post) does open up design possibilities that cannot be realised without an appeal to external entities. If we intend to fully lean in to the PBS design philosophy, for instance requiring powerful builders to produce Danksharding blocks, then the requirement of interfacing with such third-parties will be imposed by the protocol upon proposers. It would be a rough bargain if some proposers weren’t able to fulfil the duties required of them by the protocol (in particular, proposers in resource-constrained environments), while on top of this these proposers weren’t compensated when they inevitably invoke third-parties to fulfil the duties on their behalf. At least making an execution block, even one that does not maximise extracted value, is at hand for all proposers. Making a Danksharding megablock is not, however.
  
  If proposers are made whole in case of builder failure, what about risks to the protocol? If builders are less trusted to deliver on their commitments, we could end up with a protocol realising a much smaller social welfare compared to one where proposers are fully engaged to realise their duties. I am not as worried about this part. First, builders are profit-making entities, even in a competitive market. They care for their blocks to make it into the protocol, especially when the payment is committed and will happen regardless of their performance. Second, while it is a loss to the protocol when a block is missed due to builder failure, if only because of the greater real-world latency, it is always possible to “make up” for lost time, e.g., with an accumulative, time-based EIP-1559.

In any case, answering these questions would answer what Ethereum, as a protocol, is or should be. What does it require of its actors? What is its worldview with respect to the economic organisation around protocol duties? What are the boundaries of its concerns?

In the next few sections, I will discuss some of the mechanisms we might consider in our search for Ethereum’s final form.

The space of allocation mechanisms

Keeping the market structure constant (e.g., in two-slot PBS world, the proposer commits to a builder bid and the builder reveals their part after seeing a safe commitment), the space of allocation mechanisms (who gets what) offers rich possibilities.

Whole vs partial block building

The initial goal of PBS, “proposer naivety”, drove the design of a whole block auction, where the proposer lets go entirely of their right to make the block. This whole block auction is the model used today under mev-boost. Yet as we’ve seen, relinquishing entirely the proposer’s input in block construction can lead to mis-aligned preferences over the contents of the block.

With the goal of allowing for proposer expression during the construction of the execution payload, we could determine that the proposer makes one part of the block, while the builder makes another part. It is fairly hard to conceive a block construction procedure where proposer- and builder-submitted transactions are intermingled, so we may restrict the design to two options: proposer prefixes and proposer suffixes.

Proposer prefixes seem easy enough to work out. The proposer’s commitment could come with a block prefix, indicating to the builder a) how much gas they can still spend as well as b) the state root their block must build upon. The downside is that a builder only gets to know these two pieces of information as the proposer makes the commitment, unlike whole block auctions where this data is known as soon as the previous builder reveals their block. This can however be mitigated with the proposer communicating off-band the prefix they intend to make, as deviating from this prefix when making their commitment only hurts the profitability of the builder, who must readjust the block they are building.

Proposer suffixes look more complex. If we intend the proposer to build upon the prefix provided to them by the builder, we need an extra protocol round to make safe the proposer suffix, after the builder’s prefix is revealed. Vitalik suggested a different approach, where the proposer commits first to a list of transactions, which are appended to the end of the block in the order of the list, skipping any transaction already included by the builder and stopping when gas runs out. In his scheme, the proposer commits only to a root of the list, or some KZG commitment, so this may still require an extra step of communication if the proposer is expected to reveal the list eventually. Yet by committing to a list, the proposer has no space to extract MEV based on the builder prefix, so naivety is somewhat preserved.

Block vs slot auctions

This is an orthogonal axis to whole vs partial block building. Here we determine whether the builder must commit to block contents before making their bid, or after.

Block auctions mean the builder has an exact view of the contents of their block when placing their bid. They know precisely how much they are extracting, and make the bid based on the extraction amount. This is the current model used by mev-boost, where the builder forwards their whole block to the relay, which forwards the header to the proposer. The header contains a block root, which does not allow for a different block to be revealed once the proposer’s signature is received.

Slot auctions mean the builder is only bidding for the right to make the block, but not for any specific block. The proposer commitment only determines which builder is expected to release the block, but does not commit the builder to a particular block. This scheme may be more flexible, allowing for “just-in-time” block building based on the certainty that the right is owned by the builder, facilitating cross-domain MEV extraction. The downside of course is uncertainty over the true value of the block, once the state of the world is revealed, i.e., once the state of other domains is known. A builder may overpay, based on a wrong belief that they can extract more once they build the block. Could a winner’s curse scenario take hold? It does not seem possible to continuously have actors in the system operate at a loss, so likely not, but ongoing research on the question is in progress.

Inclusion lists (f.k.a crLists)

A simple way to reassert proposer input into the block construction is simply to declare a block invalid unless it contains transactions which the proposer flags previous to the block being made by the builder.

The “straw man” inclusion list design invalidates the whole block if it does not contain all transactions flagged by the proposer. With this mechanism, a proposer could inadvertently reduce the profit obtained through the builder, when their inclusion list prevents the builder from packing more profitable transactions due to lack of space. This reduces the incentive for the proposer to add anything to their inclusion list, as the rational move (with max profit as a motive) is to keep the list empty.

To go around this, we could instead let a different proposer make the list, for instance the previous proposer makes the list for the current proposer. Let’s call such lists forward inclusion lists. With the straw man inclusion list, this opens the door to griefing, where the previous proposer packs the list and hurts the current proposer’s profit. But note that packing the list beyond what currently sits in the mempool is costly! The previous proposer cannot add phony, gas-consuming transactions to the list for free. EIP-1559 requires the transaction originator to pay at least the basefee to the protocol. Still, what sits in the mempool may be enough to force the current proposer to include a sub-optimal set of transactions in their block.

But we can use EIP-1559 to design a more flexible inclusion list mechanism, where, given an inclusion list IL, either

1. All transactions of IL are included in the block, or

2. The block must be full enough that no extra transaction from IL may be included.

This way, adding a transaction to the inclusion cannot hurt the profit of the proposer: if the transaction participates to the max profit allocation given the gas limit constraint, it is included; if it does not, then the block must be full, since it is always better to include a fee-paying transaction than not.

The question is whether builders can continually censor a transaction by filling their blocks to capacity. Once again, EIP-1559 prevents it. Blocks filling up increase basefee exponentially, until it becomes no longer possible to find enough transactions willing to pay basefee. In addition, the censoring builders stuffing their blocks incur exponential costs.

Censoring-best builders and relays

If making an inclusion list does not hurt your profit, is there still a reason for using forward inclusion lists rather than letting a proposer make the list for themselves?

There is one reason. Censoring relays or builders who must respect an inclusion list could decide to forego relaying or building a block entirely. This is fine when censoring builders are not competitive, which, in a market without private order flows/information asymmetries, should be true, since censoring builders leave fee-paying transactions on the table.

But in the presence of a censoring-best builder, a builder which despite their censorship, builds the highest-paying blocks, this is not fine. In this case, a proposer may not be willing to switch off the censoring-best builder for their block, or to hurt the builder’s profits (which are forwarded to the proposer) by forcing the builder to fill up their block with garbage so that they satisfy the second validity condition of inclusion lists.

To see how forward inclusion lists mitigate this issue and spread the cost of censorship across all proposers, not only honest ones who take the hit, we introduce a simple model of player types in the censorship game. We assume that an inclusion list of censored transactions is given for the current proposer/builder pair, at first without specifying who is responsible for making the list. Proposers may be:

• Censoring: They do not want some transactions to enter their blocks

• Greedy: They will take the max profit block, whether the block censors or not

• Non-censoring: They will require either of the two validity conditions of inclusion lists to be satisfied, given some list for their slot.

While builders may be:

• Censoring: They do not build blocks with some specific transactions contained in the inclusion list

• Non-censoring: They include any and all transactions

Note that builders are all greedy, but censoring builders add more constraints to their optimisation problem. We assume here that there exist a censoring-best builder realising a greater profit than non-censoring builders.

From this simple model, we can determine some properties:

• It may be rational to build or propose blocks which “waste space” by filling up the block, to satisfy the second validity condition of inclusion lists. Indeed, a censoring-best builder could find it worthwhile to pay the basefee for the extra gas necessary to fill up the block, and still win the block auction. Let’s call such blocks stuffed blocks. While this would likely not be a common occurrence, it has the bad side-effect of raising network costs for everyone.

• When the inclusion list applies to the proposer who makes the list, only non-censoring proposers make the list. Greedy proposers do not wish to hurt their profit, and so do not make the list. Censoring proposers do not make the list for themselves either.

• When the inclusion list applies to some other proposer than the one making the list (forward inclusion list), greedy proposers no longer mind making the list. Thus both non-censoring and greedy proposers now bind other greedy or censoring proposers, increasing the “zone of influence” of the list. Proposers making the list (either non-censoring or greedy) still cannot force the hand of censoring proposers, who could prefer to not make a block at all, or make a stuffed block instead if it nets them a positive profit. Still, the economics look much better: Non-censoring proposers incur an implicit cost when a censoring-best builder exists, by shirking the option which realises the maximum profit for themselves. Now, this cost is also borne by the rest of the network.

• When there is no censoring-best builder, only censoring proposers are hurt.

This rough model could be developed further, to provide accurate bounds and dynamics for how revenue is obtained by various players in the game. A work-in-progress is found here, and generally relates to our ROP-2 (RIG open question).

Open questions for inclusion lists

As argued previously, a forward inclusion list model where a previous proposer selects the list for a future proposer seems better suited to a world where a censoring-best builder reigns supreme. There remains implementation questions. What happens when transactions from a forward inclusion list are included by the current builder? How should we select transactions to feature in the list?

In the case of mev-boost, all these questions apply, on top of which we must reason about the incentives due to the optionality of the mechanism. mev-boost is a network of builders, organised around the mev-boost builder client. Nothing prevents the introduction of a new builder client, which may prove to be a dominant strategy for (greedy) builders and proposers to switch to, in particular if profit-hurting constraints are applied to the mev-boost network as a whole.

The mev-boost plan today is indeed for the current proposer to make the inclusion list for their own builders, as forward inclusion lists would induce greedy proposers to switch to a different builder client, e.g., “MEV-boost classic”, without such lists. We must then recognise that we cannot realise the same outcomes with out-of-protocol solutions, as forward inclusion lists only work if they are not opt-in, and the protocol alone can enforce globally such constraints.2

What does PBS value?

After this long exploration of the various ways PBS might be done in- or out-of-protocol, it’s natural to wonder which version is best suited for our purposes. In my opinion, the answer lies in understanding what is gained and what is lost with each version. We’ve hinted at this in a few places before, but what we are really interested in, as mechanism designers for the protocol, is maximising the total value realised, or social welfare.

But what is value? A proper answer to this question requires a lot more work, so we hint here only at some ways the protocol might realise value for its stakeholders:

• The value derived from the execution of user transactions: It is worth $10 to me that I am able to send a payment over Ethereum, and though I may pay a fraction of that, this value is realised once the payment goes through.

• The value derived from holding ETH: Perhaps this is a protocol concern too! ETH is used to secure the protocol, so maximising its value benefits the protocol directly, in addition to benefiting ETH holders. There are disagreements over how this is achieved, relating to the nature of ETH as an asset.

• Other ways?

In this section, we’ll often use what we know about the EIP-1559 mechanism to understand what PBS values and how it realises this value. For instance, EIP-1559 elicits the value a marginal user is willing to pay to be included right now. This marginal user is the “last one” that can make it through while the chain preserves both a burst limit (the 30 million gas limit) and long-term targets (15 million gas per block on average). So what does PBS elicit?

Does PBS really value the MEV in the block? Off-chain agreements between proposers and builders

Here we think of PBS with the whole block auction model. Builders compete over the value they are able to return to the proposer, by making a block satisfying the validity conditions imposed by the protocol. This value really is MEV, the value a proposer would be able to obtain from the special position they hold as temporary leader over the chain’s contents. Or if not the whole MEV, a fraction of it, e.g., the realisable MEV.

This is the intent of the PBS bid: returning to the proposer the value they could extract, but which due to their lack of sophistication or knowledge they are unable to. This value may be quantified. But is that intent always realised? Is the winning bid of the PBS auction equal or close to that value?

Given the assumptions we’ve made so far, it is not the case. A proposer may receive bids at the protocol auction, and decide to forego any of them in favour of a private agreement with a builder. From the protocol’s perspective, it’s equivalent to the proposer accepting a 0 ETH bid and receiving the value somewhere else, for instance via a transaction in the builder’s block.

These situations could happen when the proposer and the builder have a special, trusted relationship. Without the builder submitting a binding bid to the protocol, the proposer may forego their assurance that payment will be guaranteed regardless of the builder’s actions. This could be helpful when the MEV present in the block is very large, and the builder does not have the upfront capital to submit their binding bid to the protocol, but is trusted enough by the proposer. The vertical integration between sophisticated proposers and builders favour such conditions, as Jolene Dunne noted in her Devcon talk Evaluating the PBS Experiment: Early insights from MEV-Boost and the Builder Market.

Understanding these types of off-chain agreements was critical in the study of EIP-1559. When is it to the block producer and user’s advantage to collude, in order to defeat the mechanism’s constraints? In the case of EIP-1559, the effects are particularly severe. Collusion between users and block producers could make the basefee value completely irrelevant, defeating its use as an objective oracle of the current congestion price. In the case of PBS, it could be argued that an objective oracle for current MEV does not bring about UX improvements as important as objective pricing, but this argument relies perhaps on a lack of imagination of what could be done with such an oracle.

Recovering the true PBS value via consensus bids and protocol capture

One interpretation of the EIP-1559 oracle is that it “captures” the value expended by users to compensate for the congestion they create. Without this mandatory capture, inclusion lists would not work, a really nice side-effect coming from the impossibility of block producers to stuff their blocks for free. When the protocol “sees” more, introspection allows for a more resilient system, indeed often as a side-effect.

So how can we make the PBS bid as truthfully revealing as EIP-1559’s basefee? In much the same way: the protocol must capture it. For PBS, solutions include coming to consensus over the highest bid received by the proposer. The proposer is then bound to propose a block corresponding to a bid at least equal to the consensus bid. This consensus relies on a honest majority assumption from the attesters in the proposer’s committee, the same committee making safe the proposer’s commitment to some builder block. The rationale is that if at least half of all attesters in the committee have seen such a bid, the proposer must have, too.

Given a consensus bid, which the proposer must match, off-chain agreements with builders no longer hold. If the proposer’s trusted builder makes an off-chain promise to return 10 ETH to the proposer, but a separate builder sends in a 5 ETH bid through the protocol’s auction, the proposer is bound by the protocol to accept the 5 ETH bid instead. In this case, it would be rational for the trusted builder to make a bid for 5.000001 ETH via the protocol auction, and return 4.999999 ETH to the proposer somehow.

Clearly, the PBS bid was not able to elicit the full 10 ETH value the proposer is receiving from the trusted builder, but this problem is not specific to consensus bids. Generally, in a model of rational builders, a proposer should expect to receive the second-highest bid value, as the best builder only needs to beat the second-best to win the auction. Competitiveness of the builder market then ensures the delta between the best bid and the second-best remains small, with both bids close to the true value of the block.

Given a consensus bid, and so an objective value of the block’s value (assuming again the competitiveness of the builder market), the protocol knows how much value the block returns. What can we do with this value?

• Can we return it entirely to the block’s proposer? If we did so, as happens with EIP-1559, the oracle may no longer objectively report the true block’s value. A trusted builder could bid an absurdly high value to win the auction, with the proposer and builder profit-sharing privately once the auction is over.

• Can we smooth it? This case was also studied for EIP-1559, known as l-smoothing in Tim Roughgarden’s landmark paper. With PBS, this is the suggestion of committee-driven smoothing by Francesco, known as MEV-smoothing, where the value is not smoothed over time across proposers, but across all attesters participating in the slot.

• Can we burn it? This is how EIP-1559 functions today. Domothy recently wrote up a mechanism where the value is captured then burned, known as MEV-burn. The consensus bid is obtained by making some number of proposers compete over who can burn the most, so that attesters need only attest for the proposer with the highest burn. This is a recent proposal, and it is currently discussed to gain a better understanding of its properties and guarantees.

Note that all of these mechanisms implicitly rely on PBS featuring the whole block auction. It is trivial otherwise to use the proposer’s partial block as a way of “hiding” the value in the proposer’s part, which the protocol cannot mechanically capture from.

Can PBS maximise protocol value?

In the previous sections, we assumed the ideal PBS bid represented the whole MEV of the block, and asked whether the bid received in-protocol objectively revealed this value. In this section, we review our initial assumption, and ask whether, even if objectively revealed, the PBS value matches the true MEV of a block.

Latency. The first way this might fail is due to latency. Rounds of communication between builders and proposers, even with fast connections, loses precious milliseconds which could be used to integrate new information, such as newly pending transactions, into block construction. Value may simply be lost by a user who would have been included by the proposer, but didn’t make it in time for inclusion in the builder’s block. Such losses are likely small, as all parties have the incentive to minimise latency as much as possible. Yet the incentive to waste as little time could induce a timing game, the subject of ROP-0, where proposers or builders delay the fulfilment of their duties for as long as they possibly can. This incentive could also induce builder colocation, to minimise round-trips.

Private order flow and value elicitation. The second way it might fail comes from the format of the mechanism. Whatever way the builder block is constructed, a single bid must arrive for the PBS whole block auction. This single bid must be emitted from some entity able to aggregate the value of the separate bundles and transactions it receives from searchers and users. What if the entity is not trusted with the separate order flows it receives? In the example given by Quintus, in this mev-boost repo issue, a monolithic block builder is able to make a bid for 10 ETH. Meanwhile, the dynamics of an auction between searchers mean that a block merging the searchers’ bundles realises a total value greater than 10 ETH, yet the bid expressed is lower than 10 ETH.

This situation clearly points to a failure of market competition at surfacing the true, current value of the block. Efforts towards making order flow non-exclusive would likely recover such value, as would efforts towards distributed builders who could aggregate various order flows towards maximising the value returned.3

Blockspace futures. Another type of economic value which may not be realised is the value unlocked by trust-minimised blockspace futures. The discussion relates to arguments made in the block vs slot auctions section. In the slot auction model, the builder essentially obtains a “one-slot” blockspace future from the proposer, the guaranteed right to build any block for the next slot. No proposer is able to offer such futures for more than one slot ahead, at least trustlessly:

• With “vanilla” in-protocol PBS, the proposer could always renege on their commitment to let the builder make their block at the last minute (though they could stake some money on whether they honour the commitment or not…)

• With PBS featuring “consensus bids”, the proposer might not have the choice over which builder to select, so it is definitely not possible for them to make such commitments in advance.

The question is whether there is much value in obtaining five-slot or ten-slot blockspace futures, vs the one-slot future. Are there economic activities which cannot be conducted without a guarantee over what happens 10 slots in the future? I’m not sure about this one. See also a post from our RIG researcher Julian Ma on blockspace derivatives!

Combinatorial preferences. And finally, we may find ourselves in a situation where a builder cares for either owning the right to make the next two blocks, or none at all. We’re talking here about multi-block MEV, where value is realised by performing operations in two separate blocks. In the single-slot, whole-block PBS auction, a builder may win auction for slot 1, but not know whether they can also win the auction for slot 2. Again there is a distinction between the vanilla PBS and the consensus bids PBS, in that a proposer controlling two slots in a row could make an off-chain promise to a builder for the control of both blocks under vanilla PBS, but clearly cannot honour that promise in PBS with consensus bids.

So in case the auction is truly combinatorial, and builders have preferences over bundles of blocks rather than single-blocks, some value may be lost from not allowing builders to express these preferences via the PBS auction mechanism. Multi-block MEV appears greatly centralising, and combinatorial bids may then be a Pandora’s box we’re not willing to open, yet social welfare (the total value realised) is lower if we are not able to realise this value. Could combinatorial bids for partial blocks be feasible? i.e., mev-geth with bundles spanning two blocks? Would this reduce centralisation risks? IMO some fascinating open questions here!

PEPC: Market structure guarantees for flexible proposer commitments

PEPC (pronounced “pepsi”), stands for Protocol-Enforced Proposer Commitments, a recent post I wrote on ethresear.ch. PEPC is a direct application of the modular framework for PBS splitting it between the market structure and the allocation mechanism. PEPC attempts to provide the market structure without enforcing any kind of allocation mechanism, leaving it up to the proposer to make their own out-of-protocol commitments should they wish to do so. The protocol will only be there to secure these commitments, i.e., ensure the proposer cannot walk back their commitments after observing the builder deliver, letting the proposer to steal from the builder.

The main thrust behind PEPC is to generalise the market structure to more commitments than simply the execution payload. In the near future, some builders will be summoned to produce Danksharding blocks. Later on, we may find it useful to have state providers support block construction and witness computation for stateless proposers. We may also require validity proofs based on a canonical zkEVM to be attached to an execution payload. All such pieces of data will have to come from third-party entities running specialised hardware, potentially inaccessible to the average proposer.

To ensure long-term sustainability of protocol development, figuring out a flexible form of commitment provisioning could help with avoiding to build from scratch a new facility each time a new item is added to the block construction checklist. In its most radical incarnation, PEPC could allow the proposer to control precisely how their block is being made. Parallel execution-builders could be summoned, limited by gas use and a list of state accesses, to ensure compatibility of transaction flows. Block building rights could be auctioned off ahead of time, up to the proposer’s choice (as long as it is known when they are expected to propose, up to 2 epochs in advance).

The way PEPC works is by allowing a proposer to include additional validity conditions to their block, e.g., “the execution payload must be signed by builder x” or “the execution payload starts with prefix abc and is then filled by builder y” or “the block witness is signed by state provider z”. I am hoping we can make use of EVM powers to provide a language to express such commitments, with many questions currently un-answered:

• In the benchmark case of reproducing the PBS whole block auction via PEPC, how should builder promises of payment be represented? Would an EVM “context-aware” transaction allow for conditional payment, based on the existence of a proposer commitment? Can the proposer always be made whole? What does the process look like end-to-end? (see also ROP-4!)

• How far can we go with the commitments? Can we succinctly represent complex commitments such as “transaction 1 is given by builder x, transaction 2 is given by builder y, etc”? Is there a limit to commitment complexity, such as “commitment gas”? Can the fork choice handle discriminating between all partial deliveries of some subset of commitments?

• How does PEPC mesh with protocol-captured value? Can the value received by the proposer be “smoothed”? Should it be anyways?

So what now?

Research continues into the exciting world of PBS. As our lens widens, we also find more focus on the various mechanisms at our disposal, hopefully providing us with the theory we need to evaluate what should be the final form of PBS in Ethereum. In most of what was discussed here, the protocol-side of PBS was emphasised, but distributed building, user-side privacy, smart transactions and other constructions are sure to yield fascinating ways to make the most out of our favourite coordination engine. In the meantime, a strong focus is placed on censorship resistance, to augment the current out-of-protocol market with ways for the proposer to have more control over the block built for them.

Thank you for reading this long post and make sure to check out our Open Problems, reach out if you’re interested to join this collective research effort!

Many thanks to Francesco d’Amato and Julian Ma for comments on the post, and of course to the many people working on and thinking about this topic too!

In a nutshell, the re-org is not expected behaviour of the beacon chain. It occurred due to an unhappy combination of three distinct causes:

• A late block proposal split views of validators due to a recent fork choice update called proposer boost.

• The proposer boost update was released as a soft fork, seen as a local change only that could be rolled out over the network at its own pace. This created a situation where some validators were using proposer boost, and some weren’t, splitting the views.

• A known, incorrect implementation of when the fork choice is expected to be run prevailed in some clients, leading to the persistence of the fault.

Importantly, the re-org did not result in loss of finality. Finality was not even delayed. So we need to be more precise when we talk about what exactly re-orged here.

In the following, we recap’ the basics of Proof-of-Stake Ethereum and look into how the re-org eventually happened.

Proof-of-Stake in Ethereum 101

Proof-of-Stake Ethereum features two consensus mechanisms running in parallel:

• The first, FFG Casper, is responsible for providing economic finality to the chain. Every epoch, “source” and “target” votes from attesters are tallied up. When a checkpoint block (the start of an epoch) accumulates enough target votes, it becomes justified. When a recently justified source is used to justify a target checkpoint, the target checkpoint is justified and the source becomes finalised. The gist is that no conflicting checkpoint block can be also finalised without at least 1/3 of the active stake getting slashed. So there can be no re-org of the finalised chain without a massive loss of ETH by some party. But the present re-org has nothing to do with this part of the consensus.

• The second component, LMD GHOST, aims to provide a dynamically available ledger, i.e., grow the chain while finalisation runs its course. Blocks on that chain accumulate weight bestowed upon them by the “head” vote from attesters. This weight is used to figure out, in the event of a fork, which branch should the validator follow. Because weight is expected to accumulate quickly after a block is released, forks are expected to be rare, and a block that is timely shouldn’t expect to be re-orged.

In PoS Ethereum, time is divided in slots, each slot 12 seconds in length. Each slot, a proposer is chosen, who builds their block on top of what they believe to be the head chain according to the LMD-GHOST fork choice rule (hereafter only referenced as the fork choice). Proposers are expected to release their block at the beginning of the slot, while attesters are expected to release their source/target/head vote 4 seconds into the slot or upon receiving the block from their slot, leaving plenty of time for the proposer to make their block seen by attesters of their own slot.

Despite the buffer, it was recently discovered that a late proposer could maliciously “ex ante” re-org the proposer in the next slot. Meanwhile, proposer boost was suggested to resolve the possibility of split views with balancing attacks, and applied to ex ante re-orgs as well. Using proposer boost, attesters give a weight boost to the proposer of the current slot they are attesting in, in essence preferring timely proposals. We’ll see how this works out in practice in the following.

So how did it fork?

Let’s see how the fork happened first, before we break it down step-by-step. We represent blocks as rectangles while the attestations (votes) are represented as circles, the larger the circle, the more attestations voting for a specific block. You can see the voting weight accumulate over time as blocks receive more and more attestations.

Roughly, blocks 74 and 75 appeared at the same time, creating a fork. A string of proposers made blocks building on 75, while the fork of block 74 was accumulating more weight than the competing branch. Eventually, proposer 82 built on 74, ending the fork at the cost of re-orging blocks 75 to 81. Each step is now carefully analysed to see how this happened.

The fork step-by-step

At slot 73, attesters of slot 73 vote for block 73, which arrived on time. So far, so good.

At slot 74, no block showed up, so attesters of slot 74 are voting for the block at slot 73 instead, increasing its weight.

Blocks 74 and 75 both show up around the same time, at the start of slot 75, as block 74 is late. Proposer boost is designed to give more weight to 75, so that attesters at slot 75 prefer block 75 rather than block 74, since block 75 is timely in their view. However, not all attesters were using proposer boost, so the votes are split almost 50-50.

• Attesters running a client without proposer boost activated prefer block 74.

• Attesters running a client with proposer boost activated prefer block 75.

We can see the split clearly as votes accumulate for both sides of the fork, with non-boosted attesters preferring slot 74 and boosted attesters preferring slot 75. It turns out that slightly more attesters didn’t have proposer boost activated, so the upper fork has slightly more weight than the lower fork.

Now the question is: given that block 74 had more weight than block 75, why did proposer 76 build their block on top of 75?

The reason is subtle and has to do with a client behaviour that is updated at the moment. Proposers are expected to run the fork choice before proposing, set at the time of their slot. However, the proposer at 76 was using the fork choice computation they ran set at the time of the previous slot. Proposer boost applies to the proposer of the current fork choice slot. Hence, proposer 76 was incorrectly boosting proposer 75 in their view of the current head, and selected block 75 as the parent of their block. From the point of view of proposer 76:

Attesters on 75 + Proposer boost on 75 > Attesters on 74

Meanwhile, attesters at slot 76 keep splitting their votes between the heaviest chain without the boost (with head block 74) and the heaviest chain with the boost (with head block 76).

The scenario repeats until slot 81. Notice that all attesters from slots 75 to 81 who are not using the proposer boost keep voting for block 74, increasing its weight.

Finally, a proposer comes in who does not apply the proposer boost on the previous slot to decide where to build their own block. Proposer 82 sees block 74 as heavier than block 81. While block 81 inherits the weight of all blocks behind it, remember that there is always slightly more attesting weight voting for 74 than for any of the blocks 75 to 81…

There is no confusion for attesters at slot 82 here:

• Those who do not use proposer boost clearly see 82 as winning, for the same reason why block 82 built on block 74: block 74 is heavier than block 81.

• Those who use proposer boost even more so see block 82 as winning. The votes are no longer split.

Finally, the chain resumes its course, with proposer 83 building on block 82. By this point it is clear that blocks 75 to 81 have been effectively re-orged.

Takeaways

The re-org highlights a failure case of the dynamically available chain, one that is in the realm of the theoretically possible but practically unthinkable, much like long re-orgs in Proof-of-Work are possible but rarely seen in practice (barring adversarial behaviour). So it is important to recognise that contributing factors to the present re-org are purely accidental:

• A late block can always happen, there is no way around that. The dynamically available chain is in principle designed to deal with this eventuality fairly, so that more timely proposers see their blocks accepted in the canonical chain.

• But it is clear that even changes which appear to be “local only” (as the fork choice computation is) need to be considered in the larger picture of the consensus. Ethereum protocol researchers have become familiar with the idea of “split views” between validators, where one set of validators sees something locally and another set sees something else, and how these split views can contribute to delaying liveness. It should have been recognised that an uneven rollout of proposer boost had the potential to create such a split view. It was made even worse by a known implementation fault.

• The issue would not have happened were all validators running the same configuration! In particular, it would not have happened post-Merge, as all validators must hard-fork to the Merge updates previous to the Merge, or be entirely kicked out of the consensus.

PoS Ethereum is a hybrid consensus, designed for robustness in adversarial environments. A recent thread by Sreeram Kannan highlights well the challenges that come with it:

Known limits of the consensus, also mentioned in the research Sreeram links in his thread, are driving protocol changes. While it is deeply unsatisfactory when such failures occur, they do not (in my own opinion) invalidate the approach that Ethereum is taking. But they do ask us to tread carefully, and create a protocol that is not only robust in theory but also in practice.

Many thanks to all the researchers and developers who helped make sense of this issue. Specifically, Paul Hauner detected the re-org within minutes, then triaged and diagnosed the cause of the issue over the next hour in a group chat with other consensus client developers. Thanks to Martin Köppelmann for publicly raising the issue, Jacek Sieka for providing me with data supporting the present analysis, Potuz for his own analysis, Terence Tsao for his thread that quickly gave insights to the community, Michael Sproul for additional data, and Caspar and Francesco for their whiteboarding skills on a late Wednesday evening.

Diagram plotting code available here.

Lately I’ve become interested in understanding rollups from an economic perspective. This is not just a theoretical concern. Fees on the base layer (L1) are high and we should aggressively work on providing spaces where users can transact at an affordable rate. Better economics means better pricing means happier users.

So how should we think about rollup economics specifically? We’ll first identify the parties interacting in the rollup system, their roles and responsibilities. Once done, we tease out various costs, revenues and fees irrigating the rollup system, offering us clues on how to navigate this wide design space.

Since writing this piece, I presented more about Rollup Economics at EthCC in 2022. Find the video here!

And now, back to the piece…

Players in the rollup game

For simplicity, we’ll idealise three distinct roles:

• The users: Users send their transactions on the L2 network as they would on L1. They own assets on L2 and interact with contracts deployed on the rollup.

• The rollup operator: This role subsumes many others. The rollup operator represents all the infrastructure necessary to process transactions received on the L2 network. We have in reality sequencers publishing transaction batches, executors posting assertions, challengers reporting fraud proofs, provers computing validity proofs (see also here for details)…

• The base layer: A protocol securing the data published by rollups. It is enough to consider a protocol that guarantees data availability with reduced functionality for settlement (e.g., “template” bridge contracts deployed on their execution layer) but you can also think of a general purpose settlement engine, like Ethereum’s.

Rollup costs

In this post we adopt a “systems” view of the rollup, focusing on costs, revenues, and fees. Running a system induces costs, which are “energy sinks”, value flowing from inside the system to outside. The system might also receive revenues, which are the opposite, “energy sources”, value flowing from outside the system to inside. Fees bridge sources to sinks, transfer value throughout the system components so that each performs its function appropriately.

For instance, in a previous piece on EIP-1559, I explained how to decompose the transaction fee paid by the user:

• Some of the fee goes to the operator including the transaction: in the Proof-of-Work base layer case, the miner fee compensates miners for the increased uncle risk. This fee makes whole the operator for the cost of publishing the block. This is the 1 or 2 Gwei you default to when sending a transaction today.

• The rest of the fee pays for the right to be included before others, pricing congestion. This fee makes whole the network and its users who suffer from your extra bit of congestion. This is what the L1 basefee aims to be, under normal conditions.

The good news is we will use some of the same thinking to understand costs on rollups. EIP-1559 costs involved only two parties: the user and the base layer. With a different architecture and the operator sitting between the user and the base layer, we must disassociate costs specific to the operator from costs specific to the base layer, which we do in the following sections.

L2 operator costs

Rollups must find operators willing to expend the computational resources to process the rollup data, i.e., maintain a transaction pool, sequence batches, compute state roots/state diffs/validity proofs, etc. This is a tangible cost, quantifying the dollars and cents necessary to run the infrastructure behind operators.

L1 data publication costs

It’s worth spending time on the data publication cost as this is truly the new cost in the rollup economy. Once an operator has assembled a large enough set of transactions, they are expected to post a compressed summary of the set to the base layer. Today, it is not done in a particularly elegant way: data is published by simply posting it as “CALLDATA”, a transaction attribute which allows the sender to add an arbitrary sequence of bytes.

Typically CALLDATA holds the reference to the smart contract method called by the transaction, with the inputs to that method. It may be helpful to think of rollup operators as calling some “registerCompressedData” method of the L1 “rollup chain” smart contract, with the blob of bytes representing the compressed transactions as its argument. Here is an example from Optimism’s “Canonical Transaction Chain” contract.

The cost of publishing data is incurred by the base layer. To publish data on Ethereum, the current market price of data is governed by EIP-1559, where each non-zero byte of CALLDATA consumes 16 gas, while each zero byte consumes 4 gas. With multi-dimensional EIP-1559, e.g., as instantiated in Vitalik’s simple Sharding-format blob-carrying transactions, the price of CALLDATA could be found on its own EIP-1559 market, pricing the data market separately from the traditional execution market.

In this Dune analytics dashboard, I tried collating the data published by a few major rollups. It’s not clear to me that I am capturing all of it, especially for zk-rollups. If you notice discrepancies, please let me know! :)

See also Aditi’s recent post Ethereum Rollup Call Data Pricing Analysis and L2fees.info

L2 congestion costs

There is a third, more intangible cost. Whenever the supply of rollup blockspace cannot address existing demand, scarce resources must be allocated. Included users are included to the detriment of users who are not. In a spherical cow world of time-insensitive users, users simply queue and wait for their turn. There is no loss of value from a congested system. But when users incur costs for waiting, they will attempt to minimise their delay as much as possible. For users at the back of the queue, their welfare decrease is a cost on the rollup system as a whole.

It is typical (at least in the Ethereum world) to rely on fee markets to operate this allocation, making this cost explicit.1 Without a fee market or some form of congestion pricing, users either “pay in time” (are included later), bribe block proposers off-chain for inclusion or repeatedly resend their transaction to guarantee one of them will be picked up from the mempool. In all these instances, users express their loss of utility from congestion by expending resources to prevent this loss.

Rollup revenues

Now that we are clear about the costs of a rollup, we’ll try and reason about system revenues. Here we distinguish two main sources: transaction value and issuance.

Transaction value

Users obtain some value from transacting on a rollup rather than elsewhere, and are thus prepared to expend fees for the services they obtain. Value here refers to the utility a user obtains from having their transaction included on the rollup. If I have $50 utility for inclusion, I am willing to pay up to that amount so that my transaction is included. If I end up paying $2, my surplus is worth $48. The revenue of whoever receives the fee is $2, but from the rollup system perspective, the initial inflow is $50 worth of value.

Second, whenever the transaction contains positive MEV, e.g., the transaction is a sandwich-able swap on some DEX, this quantity is added to our notion of transaction value. It does not matter at this point who receives this value, whether it’s the sequencer extracting the value, a user sandwiching the transaction or something else. The only thing that matters here is that our initial transaction brought more value to the system as a whole than the original user would receive from it. This gives us:

Transaction value = User value + MEV

Issuance

A second source of revenue is issuance. On the base layer, block producers receive revenue in the form of newly-minted coins, issuance of the cryptoasset native to the network they help maintain. This revenue offsets their infrastructure costs, with more block producers joining as long as it is profitable for them to do so.

Assume a rollup is able to mint their own token, and this token has non-zero value. The rollup may pay for some of its operations by issuing new tokens to cover its obligations. Here the model is fuzzier, with various ways of spending that revenue source on the rollup costs. For now, let’s only consider that it is possible to issue valuable tokens, and by this act bring more value into the system.

Pass the buck: rollup edition

Summarising, a rollup system includes three parties: the users, the rollup operators and the base layer. Running the system incurs three types of costs: running cost of operations, data publication costs on the base layer and congestion costs. The system receives revenue in two forms: transaction value and issuance.

Now it is simply a game of matching who pays for what, and when. Some pairs are easy to dispatch. The operator must pay the L1 data publication fee to the base layer. They must pay for it exactly when they publish the data, and at the rate quoted by the base layer.2

When fees are dynamic, priced in a fee market, L2 congestion costs are also immediate. Users observe the current demand for rollup blockspace and adjust their fees given the available supply. For instance, rollups may want to deploy an EIP-1559-style market mechanism on top of their network to govern inclusion of L2 transactions. An L2 basefee is then available to enable easy estimation of current L2 congestion costs by the users.

Budget balance: a limit to passing the buck

Let’s add a new constraint to our system, operator budget balance. We assume that the rollup operator cannot operate at a loss, i.e., they must at least receive a revenue equal to or greater than their costs. This assumption may not always hold, yet it appears critical to me if we care about a sufficiently decentralised and open set of operators in a future where operators are decentralised. Operators who operate at a loss may price out less well-capitalised players and restrict the set of operators.3 A smaller set of operators decrease censorship-resistance guarantees, where in the worst case a user must force include their transaction via the base layer, incurring high fees.

Issuance comes in handy as a slack variable to ensure budget balance. Whenever operators are “too unprofitable”, they leave the system, increasing the share of issuance received by remaining operators until balance is achieved again. Similarly when operators are “too profitable”, new entrants compete to eat a share of the profits until operators are once again budget-balanced.

Maintaining operator budget balance with delayed payments

With the budget balance rule, we must consider how operators maintain a non-negative balance. Their principal outflows, L1 data publication fees, are variable, and charged separately from their principal inflow, transaction fees. We make the assumption that operators have perfect knowledge of their L2 operator costs, and quote an exact price for it to the user at transaction time (akin to their knowledge of uncle rates and the corresponding miner fee compensating them). But how should they quote users for the eventual L1 data publication cost, realised later in time?

Today, rollups apply heuristics to hedge themselves against L1 data publication cost variability. In one instance, the rollup observes the current L1 basefee (thanks, EIP-3198!) and pad the rate with an extra buffer, overcharging the user early in case operators must pay more later to publish the data. In another, users are charged a function of the L1 basefee’s running average, to even out fluctuations over the long term.

In my view, the natural solution is to invoke derivatives, e.g., simple L1 basefee future contracts. At transaction time, the user is charged a fee defraying the cost of locking in a future price for the publication of data on the base layer. By reducing pessimistic overpayment, savings are passed on to the users. Investigating the optimal design of such derivatives remains an open question.

What to do with congestion fees?

Assuming the rollup perfectly prices the cost of congestion when users transact, there is now revenue available in the form of congestion fees. Today, on the Ethereum base layer, these fees are burned. The first reason for doing so is incentive-compatibility: should congestion fees return to the block producer, the protocol-quoted basefee would no longer be binding, destroying the purpose of EIP-1559. But burning is not the only option preserving incentive-compatibility.

It has been proposed to direct all “rollup exhaust”, fees arising from economic externalities, e.g., congestion or MEV, towards public goods funding.4 This is not a bad solution. Congestion pricing in cities is typically ear-marked for improvements of the public transportation system, i.e., it is money spent on compensating for the negative externalities which, when priced accordingly, provide this revenue.

Notice that I slipped MEV in there… why should we think about it the same way we think about congestion fees? First, because like congestion, MEV is an externality. The simple act of emitting an MEV-carrying transaction creates a positive externality to those who can capture it.5 Externalities are “unmatched value”, i.e., they arise from some original economic activity that balanced useful work with payment for that work (e.g., users pay for the L2 operator costs; operators pay for the L1 publication costs), but they produce or destroy some extra bit of value in process.

This is most clearly articulated in the concept of MEV auctions. In this design, operators compete for the right to make a block based on how much value they can extract from it. Implicit in this notion of value are congestion costs, which users express by bidding against one another. More explicit is the MEV itself, which would-be operators compete on. Once again, assuming no operator is allowed to operate at loss, their bids must reflect their true capacity of extracting value from the block, i.e., an operator would bid the sum of user fees in their batch plus the MEV they extract from the batch. Meanwhile, assuming all operators must pay an equal amount in L2 operator costs and L1 data publication costs are charged precisely to the user, we obtain:

• User fee = L1 data publication fee + L2 operator fee + L2 congestion fee

• Operator cost = L2 operator cost + L1 data publication cost

• Operator revenue = User fees + MEV

• Operator profit = Operator revenue - Operator cost = L2 congestion fee + MEV

In a world where operators compete in an efficient market to win the right to propose a block, the operators must bid away the entirety of their profits, i.e., exactly the congestion fees and the MEV available in their batch.6 This is value that “slipped” into the system: the first from users protecting against losses due to congestion, the second from ripple effects caused by the initial transaction. This value was never anyone’s to begin with, so why shouldn’t it be captured and redistributed somehow?

Unboxing

Many assumptions were made in the piece. For instance, I have assumed “operator budget balance”, as I believe the community should consider rollups who operate at a loss with a critical eye, potentially less decentralisation-ready. Issuance helps to re-establish budget balance, though it relies on an exogenous price signal (the token value) to harmonise operator incentives. In this view, it remains preferable for operators to price as precisely as possible what they can price, e.g., their L2 operator costs and L1 data publication costs. This avoids future revenue mismatches, where an operator expected a higher token price to cover their operations.7

But this is not a call to advocate for a specific form of rollup economics. The design space remains wide open. Unboxing L2 operator costs reveals more complexity that we haven’t explored here, e.g., the market institutions supporting a decentralised infrastructure to generate validity proofs for zk-rollups. Focusing on specific types of users on the rollup, e.g., fast withdrawal services from L2 to L1 or cross-L2 bridges, would also reveal different facets of user demand. With clear ideas about costs, revenues and fees, it is now hopefully easier to reason about the outcomes and business objectives a rollup should achieve, and the means to achieve them.

Other resources

• John Adler’s Wait, it’s all resource pricing? (slides, video here) gives more context to the L2 operator costs and the separability of execution and data availability costs.

• Patrick McCorry, Chris Buckland, Bennet Yee, Dawn Song, SoK: Validating Bridges as a Scaling Solution for Blockchains

Many thanks to Anders Elowsson, Vitalik Buterin, Fred Lacs and Alex Obadia for many useful comments, and Michael Silberling for his insights and discussion.

The short hiccups are worth dissecting to understand better how the beacon chain, a complex system driven by thousands of separate entities around the planet, behaves under and recovers from momentary lapses of reason. We'll see that even though its heart rate dropped significantly, the system was able to pump enough blood around to keep itself conscious throughout.

The efforts to find the bug are well-detailed in the Prysmatic Labs team post-mortem report, a recommended read for the full picture. To provide more background, this is the “Root cause” section of the report:

Eth2 is loosely coupled to the ETH1 chain, depending on it only for validator deposit verification. That is, the Eth2 proof-of-stake chain can continue even if validators are voting on junk data. The only thing that will fail is the onboarding of new validator deposits until the chain votes on the correct ETH1 data once again. This “voting” is done in “voting periods”, which are set to periods of 64 epochs on mainnet today (approximately 6.8 hours).

The way voting works is a simple majority rule, and the Eth2 specification for validators explains how this should work. Unfortunately, Prysm’s implementation of “voting with the majority” was missing some validation. What happened in the incident was a bug within Prysm led a block proposer to create a completely invalid ETH1 deposit tree root, and other Prysm nodes were the first to see it. Then, they would vote on it as Prysm was following a simple “voting with the majority” rule without explicit validation.

The effect of all Prysm nodes then “snowballing” into voting on the invalid information led to block proposers unable to include blocks with deposits in the chain, as the proposal would fail due to the deposits not verifying with respect to those nodes’ idea of the ETH1 deposit tree root. The incident resolved itself after the end of a voting period, but would continue to happen once more if left unanswered.

The actual root cause of the “corrupted” ETH1 data deposit tree root was due to a bug in the cache initialization for deposits affecting only a subset of beacon nodes using Prysm. This led those nodes to produce bad deposit tree roots, which then other Prysm nodes voted on, causing the incident.

In this post, I’ll look at three charts plotting the course and consequences of the client incident, drawing lessons on the behaviour of the protocol.

Prysm clients stop proposing

With a simple analysis on the graffiti included with beacon chain blocks, we can get a rough idea of the client software used by validators to build their blocks. By default, Lighthouse, Nimbus and Teku all include a graffiti string with their name and version. Prysm simply defaults to the empty string. We can also look up POAPs in case some validators still use those. This gives us the following picture:

The column height indicates how many blocks each client proposed each epoch. Prysm is very much the dominant client on the network today, and it’s easy to observe the difference in blocks starting from epoch 32302, even among blocks that were tagged “undecided”. On beaconcha.in too we see blocks missing from this epoch onwards.

Delayed inclusion

On the beacon chain, validators are expected to produce votes indicating their view of the network, including the FFG source and target checkpoints as well as the current head of the chain, returned by the LMD-GHOST fork choice. Each validator is assigned one attestation slot per epoch, for which they are expected to produce an attestation. Once the attestation is broadcasted, it can be included at least one slot after the attestation slot, and at most 32 slots after.

In the figure below we plot the average inclusion delay of validators in red. This average tends to hover around 1: most blocks are proposed, so validators are included as soon as possible.

Past epoch 32302, the inclusion delay clearly increases, with validators needing to wait a longer amount of time for their attestations to be included.

One might ask: “Validators had to wait because blocks were unavailable, but once blocks were produced, were they included?” In green we plot the average minimal inclusion delay, where we count how long an attestation had to wait after a block was proposed. In general, this number is 0, since attestations are included as soon as a new block is available. After epoch 32302 though, this number significantly increased.

This is noteworthy since it could be the case that stranded attesting validators would get on the first available lifeboat (block) once that boat is ready to ship, but it’s not what happened. Instead, some validators had to wait several lifeboats before boarding and being included on-chain.

The block at slot 1033704 is one of the first blocks proposed during the incidents, coming after a series of 10 missed blocks in the slots prior. The block contains 128 aggregate attestations, the maximum a block can include. Each aggregate synthesises the votes of a slot committee, among which validators attesting for a slot are partitioned. There are now around 30 committees per attesting slot, so a block appearing after 3 missed blocks can barely include all aggregate attestations the 3 missed blocks were supposed to include (3 times 30, one per slot committee), plus its own (30 more). A block appearing after 10 missed slots has a lot of catching up to do.1 As a consequence, some validators reported missed attestations, having been unable to board before 32 slots went by.

Lost profits

As seen in the previous section, the chain was stressed, lifeboats were full, yet finalisation never stopped (the chain typically finalises as long as 2/3rds of the stake is online and included). This is excellent, and strong evidence for the robustness of the protocol. Yet block proposers who were affected by the incident lost block proposing rewards, which are a significant, if infrequent, share of validator rewards. Online validators who could not get on a lifeboat in time also lost a small share of rewards.

We can get a better idea of the loss incurred by looking at the net difference in balances between each epoch during the incident. We only chart it for the first occurrence here.

The height of the column indicates the net profit earned by all validators at the end of each epoch. The protocol either mints rewards for validators who performed their duties and were included, or decreases the balance of validators who failed at either. Adding up these rewards and losses we obtain the chart above.

The white area between epoch 32302 and 32320 gives us a rough idea of the profit loss by validators. It is hard to get a fully precise number: we ought to know which validators were online and validating but were unsuccessful at being included to write down the loss as caused by the incident. So taking the few epochs net profit prior to epoch 32302 yields a baseline of around 3.93 ETH per epoch. Summing up the differences between this baseline and the realised net profit between epochs 32302 and 32320, we get a good estimation of the loss, which adds up to around 15.9 ETH, or around $40,000 at $2,500 ETH/USD.2

Closing thoughts

Major credits go towards the work of the Prysmatic Labs team and researchers who tracked down the issue and fixed it in a timely manner. Fortunately, finalisation continuing despite the reduced number of produced blocks prevented the quadratic inactivity leak, which incurs more severe penalties on validators failing to be included.

Yet it’s also important to recognise limits of the protocol. As we’ve seen, each slot provides the opportunity for 128 aggregate attestations to be included, and we have 32 slots per epoch, so 4096 opportunities to include aggregates per epoch. If a fraction f of blocks is missing, we are reduced to 4096 * (1-f ) opportunities. Since each slot committee targets a membership of 128 validators, for N currently active validators we have ~N/128 committees per epoch, who must fit within 4096 * (1-f ) opportunities. With the current numbers, we are running out of opportunities as soon as over f = 75% of blocks are missing. With Prysm’s dominance among validator clients, we got close to this number during the incidents, and sometimes even above, so some attestations were left behind.

At the risk of repeating an oft-heard refrain, client diversity matters. All of the four major eth2 clients have produced excellent infrastructure, and it’s worth giving a shot to another one of them if you haven’t yet.3 Check out for instance Michael Sproul’s guide to setting up Lighthouse, read about Nimbus's latest optimisations from Jacek Sieka or Teku’s Ben Edgington’s own take on client diversity. Their respective Discords and the folks at EthStaker are also here to help!

Many thanks to Danny Ryan for comments. All code used to obtain the data and plots available here.

Subscribe to this (infrequent) newsletter to read more about Ethereum, incentives and in-depth analysis

Subscribe now

This is the road to Ethereum. Ethereum today is what eth2 developers are calling “eth1”, the current Proof-of-Work (PoW) chain that we all know and love. Ethereum tomorrow isn’t eth1, nor eth2, it’s just… Ethereum: a synthesis of eth2 efforts at deploying Proof-of-Stake (PoS) and sharding on top of today’s execution layer.

Word soup. Let’s backtrack. This is today.

Users want to do things (“transactions”), so they send their transactions to miners, who package them nicely into blocks and add their blocks into an ever-growing chain. Miners run the PoW consensus mechanism1 to decide who’s next to add a block, and also execute transactions contained in the block to make sure they are valid.

PoW requires a large mass of hardware running intensive computation, incurring exorbitant energy consumption. We’re not going to talk about waste in the sense that most cryptocurrency critics intend (“why would we need a payment system that uses <country>’s energy??”) but really waste in the sense that if we can do something with a strictly smaller absolute number of kWh, we should.

So enter Proof-of-Stake, replacing large swathes of mining rigs with one smol server, and replacing miners with validators.

So what is 2.? What are validators validating exactly?

Consensus layer ensures everyone agrees on the correct data. Execution layer actually interprets this data, makes it meaningful. “Data” is any kind of interaction with the blockchain, e.g., deploying a contract, doing trades on an exchange, sending a payment etc…

The heartbeat of a blockchain is the introduction of a new block in the chain. When that happens, there is a state transition between the state before the new block and the state after. The state summarises the whole bunch of data that came previous, between blocks 0 and N.

For instance, if the state keeps a ledger with Alice and Bob’s balances, and the new block contains a payment from Bob to Alice for 10 coins, the state after the block will have the new balances. The dashed blob on the right of the “State after block N+1” bubble shows that a new block might either modify existing state (e.g., Alice and Bob’s balances) or create new state (deploy a new contract, or adding Carol to the ledger…)

The general gist of rollups and eth2 efforts tackle point 1. of our plan, decorrelating consensus and execution. So how’s that going?

Since December 2020, we have two chains running in parallel:

• At the top, the PoS-consensus chain (a.k.a., beacon chain)

• At the bottom, our ol’ reliable PoW-consensus+execution chain (a.k.a., “eth1”).

They run parallel, but they talk to each other. Well, it’s pretty one-sided at the moment…

To become a validator on the PoS-consensus chain, a user on the PoW-consensus+execution chain locks up 32 ETH in the deposit contract, which is automagically transposed to the PoS-consensus chain. Once the validator is activated, they can start validating and receiving rewards.

This one-sided conversation hopefully won’t last long. The Merge bridges the gap between the PoS-consensus chain and the PoW-consensus+execution chain permanently, allowing validators to produce blocks for the execution layer. After the merge, we therefore have two chains:

• The same PoS-consensus chain

• A PoS-backed-execution chain (f.k.a, “eth1”)

When this happens, validators of the PoS-consensus chain will finally be able to redeem and withdraw their earnings and deposits, sending them back onto the PoS-backed-execution chain.2

All that in itself gives us the move from a PoW environment to a fully fledged PoS environment. But notice that it doesn’t quite increase the bandwidth of the chain—how much execution a block is packing—, which is the goal of sharding. Before we get to that, let’s talk about other ways to scale execution if we only have one execution chain.

Enter rollups, one of the myriad scaling solutions available, but perhaps the one offering the most optimal trade-offs from a protocol design perspective. The idea is simple: synthesise state transitions by committing on-chain to data necessary to recreate the execution of the state transition, and push execution off-chain. If anyone has a problem with the execution result, or if someone forgets to execute in the first place, the data is there for all to process. Permissionless!

To be more precise, the data necessary for execution (transaction inputs) is separated from its containers (transactions) and “bundled” in a space-saving manner. Meanwhile, rollups run besides the execution chain, committing to the data and executing it.

To “get on a rollup”, users deposit assets in the rollup’s contract on the execution chain (“eth1”), then they do stuff on the rollup, such as trade them with other assets also on the rollup. Once they are done, users withdraw assets back from the rollup onto the execution chain. Voilà.

What is the alternative to rollups? Well, what if instead of having these perpendicular yellow chains, we had a bunch of parallel red chains? As in, what if the eth1 chain was “duplicated” and several instances were running side-by-side?

The issue here is how we deal with several execution chains running in parallel. What if something happens on a chain that another needs to know about? This is pretty much the thorny problem of sharding, or dividing execution between multiple chains.

“Rollups aren’t so different!” you will say, and in essence it’s true. When you want to do something on another rollup from one rollup, the same thorny questions arise. The point however is that several rollup designs exist and the space of solutions is wide and mostly unexplored. So why not let rollups bootstrap experimentation before enshrining one approach at protocol-level?

This leads us to……

So you heard about block space scarcity did you? Rollups do need to publish their data, and eth1 block space is rare! Plus as we discussed, cross-shard stuff is hard. So to make lemonade with our lemons, why not use the shards to hold the data that rollups critically need to publish? With 64 shards, that’s 64 times the bandwidth available now, and possibly more as one shard block would likely hold a much higher amount of data than the eth1 chain blocks currently can.

It should be emphasised that this doesn’t mean execution at the shard level is forever excluded. The rollup-centric Ethereum is a short-to-mid-term way forward, until (for instance) better cryptographic primitives are found to guarantee correct execution sharded across multiple chains. It’s all very fascinating and should keep a lot of people busy for a long amount of time. In the meantime, rollups are the way.

There’s plenty more work on that side! First let’s not forget the Merge and data shards are extremely complex endeavours with multiple teams working on either or both at the moment. But even on the rollup side, there are still some extremely juicy questions that are left to explore, and these are but just a few.

• Mass migration of users to and from rollups is a very cool concept. Why should you take your own car to go between Layer 1 (eth1) and Layer 2 (rollups) if you have frequent enough public transport shuttling you to and from? What are the economics of this?

• What if you’d like to do something on a neighbouring rollup, because they have something cool that yours doesn’t have? Should you necessarily move from your rollup to L1, and then from L1 to the neighbouring rollup? This seems rather wasteful.

• Rollups are a massive improvement in bandwidth for current operations, there is no question about this, yet rollups aren’t the infinite highways users seem to expect. There is still a lot of people wanting to do a lot of stuff, sometimes at the same instant! So rollups will naturally have to deal with congestion, but contrary to the L1 protocol enshrining a particular congestion market (soon, eip1559), rollups have a much larger design space to explore.

• Speaking of congestion, and this is more protocol-specific, but we’ll also see eip1559 playing traffic cop to regulate how much data is published on every data shard, ensuring validators can cope up with the amount. If you thought one eip1559 mechanism was cool, wait until there are 64 running. So where should rollups publish their data? On one shard only to make it accessible without shard-hopping for whoever is listening to it? On multiple shards to take advantage of the planned shard staggering, where shards publish a new block in turn, such that you are never more than a couple hundreds of milliseconds away from a new block to publish your data, ideal for quick-finality applications?

Many thanks to Danny Ryan and Sacha Saint-Leger for their suggestions.

Crystal ball predictability

Before we start, let's immediately rule out predictability as the ability to estimate what the fee will be 1 block, 5 blocks, 10 blocks, 1,000 blocks from now. Such predictions are more “macroeconomic” in nature, as they rely on analysing the demand for transacting on the Ethereum network and future changes affecting the supply of gas (e.g., eth2, rollups etc.)

To some extent, eip1559 gives us bounds on how much the basefee varies over some number of blocks. At an update rate of 12.5% maximum, the basefee doubles every 6 blocks assuming these 6 blocks are full. This is a guarantee that the basefee will not increase past a certain value in a given amount of time, but it still does not tell us what the entry price will be.

Inclusion predictability

Let's try this definition: we care more about predicting inclusion given some bid made by the user. What does this mean in the current system?

A user bids some gas price with their transaction. Given the (changing) environment of the fee market, the gas price is a parameter to some random variable denoting inclusion delay. So given the gas price bid, the user should expect to be included after some number of blocks. The delay is zero when the user is included in the next block. The game is to predict how long the delay will be given the gas price offered.

What can we tell about the inclusion delay? It turns out, not much. One thing that seems natural is that a higher gas price should never harm your chances of being included, so if Alice bids less than Bob, Alice should never be included before Bob. A gas price of zero should give you infinite delay. A gas price of infinity should give you zero delay.

These are all nice mathematical facts, not so useful in reality, but pretty much the only things we can tell for sure. Let's be more concrete.

At any point in time, we have a collection of pending bids, ordered from highest to lowest. This is the observable demand curve. The top bids up until 12.5M gas will be included in the next block.1 Maybe your bid places high enough in that list to be included. Maybe more bids come in the meantime and you are pushed out of the top of the list, and not included, but once these top bids are included, you are at the top again and you are included one block later, etc etc.

In other words, there is some distribution over the possible outcomes: included now, included a block later, included two blocks later... We can sort of guess this distribution by looking at the current bids and perhaps how bids have evolved in the recent past. This is what most oracles do.

eip1559 improves on this paradigm by quoting the correct cut-off price. We spent some time looking at how eip1559, and the basefee in particular, achieve pricing the variable congestion observed on-chain. This study led us to break down eip1559 into three different cases.

We'll call effective demand the amount of gas demand by users who are willing to pay at least the basefee plus the miner fee. There are three cases worth taking a closer look at:

1. Undertarget: The effective demand is lower than the gas target.

2. Overtarget: The effective demand is higher than the gas target, and lower than the gas limit.

3. Overfull: The effective demand is higher than both the target and the limit.

At most points in time, when blocks are under- or overtarget, we are guaranteed to be included in the next block by following the simple bidding strategy of paying the fixed 1 Gwei miner fee on top of the basefee. Case closed. Overfull blocks is the bad case: there are too many users who could potentially be included in the next block, in spite of the current basefee level. Scarcity!

So with 1559, we’ve reduced the space of salient outcomes to pretty much two:

• Either we are included at the quoted basefee + miner fee,

• Or there is enough effective demand to push us into the overfull case.

The bizarro fee market

What are the bad things that happen in the overfull case with eip1559 activated? It turns out, bad things in the overfull case still seem less bad than they are in the current paradigm. We’ll do a thought experiment where we imagine the demand, the users and everything are the same in two parallel worlds, except one world uses the current fee market while the other has activated eip1559.

First, note that because blocks can double in size, there are situations where we are priced out of the current fee market, which don’t happen under eip1559, since the block slack allows for our inclusion. So there isn't a strict equivalence between being priced out currently and blocks being overfull in eip1559. In other words, in the eip1559 world the block is overtarget, but not overfull, so we are next-block included, no scarcity, everything worked out; yet in the parallel, current fee market world the inclusion delay is greater than 0. That’s a net win.

Let's look at a worse case, one where we are both priced out in the current fee market, and we might not be next-block included in eip1559 world (equivalently, we are not next-block included in the current fee market world and we are in the overfull case in the eip1559 world).

In the current fee market world, let's assume an all-knowing oracle quotes me the exact cut-off price at the time of my transaction, i.e., the gas price in the ordered list where transactions bidding above that gas price are exactly enough to fill a block. All I have to do to get in at that exact instant is bid above the cut-off. Let’s say that cut-off is 100 Gwei, so I bid 100 Gwei.

Bad luck: a bunch of users are doing the same, right after I place my bid. They are bidding randomly, sometimes above my bid, sometimes below, meanwhile the all-knowing oracle picks this pattern up and starts quoting a higher cut-off price, higher than my bid is (110, 120, 130, ...), because the list gets longer and the bids at the top get more competitive. For a string of blocks there is enough sustained demand of users outbidding me, while I wait.

But maybe I didn't mean to bid so low! Rather, if I knew I wouldn't be included with my initial bid, I might have wanted to revisit it slightly higher than I sent it, maybe to 150 Gwei instead. I can still do that, of course (replace-by-fee), but it means I am sitting in front of Etherscan or Metamask and monitoring my transaction all this while.

Overfull blocks in eip1559

How does eip1559 improve upon this pattern? Transactions sent in eip1559 world have two parameters:

• The maximum fee: the most I am willing to pay.

• The inclusion fee: meant to carry the miner fee, with or without the strategic fee.

The maximum fee parameter allows me to set the highest value I am willing to pay, which including both the basefee and the inclusion fee. I don't believe wallets even need to ask the user to set that parameter themselves. Of course wallets should always give the option to do so, but a wallet could simply set fee cap to whatever basefee is, times 2. As we’ve seen, it takes 6 full blocks (at 2x capacity) for basefee to double. This is pretty safe.2

In the parallel world of the current fee market, the all-knowing oracle had direct access to the demand to quote its price. In eip1559 world, the all-knowing oracle is the basefee, in the sense that the correct cut-off price is the basefee plus the fixed, 1 Gwei, miner fee.

We’ll repeat the scenario seen in the current fee market world. I send my transaction in, following the basefee + 1 Gwei inclusion fee strategy, and setting my maximum fee to 2x the current basefee.

The herd joins in the fun, there are too many of us to include, even with the slack: in this world, blocks are overfull. The basefee increases as a result. Some in the herd are bidding strategically, deviating from the 1 Gwei default and adding 2, 3, 4 Gweis to ensure they are included quickly. As long as these strategic users are enough to fill a block, I am at the back of the queue. If there aren’t so many of them, maybe I am included in the next block after I sent in my transaction.

If I am not included, maybe I’ll be in the next block. The herd would need to push basefee high enough, beyond twice its initial quote, to overtake my maximum fee and price me out entirely. The point is that my bid remains competitive, unlike my previously fixed 100 Gwei bid. I might get in by the fourth block after I sent my transaction. Basefee is at most 160 Gwei now. If the demand from the herd only pushed the basefee to 150 Gwei, that's what I end up paying. Another win: I always pay the lowest amount at the time I am included.

Surfing on sine waves

To summarise our thought experiment, we get two major wins with eip1559. First, the block slack means that the inclusion delay induced by sudden and short demand bursts is dampened. Second, the bidding grammar of eip1559, taking as reference a variable fee (basefee) and adding on to it means that we are not constrained to a fixed bid and instead follow the market where it leads us.3 This paradigm ensures we also pay the lowest amount when we are included and need not nurse our bid throughout to ensure we remain competitive.

This opens the door for wallet simplification too. Most of the time, a wallet can hide all parameters away from the user, simply quoting the current basefee with a binary “Send transaction / Don’t send” interface. As stated in my tweet above, a smart wallet should still rely on transaction pool monitoring to detect shifts in demand that would push the market into the overfull case. If a shift is observed, the wallet could let the user know that the market is heating up and suggest either:

• Raising the maximum fee parameter if the user has low time preference and simply wants to be eventually included in a reasonable amount of time.

• Raising the inclusion fee parameter if the user needs fast inclusion, skipping ahead of the queue.

• Setting a notification to be sent when basefee comes back down to a preferred level, at which point the user sends the transaction themselves.

Note that in hot markets as in relatively stable ones, the user can also always set their maximum fee to somewhere lower than basefee. If the current basefee is 100 Gwei but the user never wants to pay more than 50, they set the maximum to 50.4

Otherwise… Let the duck carry you.

Many thanks to Sacha Saint-Leger for edits and comments, and Tim Beiko for useful comments on this draft (and the previous one).

Also check this out

• Micah Zoltu wrote a great post in November 2020, A Tale of Two Pricing Schemes, going even deeper in the weeds of how transactions fail and how 1559 improves the pattern.

• Last Friday the much-anticipated 1559 community call happened. In my view there was more consensus than expected, with MEV (Maximum / Miner Extractable Value) coming out as a clear direction for future revenue. We’ll talk about this more in a future post, but in the meantime you can also check out Micah talking about MEV with Michael Carter (a.k.a., BitsBeTrippin’) or the excellent post by Hasu and Georgios Konstantopoulos estimating bounds on MEV under 1559.

In the current system, users attach a bid to their transactions (the gas price), hoping to outcompete other users and entice the next miner enough to include them. However, this first-price auction-style of bidding induces overpayment, UX issues and generally provides few guarantees for inclusion.

With eip1559, a basefee is introduced to price dynamically the congestion endured by the system, setting a minimum entry fee for each block, which in most cases is also the “correct” fee (modulo a small premium). This allows us, as Tim Roughgarden puts it, to move away from difficult-to-gauge transactions looking like buying a house in a dynamic market, towards an Amazon-style, posted price, take-it-or-leave-it paradigm.

To see how the posted-price paradigm is achieved, it’s useful to go in the weeds of how eip1559 determines its quote. It’s in fact possible, even more so than in the current system, to decompose the price quoted under 1559 as the sum of various parts, each arising from specific demand and supply constraints.

The miner fee

In all my writing so far, I’ve emphasised the role of the fee market as a congestion control mechanism to surface the best bids at any given moment. While congestion is responsible for the price variance, there is another cost the transaction fee is paying for. Since this cost is fixed at the timescale of a block, we’ll address it first.

From the perspective of the fee market, miners incur a cost proportional to how much gas they supply: the risk of their block becoming stale. Any extra transaction included in a block slows its propagation and its execution, opening the possibility for the block to not be received or processed in time, before another competing block is.

Ethereum provides rewards for stale blocks if their headers are included on-chain. The stale block miner receives an uncle reward but does not receive any of the transaction fees it included. There are two outcomes for a miner then:

1. The block is included in the canonical chain and the miner receives the block reward plus the fees attached to included transactions.

2. The block is “uncled” and the miner receives an uncle reward, smaller than the block reward.

It is estimated that the risk of being uncled is roughly linear in the amount of gas provided: a block twice as large has twice as much chances of not making it into the canonical chain. The miner ought to be compensated for the extra risk they incur by filling a marginal amount of gas in their block. At the limit, we can estimate the cost for a miner to provide one extra unit of gas. Let’s call this marginal cost the miner fee.

It is quite easy to estimate the miner fee. Vitalik has done it some time ago, or more recently you can find this estimation by u/c-i-s-c-o:

The tip level that compensates for uncle risk has been calculated to be about 0.8 gwei (uncle blocks get on average a 1.67 ETH reward instead of the 2 ETH base, so that's a ~0.33 ETH = 330m gwei loss, 10 million gas blocks add ~0.025 to the uncle rate [compared] to empty blocks, so the expected cost of 1 gas is = 330m / 10m * 0.025 = 0.825 gwei) and miners do actually set about this value when the chain is empty.

In a nutshell, it is appropriate to think of the miner fee as compensation for this increased risk of becoming an uncle, and to think of the miner fee as fixed to some nominal value. At this time, the meme appears to be 1 Gwei, based on the estimation above.

The congestion fee

The miner fee embodies the cost of use of the service, borne by the provider. The rest of the fee strictly arises from the cost of congestion, the desire of other users to join the system at the same time. While both costs are somewhat hidden in the fees paid in the current system, eip1559 gives us a much clearer distinction, between the fixed miner fee received as tip and the variable basefee measuring the congestion, in a very precise sense.

Let’s go back to the second-price auction example we introduced in the previous post, where three drivers, A, B and C, were bidding to access a road with limited capacity, fitting only one of the three.

Before driving, we'll have A, B and C write a bid on a piece of paper. There are two rules:

1. The driver with the highest bid wins the right to use the road.

2. The winning driver pays the price of the second-highest bid.

Assume all bidders know these rules, but none knows the benefits other drivers obtain from using the road.

The proof is left to you, but it is the case that rational bidders A, B and C ought to bid exactly how much they value the road.

We are looking for a fee that prices out exactly enough users to reach capacity. We saw that charging included users the bid of the first user not accessing the road gave us the efficient solution: users who receive the highest benefits also fill the system to capacity.

eip1559 is kind of a perpetual second-price auction. The basefee floats to price out exactly enough users such that the remaining ones fill the block to capacity. Sometimes it increases (as in English auctions), when the demand is higher than the supply, and sometimes it decreases (as in Dutch auctions), when the demand is lower than the supply.

By the way, what do we mean by demand?

The blue curve represents the demand, the price users are willing to pay for their gas. We order users in decreasing order of willingness. Of course the true demand curve would look a lot more like steps, because a user has a demand for a fixed amount of gas, not just one unit, but you can take this plot as a smooth approximation.

We show one important point: the gas price for which the demand is exactly equal to the block target size of eip1559, 12.5M units of gas. In this example the “equilibrium” price is 50 Gwei: only 12.5M gas worth of users are willing to pay above this price. If basefee was set to 49 Gwei and the miner fee to 1 Gwei, we’d have exactly as much gas in the block as we are targeting.

This is all fine, but since the whole demand curve is way above the miner fee, why couldn’t miners include everyone up to the block limit, set to twice the block target?

Effective demand in eip1559

The reason is that the basefee is binding. Users who do not pay at least the basefee cannot be included. Additionally, users who do not pay the miner at least the miner fee wouldn’t be included.

We'll call effective demand the amount of gas demand by users who are willing to pay at least the basefee plus the miner fee. There are three cases worth taking a closer look at:

1. Undertarget: The effective demand is lower than the gas target.

2. Overtarget: The effective demand is higher than the gas target, and lower than the gas limit.

3. Overfull: The effective demand is higher than both the target and the limit.

Each case maps neatly on the previous plot. If the effective demand is somewhere between 0 and 12.5M gas, we are undertarget. If it is between 12.5M and 25M, we are overtarget. If it is above 25M, we are overfull.

Obviously we’re still aiming for the sweet spot between the under- and overtarget areas, but this is a small window to aim for. So let’s see what happens in each case, starting with the overtarget case.

Overtarget: Effective demand higher than target and lower than limit

In this case, more users can and would be included than the target, meaning that the basefee is too low given the current effective demand. Fortunately, eip1559 allows us a bit of slack in case we haven't exactly figured out the basefee that makes effective demand exactly equal to the gas target.

This slack means users need not overbid. The next block has enough room for all users part of the effective demand. Users are expected to pay exactly the basefee plus the 1 Gwei miner fee.

Overfull: Effective demand higher than target and limit

This case is trickier. The next block cannot accommodate all the effective demand, which is higher than 25M gas. In Roughgarden’s terminology, the basefee is excessively low. In this scenario, it is rational for users to include higher tips with their transactions, to secure their inclusion faster.1

In this case, we decompose the transaction fee in three parts:

1. The miner fee (1 Gwei).

2. The basefee, which is not matching the true congestion fee.

3. The strategic fee, making up for the mismatch.

Although the miner receives parts 1. and 3., the true congestion fee is actually the basefee plus the strategic fee.2

Undertarget: Effective demand is lower than target

In this case, the basefee is higher than it needs to be, pricing out too many users. In the previous case, the true congestion fee was under-estimated by basefee. Now, it is over-estimated, by a quantity we’ll call the mismatch fee. It is still rational for users to bid the basefee + 1 Gwei miner fee strategy.

Fee decomposition in eip1559

As we’ve seen, eip1559 is easily matched to three disjoint cases, each giving rise to specific fee conditions. We summarise them here.

Overall, the user pays the height of each column in the previous plot. The miner receives both the miner fee and the strategic fee, when the latter exists. When blocks are undertarget, the mismatch fee is implicitly contained in the basefee, which hasn’t adjusted downwards yet to meet the decreasing demand.

How often are we in either of these cases? Being under- or overtarget is clearly more desirable than being overfull, since users are simply expected to bid basefee + 1 Gwei miner fee, yielding the elusive UX improvements eip1559 touts. All else equal, effective demand conditions closer to target size are also preferable, since they entail basefee is pricing accurately the congestion, with users paying a fair rate.

There is hope that blocks aren’t usually overfull and that the only tips above basefee + miner fee will come from MEV-extracting transactions. On-chain data after eip1559 is deployed will tell us if we are correct, but in the meantime we can draw more general conclusions on the tension between the basefee update rate and the demand to understand when this fails in theory. In our recent paper, Dynamical Analysis of the EIP-1559 Ethereum Fee Market,3 we go further and prove that chaotic behaviour is observed in the block occupancy rate whenever demand concentrates, producing strong oscillatory behaviour.

We’ll dive into these results in a future entry of this newsletter, subscribe here to be sure not to miss it!

Subscribe now

In other 1559 news

• 1559 is proposed for the London upgrade (probably ~July)

• Upcoming 1559 community call (Feb. 26th)

Many thanks to Sacha Saint-Leger for useful comments on this draft.

With eip1559, a basefee is introduced to price dynamically the congestion endured by the system, setting a minimum entry fee for each block, which in most cases is also the “correct” fee (modulo a small premium). This allows us, as Tim Roughgarden puts it, to move away from difficult-to-gauge transactions looking like buying a house in a dynamic market, towards an Amazon-style, posted price, take-it-or-leave-it paradigm. In its standard version, eip1559 “burns” the basefee by effectively redistributing it to no one.

Congestion is central to the existence of the fee market and the design of eip1559, and we’ll spend some time defining properly what it means and how we measure it. We’ll see how congestion pricing arises as a fairly natural solution and discuss whether any of its principles help us decide what to do with the fees.

A primer on congestion games

Think of a road with one lane that takes 1 minute to cross if you are alone on the road. Assume that each additional driver on the road increases the travel time by 1 minute. The "latency function" of the road is x, where x is the number of users on the road (so if you are the only driver, the latency is 1 minute).2 How much total travel time does one extra road user bring?

• When there is one user A on the road, the total travel time is 1 minute.

• When there is one more user B, A now takes 2 minutes to cross the road, and so does B. The total travel time of everyone is 4 minutes.

• When there is one more user C, users A, B and C all take 3 minutes to cross the road, so the total travel time is 9 minutes.

In other words, each additional driver adds one extra minute of travel time to all other drivers. If there are 10 drivers on the road and an eleventh driver shows up, the total travel time of these 10 drivers is up 10 minutes (1 minute each). If each driver imposes costs on everyone else, at which point does the overall society lose out?

In search of lost optimality

In algorithmic game theory, we often look for mechanisms that produce the best social outcome given some social dynamics. We’ll start with elaborating what best social outcome means in the context of our drivers, before moving on to the mechanisms that achieve optimality.

We assume the drivers trade-off time and money equally, e.g., spending one extra minute of time on the road is equally as bad as losing a dollar. While all drivers trade-off money and time equally, they receive different benefits from crossing the road. Some drivers want to go to a market they like, but could also choose a different one. Others really need to go see family or attend an important event. For each driver, we associate a number that expresses in dollar terms the benefit they obtain from crossing the road.

Let's take a simple example. We have three road users, A, B and C, with respective benefits $10, $7 and $4 (we’ll drop the $ in the following). If all three users take the road, the travel time for each is 3 minutes. So overall,

• A benefits 10 but “pays” 3 minutes of their time on the road, so the profit is 7.

• B benefits 7, pays 3, profits 4.

• C benefits 4, pays 3, profits 1.

The last number in bold represents the social welfare: how much everybody benefits minus how much everyone pays. Our goal is to make the social welfare as high as possible. Is this the most we can get out of the situation? What if we prevent C from entering at all?

When we prevent C from using the road, we increase the social welfare! Why is this true? The key reason: the extra cost brought on by C to A and B is not compensated by the extra benefit obtained by C. In other words, the private benefit is smaller than the public cost.

We are faced with a clear paradox: there is no reason for C not to enter. Given the information that both A and B plan to use the road, a rational user C would still want to join as well, since they receive one unit of profit, leading to a decrease of the social welfare.

Inducing social optimality: Adding a toll

To obtain the best social outcome, we'd like to operationalise the following idea: any user on the road should pay for the harm it causes other users.3 By internalising the public harm into the private profit evaluation of each user, incentives are aligned. We do so by adding a toll to the road.

How much should the toll charge? We've seen that adding one user to the road when x users are already driving causes x additional cost (1 extra minute per driver). So we should set the toll to x, where x is the number of users already on the road.4 We call this a marginal cost toll, as any incoming user raises the toll to the cost the user imposes on everyone else.

Assume that all users pay x when they are on the road and x users are using it. Suppose A, B and C all enter.

Now C makes a negative profit. They realise it’s just not worth taking the road, so they drop out and we obtain:

Is there some sleight of hand here? We thought the toll would help us reach our socially optimal situation, yet the social welfare is now 9, but it was 13 before! Where did the 4 units go?

In a sense, we have reached the socially optimal outcome (A and B use the road, C doesn't), if not the socially optimal payout (the total profit is 13). The reason is quite simple: 4 units have disappeared into the toll, as both A and B pay 2 units to the toll. We'll discuss this point soon, after making the link with eip1559 clearer.

Constraining the road: Auctions appear

As is probably evident by now, the road is a metaphor for the transaction fee market. Yet our metaphor doesn't really describe the true situation of transactions and blocks. Blocks are limited in size, so they do not allow for unbounded “congestion” the way our model of the road does.

Let's assume that the road only fits one out of our three drivers. Depending on who arrives first, we might have suboptimal situations. For instance, if user C arrives first, the situation is:

Would a toll work? Well, what if we wanted to target exactly the road capacity, i.e., what if we wanted to induce exactly as many users on the road as the capacity allows for? There is no reason why the socially optimal number of users that the toll returns should be equal to the road capacity. If the toll induces less drivers than the road capacity, arguably we have reached social optimality, so it’s not a problem. But if the socially optimal number of users on the road is above the constraint, the marginal cost toll will not work in general. We’ve seen it already: both A and B were still using the road, which exceeds the capacity we set.

There is a more “essential” reason why a toll cannot in general induce the optimal allocation with capacity constraints. The toll priced the extra latency that a new user imposes on everyone else. With a capacity constraint, a new user doesn’t simply slow down everyone, they totally prevent access to the resource. If we wanted to internalise the public harm via some mechanism, we’d have to price how much this access restriction is worth, beyond the degradation of the service due to congestion.

Fortunately, there is a different mechanism which does just that. We need to think about auctions, specifically, second-price auctions. How should we decide who among A, B and C should access the road?

Before driving, we'll have A, B and C write a bid on a piece of paper. There are two rules:

1. The driver with the highest bid wins the right to use the road.

2. The winning driver pays the price of the second-highest bid.

Assume all bidders know these rules, but none knows the benefits other drivers obtain from using the road.

The proof is left to you, but it is the case that rational bidders A, B and C ought to bid exactly how much they value the road. For now, we’ll forget that crossing the road itself is costly for the winning user, and focus on the bids only.5

Another sleight of hand! Where did the 7 dollars A bid go? The answer: in the auctioneer's pocket. But who is the auctioneer? Is the auctioneer the road provider?

🔥🔥🔥

We follow our intuitive definition of internalising public costs: we make users pay for the harm they cause others. If A wasn't there, B should be the driver on the road (to maximise public benefit), while B would harm C by taking the road from them. Congestion thus affects users who were keen to access some resource, but couldn’t, or could at a degraded level of service. Shouldn’t these users be compensated for their loss?

In a monetary economy, there is one way to compensate for the harm caused by congestion that retains efficiency, in the game-theoretic sense of “users with the highest benefits obtain the right to access”: not redistributing the fee to anyone.

This isn't a silver bullet, and it isn't exactly equivalent to redistributing equally the collected fees among everyone, because the mechanics of a monetary economy are a bit more subtle than this. But the intuition is:

1. Users-as-transaction-senders bear the costs of congestion, since it deprives them of access to the transaction market.

2. Thus users-as-transaction-senders ought to be compensated for the costs induced by congestion.

The two points above are perhaps the most straightforward microeconomic argument for burning-as-congestion-compensation. Yet, arguing for burning as a necessarily fair microeconomic consequence is difficult for at least two reasons.

Suppose we do believe that burning is an exact redistribution of the amount burned over all participants. In a large economy, this direct redistributive effect is extremely diluted over individual recipients, approaching zero as the number of participants increases (assuming a fixed amount of fees throughout).

Let’s say we are fine with the dilution: an epsilon amount of cash is better than zero after all. We can level a second critique to the microeconomic argument. We've not differentiated, among our population of Ethereum users, between transaction senders and holders. While transaction senders are the ones inconvenienced by the congestion, holders aren't (by definition, they don't send any transactions). But how should a mechanism determine who has been harmed by the congestion or not? Likely, it is impossible, as we’d need to know who would have sent a transaction but didn’t because of the congestion. Is rewarding everyone who holds ETH with the burn a good enough approximation of a mechanism that compensates those affected by the fee market congestion?

I’ve often seen this argument mentioned by miners as a reason why it is delusory to expect that burning achieves redistribution, because of the dilution, and I tend to agree. If this direct, “micro” effect is unsatisfying, perhaps we can think of a more indirect, “macro” effect of the burn that we feel stronger about.

So we decompose the total effect of the burn between a more direct “redistribution effect” of burning part of the supply (with the caveats seen above that this redistribution is both diluted and approximative) and a more indirect effect based on the more intangible nature of ETH as an asset fit to secure the Ethereum network.6

This second, indirect effect tends to be more popular among pro-eip1559 people, and is probably what they mean by “eip1559 will solidify ETH as an asset”, i.e., not something that is measured by comparing inflation pre- and post-eip1559 and scaling the price of ETH by the difference. With the burn proportional to the demand for the network, a link is created between ETH the asset and the network value of Ethereum. In turn, a better ETH increases the bandwidth to use the asset as, e.g., collateral for generating more DAI, in addition to increasing the general level of security of eth2 for instance.

There are other, very good reasons for burning, including weaning off an economy of a highly volatile revenue source which, at the limit, induces instability and complicates miner revenue estimations; recentring the block reward as the mechanism via which security is paid for; or preparing the ground for the transition from Proof-of-Work to Proof-of-Stake.7 Whether any of these ought to apply as soon as eip1559 is turned on versus in months or a year after seems to have indeed become the stage for the argument.

In the next Price of agency

Since we’ve gone to the trouble of defining what we mean by congestion and how to price it, we’ll drop the road metaphors and see how eip1559 brings us closer to that price by inspecting its dynamics. Subscribe to receive it as soon as it is out.

Subscribe now

Many thanks to Vitalik Buterin, Sacha Saint-Leger and Tim Beiko for comments and edits. Errors, opinions and erroneous opinions remain mine.

Sign up to receive new posts as they are released.

Subscribe now

In the meantime, tell your friends!