Seeing like a protocol
Seeing like a protocol
Where does protocol credibility come from?
In the past months, I’ve harped on Proposer-Builder Separation, and the Principal-Agent Problem more generally. One reason is the depth of research questions, bringing in the mix considerations from both the consensus layer and the execution layer, plus everything in-between, such as MEV, the transaction supply network, and the growing web of out-of-protocol markets and institutions.
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.3Ordering 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.
Block ordering escaped from the purview of the protocol, or, depending on where you stand, it was never really there to begin with. 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.
Anything not sold is for sale.
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.
Or was that a reaction to the complexity explosion of sharding?
Specifically, attributable faults lead to slashing, a significant loss of stake for malicious validators, which gets more significant as the size of the malicious set grows. Meanwhile, non-attributable faults such as validators being offline or voting on wrong, but non-conflicting items, lead to “inactivity leaks” and small, possibly recurrent penalties, as long as the fault lasts.
We use exclusive to refer to transaction flow that is not gossiped publicly before making it into a block, and private to refer to transaction flow made private via e.g., encryption.
And if “Feedback is all you need for agency to emerge”, then our correcting the protocol when it errs means Ethereum is intelligent??
An identical sleight of hand is performed whenever a lawyer is contracted to enforce the will of its client, or when a company drafts a policy which both constrains and protects its own members. This phenomenon is well-known to game theorists.
I learned that this has to do with smart transactions and MEV-time oracles...