A look down Ethereum’s roadmap: The cases for FOCIL and multi-proposer schemes
Ethereum now supports a vibrant ecosystem of applications and Layer 2s. But its transaction supply chain, which determines which transactions land onchain, enshrines certain participants with market power, harming the chain’s economic efficiency.
Many issues with Ethereum’s transaction supply chain stem from the fact that for every slot, a single proposer has monopoly control over what transactions to include in their block. Proposers also have incentives offchain and from the application layer that affect their behavior. These sometimes competing incentives make it difficult to encourage proposers to honestly follow the protocol.
Two types of proposer deviations are of particular concern: (1) short-term censorship, and (2) acting on enshrined latency advantages.
How to prioritize and address these two problems depends on Ethereum’s development roadmap. If Ethereum has to solve short-term censorship resistance, constrained single proposer designs have appealing properties while also being close to well specified enough with proposals like FOCIL to be implemented. But if Ethereum’s success also relies on addressing some of the negative market effects of single proposer schemes on the application layer, more drastic change likely needs to happen. Multi-proposer schemes look promising to address the broader concerns.
The rest of this post describes these problems in more detail before getting into how these issues impact Ethereum’s functionality. I’ll then analyze the two potential solutions to address them — the implementation of which depends on Ethereum’s roadmap.
Problem 1: Short-term censorship
Blockchains inherent censorship resistance from liveness: Eventually every valid submitted transaction will make it onchain. But the bounds on how long a transaction will take to be included onchain are too loose for many applications. DeFi transactions are a common example, where it might be only a few seconds until a transaction is stale. In these scenarios, a proposer could stand to gain by censoring a transaction even for a single block, degrading the efficiency of these applications.
Consider the case where a dapp wants to sell an item every slot via a first price auction. Assume this item has a common value of $10; thus in a competitive auction we’d expect the dapp to receive around $10. But since the auction takes place over the course of a slot, all the bids from the auction need to be included by the proposer. In a single proposer scheme, the proposer could simply exclude others’ bids, and include only their own low bid, winning the item for much less than the item is worth.
Such instances require a notion of short-term censorship resistance that captures how hard it is for an adversary to censor a transaction for a single block. Short-term censorship resistance is an economic property. If more transactions demand to be included in a block than there is space, some of the transactions must be left out. Those transactions aren’t necessarily being censored by an adversary; rather, they are simply priced out of inclusion. However, some protocols make it easier for an adversary to either price out or incentivize the proposer not to include target transactions. In the spirit of saying protocol A is more censorship resistant than protocol B if it is more difficult for an adversary to censor a target transaction in A than B, we use the following definition:
Protocol A is more short-term censorship resistant than protocol B if all else equal, for any transaction t, the minimum net payments an adversary has to make to prevent t from being included at equilibrium in a given block is higher under A than B.
(This definition is intentionally not well defined mathematically. Formally defining the game being played and the equilibrium concept will be the subject of future work. For now, the examples convey the spirit of this definition.)
Example
With Ethereum using EIP-1559 as its fee mechanism, an adversary simply needs to pay the proposer more than a transaction’s tip above the base fee to not include it.
If the fee mechanism is a first-price auction, an adversary would have to pay the proposer more than the entirety of a user’s bid to incentivize them to not include the transaction.
Note that bidders are expected to only pay tiny tips under EIP-1559. Thus while the bids under a first price auction are expected to be relatively small in comparison to a transaction’s true value, they are still substantially higher than what the transaction’s tip would be in EIP-1559. Thus we would say that Ethereum using a first price auction as its TFM is more short-term censorship resistant than Ethereum using EIP-1559. In either case, however, if the equilibrium price for inclusion for a Defi transaction is high enough to deter an adversary, users now have to pay a hefty tax to the protocol in turn making the Defi app itself less attractive.
Problem 2: Enshrined proposer latency advantages
In a single proposer architecture, the proposer is by design the last one to move in the block production game for a given slot. (In practice there is a complicated offchain transaction supply chain where relays move last. For the purposes of this post we treat proposers and builders as combined.) This means that proposers can always submit transactions that reflect a “fresher” state compared to any other submitted transactions. Even if both users and the proposer receive information simultaneously, it takes time for users to send their transactions to the proposer, during which new information might arrive. The proposer is in a position to instantly react to this information and potentially change their transaction, but the user has no time to do this.
For example, the optimal way to route a trade onchain may depend on the offchain ETH-USD price on Binance. In a single proposer architecture, a sophisticated proposer can submit trades that are more up-to-date than any users competing for the same trade.
Example
Consider our previous example of a dapp selling an item every slot via first-price auction. But now the item’s value is a function of constantly updating information. Assume there are two bidders competing for the item, agents 1 and 2. Both agents hear new information simultaneously, except agent 1 always gets to bid after agent 2. In this case, agent 2 is adversely selected against when they win because the only time bidder 2 wins is when the information updates after they submit their bid to the point that they are over paying. Otherwise, whenever the information changes so that bidder 2’s bid is profitable, bidder 1 will simply update their bid in response to the newer information and win the auction. This effect is especially stark when agent 1 can directly observe agent 2’s bid, but even if agent 1 can’t see agent 2’s bid, agent 1 still has a substantial competitive advantage. In the long run, agent 2 will not find it worth it to participate, letting agent 1 capture all the value from the auction.
This example shows how structural advantages given to the proposer can cause competition to dry up and drive all the surplus value from onchain markets to the proposer.
Possible solutions depend on the roadmap
The extent to which short-term censorship resistance and proposer latency advantages matter depend on the Ethereum development roadmap. One vision for Ethereum’s future is fully embracing the L2 roadmap and having all meaningful execution happen offchain, with Ethereum being used for settlement, data availability, and proof-verification. In such a world, short-term censorship is the main problem, although achieving it over the span of ~10 blocks may be sufficient rather than the block-level guarantees we described above. An alternative path is for Ethereum to serve as a hub for high value execution, and in particular for high-value Defi. In this world, achieving strong short-term censorship resistance and alleviating proposers’ strong structural economic advantages becomes essential.
Two alternatives help address these problems. The first is a constrained single proposer architecture that adds committees which bind the proposer’s action space. The second is a multi-proposer architecture that looks dramatically different from Ethereum’s current design: It splits the proposer’s power among many different parties.
While both designs are still in active development, there have been proposals of what these architectures might look like. We outline what these proposals look like and analyze how they address the problems we’ve discussed.
A case for FOCIL
Constrained single proposer architecture
A constrained single proposer architecture is one where a committee within the same block imposes constraints on the proposer. Inclusion lists (ILs) are the most natural example of this, where an inclusion committee enforces that a block proposer include certain transactions the committee hears about.
The amount of power the committee has varies in different designs. One important distinction is between unconditional and conditional inclusion lists. With unconditional inclusion lists, the transactions the committee includes must be included by a proposer for the block to be valid. With conditional inclusion lists, a block only has to include the contents of the inclusion list conditioned on the block not being full, meaning that if the proposer fills the entire block with their own transactions, they aren’t required to include any transactions in the inclusion list. While unconditional ILs can offer better short-term censorship resistance, they might also be easier to crowd out because they might be used to offer products like preconfirmations.
The latest proposal for a constrained single proposer design on Ethereum is called FOCIL (fork choice conditional inclusion lists), which lays out how to implement inclusion lists (FOCIL is not explicitly designed to deal with high-value MEV transactions but is instead optimized for censorship resistance over the span of a few blocks. Nevertheless, as it’s the most concrete specification of what a constrained-single proposer architecture could look like, it’s useful to analyze it in this setting.)
The high-level design is as follows (for details, see “FOCIL CL & EL workflow”): Every slot a subset of validators are chosen as inclusion committee members. Committee members construct their lists of transactions up to a local IL size limit (in KB). These lists are locked ¾ of the way through the slot and gossiped to the proposer, who is then responsible for appending any transactions they are missing in the list to their block, until their block hits the gas limit. Then, in addition to standard block validity rules, attesters also check that proposed blocks are conformant against the corresponding inclusion lists. Note, there are no economic incentives in the protocol for the inclusion list committee to act honestly.
Analysis
Short-term censorship resistance
The short-term censorship resistance of a constrained single proposer scheme depends on what types of constraints are allowed and how the proposer is bound to them. As we define short-term censorship via an economic model, the details of how the inclusion committee is incentivized can also change the relative power of these mechanisms. We will start by analyzing FOCIL with EIP-1559 as the L1 TFM before expanding on what is possible in the space of constrained single proposer mechanisms.
Since FOCIL does not explicitly incentivize the inclusion committee to include any transactions, let’s assume that the inclusion list committee is non-strategic and acts honestly. FOCIL also doesn’t specify what inclusion rule honest IL committee members should follow, but for our analysis we assume that honest IL members will include transactions they hear about with the highest priority fees. (FOCIL’s goal is to also increase censorship resistance on longer time scales than a slot, so the intention is that some committee members also follow inclusion rules such as including transactions that have been in the mempool the longest.)
Now consider an instance where an adversary is targeting a transaction that tips $10 on top of the base fee, and that $10 is sufficiently high to make the transaction included in the IL. The adversary here has two options. They can either send enough transactions above a $10 tip in the mempool to kick the target transaction out of the IL while also bribing the proposer $10 to not include the target; or the adversary could send enough transactions to fill the proposer’s block and also still send the proposer with $10 to not include the target transaction. Either of these strategies is significantly more expensive for the adversary than the status quo of only paying the proposer $10 to not include the target transaction. In the former case, the adversary has to pay the priority fee plus base fee for any of the transactions that ends up landing on chain; in the later case the adversary has to pay at least the base fee to fill the entire block (assuming EIP-1559 as the base layer TFM).
If FOCIL instead used unconditional inclusion lists, the second attack vector would be ruled out. Thus, if the target transaction had a high tip, then the adversary would be put in the position of filling the IL gas limit with transactions having tips above the target, which is potentially much more expensive than paying the base fee to fill the entire block.
The key assumption in this analysis is that the IL committee acts honestly while being non-strategic. If the inclusion committee were strategic, then the adversary could pay them an arbitrarily small amount to produce empty lists in the current protocol. Without any mechanism incentivizing the IL committee to follow the protocol, analyzing the short-term censorship resistance of these protocols reduces to the standard single proposer case. Fee mechanism design that allows fees of transactions included by the IL committee to go to the IL committee can help increase the robustness of these protocols, but the details of such designs and the properties they would satisfy are the subject of future work (for instance, see this example).
Proposer latency advantage
Constraints like ILs alone don’t help address proposers’ latency advantages. In these designs, the single proposer still moves last and still has the power to insert whatever transactions they like. In general, the constrained single proposer setting has difficulty addressing this problem because any form of a constraint committee must act before the end of a slot for the proposer to have time to hear the outcome of the constraint and act accordingly. Thus, the proposer has the privileged position to act on any information that arrives in this duration. The only way around this is for a committee, rather than the proposer, to end the block production game, in which case we move toward a multi-proposer architecture.
A case for multi-proposer
Multi-proposer architecture
A multi-proposer architecture explicitly has multiple proposers jointly building a block every slot. Many potential instantions exist, but multi-proposer schemes generally have a similar structure: A set of validators is chosen randomly by stake as proposers in a given slot. At the end of the slot, each chosen validator proposes a set of transactions following a local block validity rule. Then the protocol deterministically aggregates these proposals into a single canonical block.
The key feature of multi-proposer schemes is that no single proposer is given special power over what gets included in a block. Even though the multiple proposers in such a scheme have advantages compared to non-proposers, the competition between proposers themselves can lead to improved market equilibria.
As opposed to the constrained single proposer setting that is additive to the current Ethereum protocol, a multi-proposer architecture would require a fundamental rework of Ethereum. As such, many components have to be reasoned about, including the transaction supply chain, consensus, and fee mechanisms. Here, we will consider an idealized model of a multi-proposer architecture where the consensus details are worked out and we can focus on a single slot in isolation. Assumptions include that all the proposers are homogenous and have equal access to information, and that the aggregation rule is simply taking a union over all proposed transactions. (This analysis holds for any reasonable choice of ordering rule.) A large part of bringing multi-proposer to production will be relaxing these assumptions to create a full specification, but even with this simple model there is still much to consider.
Analysis
Short-term censorship resistance
The short-term censorship resistance of a multi-proposer architecture depends on the TFM being used. For example, schemes that evenly distribute fees across all proposers and are pay-as-bid for users can incentivize better throughput but worse short-term censorship resistance than you would get from current single proposer schemes. On the other hand, some proposal TFMs look to take advantage of multi-proposer architectures to get more censorship resistance than would be possible in a single proposal scheme.
For example, Fox, Pai, and Resnick. make the observation that having a transaction’s payment be a function of how many proposers include a transaction can drastically increase the cost to censor the transaction. Their TFM has users submit a pair of bids (t,T) with t<<T. If k>1 proposers include the transaction. The transaction pays kt with t going to each of the corresponding proposers. However, if only one proposer includes the transaction, then the transaction pays T to the single block producer. Hence, an adversary has to pay kT to censor the transaction, since any validator can unilaterally deviate to include the transaction if no one else is, while the transaction only expects to pay Θ(t) for inclusion.
This gap between how much a transaction has to pay for inclusion and the cost to censor it, is a key property that comes from proposers competing among themselves. A censoring adversary needs to make payments such that none of the proposers include the transaction. Of course, if the proposers all collude, this analysis breaks down and the benefits of multi-proposer is lost — potentially leaving us in a worse situation than the single proposer case. However, as the number of concurrent proposers increases, both the amount an adversary has to pay to induce a censoring equilibrium and the difficulty of maintaining the collusion increase since even one proposer deviating from the censoring ring would be sufficient to regain short-term censorship resistance properties.
Proposer latency advantage
Assume no proposer can see other proposers’ blocks before they make their own block. Perfect synchrony could achieve this, but, more practically, cryptography can achieve the same end. Proposers can use time lock encryption to have their block contents hidden only for a few seconds. Thus, if proposers all release their blocks a couple seconds before the end of the slot, proposers can’t see each other’s blocks until the slot has passed. Instead of time lock encryption we could also threshold encrypt block contents to an attester committee to achieve a similar property.
Given this assumption, there is no party who moves last to end the block production game. This means that proposers are forced to compete with one another on an equal playing field to take advantage of opportunities at the application layer. As new information comes in, all proposers are in an equal position to react and update their transactions. This competition then keeps this value within the application layer and allows a competitive market to exist instead of having the market unravel and letting the value all leak to a single proposer. Note, however, that a multi-proposer scheme doesn’t change the structural advantage proposers have over users, since users still face a latency delay in getting their transactions to the proposer. But now instead of a single party with the advantage, there are multiple parties with equal advantages.
The exact details of how to implement the cryptography so proposers can’t see each others’ blocks before they propose their own are crucial to maintaining this property. Otherwise, certain proposers again have structural market advantages over others, degrading the competitiveness of onchain markets. These specifications are still largely works in progress.
***
If the main concern Ethereum has to solve is short-term censorship resistance, constrained single proposer designs have appealing properties while also being close to well specified enough with proposals like FOCIL to be implemented. On the other hand, if Ethereum’s success also relies on addressing some of the negative market effects of single proposer schemes on the application layer, more drastic change is likely needed. Multi-proposer schemes look promising to address the broader space of issues. But since these designs completely restructure the Ethereum stack, they have a longer path ahead of them in getting to a complete specification and addressing all the potential second-order effects of such large changes.
***
Acknowledgments: Thanks to Barnabe, Joachim, Julian, Max, and Thomas for helpful comments and suggestions
***
Pranav Garimidi is a research analyst at a16z crypto. He focuses on mechanism design and algorithmic game theory as it relates to blockchain systems. He is especially interested in how incentives interact across the blockchain stack. Prior to a16z, Pranav was a student at Columbia University where he graduated with a degree in Computer Science. You can follow him on X @pgarimidi
***
The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of a16z or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the current or enduring accuracy of the information or its appropriateness for a given situation. In addition, this content may include third-party advertisements; a16z has not reviewed such advertisements and does not endorse any advertising content contained therein.
This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments for which the issuer has not provided permission for a16z to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://a16z.com/investment-list/.
The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures/ for additional important information