Author: Ethereum founder Vitalik; Translated by: Deng Tong, Golden Finance
Note: This article is the third part of a series titled "Possible futures of the Ethereum protocol, part 3: The Scourge" recently published by Ethereum founder Vitalik on the future development of the Ethereum protocol. The second part can be found in Jinse Finance "Vitalik: How the Ethereum protocol should develop in the Surge phase", and the first part is titled "What improvements can still be made to Ethereum PoS". Below is the full text of the third part:
One of the biggest risks facing Ethereum L1 is the centralization of proof of stake due to economic pressure. If there are economies of scale in the core proof of stake mechanism, this naturally leads to large stakeholders dominating, while small stakeholders exit to join large mining pools. This leads to a higher risk of 51% attacks, transaction censorship, and other crises. In addition to the risk of centralization, there is also the risk of value extraction: a small number of people are obtaining value that would otherwise flow to Ethereum users.
Last year, our understanding of these risks significantly increased. As is well known, this risk exists in two key areas: (i) block construction, and (ii) staking capital regulations. Larger participants can run more complex algorithms ("MEV extraction") to generate blocks, thus bringing them higher block revenues. Large participants can also more effectively address the inconvenience of funds being locked by releasing funds as liquid staking tokens (LST) to others. In addition to the direct issues between small stakers and large stakers, there is also the question of whether (or will) there be an excessive staking of ETH.
Scourge 2023 Roadmap
This year, significant progress has been made in blockchain construction, most notably the integration of "the committee inclusion list plus some targeted ordering solutions" as the ideal solution, as well as important research on proof-of-stake economics, including two-layer staking models and reducing issuance to limit the percentage of staked Ether.
The Scourge Key Objectives
Minimize the centralization risk of the Ethereum staking layer (especially in block building and capital supply, also known as MEV and staking pools)
Minimize the risk of excessively extracting value from users.
This article is divided into three parts
Fixing the block construction pipeline
Fixing staking economics
Application-layer solutions
Fix Block Construction
What problem are we trying to solve?
Currently, Ethereum block construction is primarily achieved through the off-protocol propser-builder separation of MEVBoost. When validators have the opportunity to propose a block, they delegate the task of selecting block content to specialized participants known as builders. The task of selecting block content that maximizes revenue is scale-economy intensive: it requires specialized algorithms to determine which transactions to include in order to extract as much value as possible from on-chain financial instruments and user transactions interacting with them (this is referred to as "MEV extraction"). Validators face a relatively lighter scale-economy "dumb-pipe" task, which involves listening for bids and accepting the highest bid, as well as other responsibilities like proof.
The programmatic diagram of what MEVBoost is doing: dedicated builders take on the red tasks, while stakeholders take on the blue tasks.
There are multiple versions, including "Proposer-Builder Separation" (PBS) and "Attester-Proposer Separation" (APS). The differences between them relate to fine-grained details regarding which responsibilities are borne by which of the two participants: broadly speaking, in PBS, validators still propose blocks but receive payloads from builders, whereas in APS, the entire slot becomes the responsibility of the builder. Recently, APS has been favored over PBS because it further reduces the incentives for proposers and builders to coexist. Note that APS only applies to execution blocks that contain transactions; consensus blocks that contain proof-of-stake related data (such as proofs) will still be randomly allocated to validators.
This separation of power helps maintain the decentralization of validators, but it comes at an important cost: participants executing "specialized" tasks can easily become very centralized. This is the state of Ethereum block building today:
Two participants are selecting the content of approximately 88% of the Ethereum blocks. What if these two participants decide to review the transactions? The answer isn't as bad as it seems: they cannot reorganize the blocks, so you don't need 51% of the review to prevent transactions from being included; you need 100%. Under the 88% review mechanism, users typically need to wait for 9 slots (technically an average of 114 seconds, rather than 6 seconds). For some use cases, waiting two minutes or even five minutes for certain transactions is acceptable. But for other use cases, such as DeFi liquidations, the ability to delay the inclusion of others' transactions by a few blocks poses a significant market manipulation risk.
Strategies that builders of blocks can use to maximize profits may also have other negative impacts on users. "Sandwich attacks" can cause users trading tokens to suffer significant losses due to slippage. To clog the chain with these attacks, the Gas prices for other users have been increased.
What is it and how does it work?
The leading solution is to further break down the block production tasks: we will return the task of selecting transactions to the proposer (i.e., the staker), while the builder can only choose to sort and insert some of their own transactions. This is what the inclusion list aims to do.
At time T, a randomly selected staker creates a list of valid transactions under the current state of the blockchain. At time T+1, the block builder (potentially selected in advance through an internal auction mechanism) creates a block. This block must include each transaction from the list, but they can choose the order and can add their own transactions.
The Fork Choice Mandatory Inclusion List (FOCIL) proposal involves a committee composed of multiple inclusion list creators for each block. To delay a transaction by one block, all k inclusion list creators (for example, k = 16) must review the transaction. FOCIL, combined with the final proposer selected through an auction, needs to include the inclusion list but can reorder and add new transactions, commonly referred to as "FOCIL + APS."
Another way to solve this problem is through multiple concurrent proposers (MCP) schemes, such as BRAID. BRAID attempts to avoid dividing the block proposer role into low-scale economic parts and high-scale economic parts, but rather tries to allocate the block production process to many participants, so that each proposer only needs to have a moderate level of complexity to maximize their income. The way MCP works is by allowing k parallel proposers to generate a list of transactions, and then using a deterministic algorithm (for example, sorting by fees from high to low) to select the order.
BRAID does not seek to achieve that running default software dumb-pipe block proposers are the best target. The two easily understandable reasons it cannot do so are:
Backdoor Arbitrage Attack: Suppose the average time submitted by the proposer is T, and the time by which you may finally submit and still be included is approximately T+1. Now, assume that on the centralized exchange, the ETH/USDC price moves from $2500 to $2502 between T and T+1. The proposer can wait an additional second and then add extra trades to arbitrage on the on-chain decentralized exchange, earning up to $2 profit per ETH. Experienced proposers with good network connections are more capable of doing this.
Exclusive Order Flow: Users are incentivized to send trades directly to a single proposer to minimize their vulnerability to front-running and other attacks. Experienced proposers have an advantage as they can build the infrastructure to accept these trades directly from users, and they have a stronger reputation, allowing users to trust that the proposer will not betray them and front-run (this can be mitigated by using trusted hardware, but trusted hardware comes with its own trust assumptions).
In BRAID, provers can still be separated and function as a dumb pipe.
Apart from these two extremes, there exists a range of possible designs that fall in between. For example, you could auction roles that only have the right to attach to blocks, without the right to reorder or prepend. You could even allow them to attach or prepend, but not to insert in between or reorder. The appeal of these techniques lies in the fact that the winners of the auction market may be highly concentrated, thus reducing their authority has many benefits.
memory pool encryption
A crucial technology for the successful implementation of many such designs (specifically, BRAID or APS versions, which have strict limitations on auction functionality) is the encrypted memory pool. The encrypted memory pool is a technology where users broadcast their transactions in encrypted form, attaching some form of validity proof, and the transactions are included in the block in encrypted form, while the block builders are unaware of their contents. The transaction contents are published later.
The main challenge of implementing a cryptographic memory pool is to come up with a design that ensures all transactions will eventually be disclosed: a simple "commit and disclose" scheme does not work, as the choice to disclose or not disclose, if voluntary, itself represents a "last mover" influence on the block that can be exploited. The two main techniques are (i) threshold decryption and (ii) delayed encryption, which is a primitive closely related to the verifiable delay function (VDF).
What connections exist with existing research?
Explanation of MEV and Builder Centralization:
MEVBoost:
Enshrined PBS (the early proposed solutions to these issues):
Mike Neuder's list of related reading materials on inclusion lists:
Includes list EIP:
FOCIL:
Max Resnick's BRAID demonstration:
"Priority is what you need," Author: Dan Robinson:
About the multi-proposer widget and protocol:
VDFResearch.org:
Verifiable Delay Functions and Attacks (with a focus on RANDAO setup, but also applicable to encrypted memory pools):
MEV Execution Ticket Capture and Decentralization:
APS Centralized:
Multiple MEV and inclusion list:
What else needs to be done, what needs to be weighed?
We can regard all the above schemes as different ways to partition the permissions for participating in staking, arranged from lower economies of scale ("dumb-pipe") to higher economies of scale ("specialization-friendly"). Before 2021, all these permissions were bundled into a single participant:
The core issue is: any meaningful power still held by stakeholders could ultimately become "MEV-related" power. We want a group of highly decentralized participants to hold as much power as possible; this means (i) giving a large amount of power to stakeholders, and (ii) ensuring that stakeholders are as decentralized as possible, which means they have little to no integration incentives driven by economies of scale. This is a difficult tension to navigate.
A special challenge is multi-block MEV: in some cases, if the auction winner captures multiple slots in succession and is not allowed to make any MEV-related transactions in blocks other than the last block they control, they can earn more money. If the inclusion list forces them to do so, then they may try to circumvent it by simply not publishing any blocks during those time periods. People can create unconditional inclusion lists, and if the builder does not provide one, that inclusion list will directly become the block, but this makes the inclusion list related to MEV. The solution here may involve some compromises, including accepting some low-level incentives to bribe people to include transactions in the inclusion list.
We can view FOCIL + APS as follows. Stakers continue to retain power over the left side of the spectrum, while the right side of the spectrum is auctioned to the highest bidder.
BRAID is entirely different. The "staker" portion is larger, but it is divided into two parts: light stakers and heavy stakers. At the same time, since transactions are sorted by priority fees in descending order, the selection at the top of the block is effectively auctioned through the fee market, and this scheme can be seen as similar to PBS.
Please note that the security of BRAID largely depends on the encrypted memory pool; otherwise, the block top auction mechanism is easily susceptible to strategic stealing attacks (essentially: copying other people's transactions, swapping the receiver's address, and paying a high fee of 0.01%). This demand for pre-inclusion privacy is also why implementing PBS is so tricky.
Finally, a more "aggressive" version of FOCIL + APS, for example. The options determined by APS only at the end of the block are as follows:
The main remaining tasks are (i) to focus on consolidating various proposals and analyzing their consequences, and (ii) to combine this analysis with an understanding of the goals of the Ethereum community, namely what forms of centralization it will tolerate. Each individual proposal also needs to complete some work, such as:
Continue to focus on the design of the crypto memory pool, achieving a level where our design is both robust and fairly simple, and seems ready to be incorporated.
Optimize the design of multiple containing lists to ensure that (i) does not waste data, especially in the context of containing lists that include blobs, and that (ii) is friendly to stateless validators.
More work on optimal auction design for APS.
Additionally, it is worth noting that these different proposals are not necessarily incompatible crossroads with each other. For example, the implementation of FOCIL + APS can easily serve as a stepping stone for implementing BRAID. An effective conservative strategy is the "wait-and-see" approach, where we first implement a solution that restricts the powers of stakers, with most powers being auctioned off, and then gradually increase stakeholders' powers over time as we gain more understanding of how the MEV market operates on the real-time network.
In particular, the centralized bottleneck of staking is:
Centralization of Block Construction (This Section)
Centralization of staking due to economic reasons (next section)
The minimum limit of 32 ETH leads to staking centralization (to be resolved through Orbit or other technologies; see the post about the merge)
Staking centralization due to hardware requirements (resolved in Verge through stateless clients and later ZK-EVM)
Solving any one of these four issues will increase the benefits of solving any of the other issues.
In addition, there is an interaction between block construction pipelines and single-slot finality designs, especially in attempts to reduce slot time. Many block construction pipeline designs ultimately increase slot time. Many block construction pipelines involve the role of the prover in multiple steps of the process. Therefore, it is worth considering both block construction pipelines and single-slot finality simultaneously.
Fixing Staking Economics
What problem are we trying to solve?
Currently, about 30% of the ETH supply is actively being staked. This is sufficient to protect Ethereum from a 51% attack. If the proportion of staked ETH increases further, researchers are concerned about different scenarios: if almost all ETH is staked, there will be risks. These risks include:
Staking has shifted from a profitable task for experts to a responsibility for all ETH holders. As a result, ordinary stakers are likely to be less enthusiastic and will choose the simplest method (essentially, delegating their tokens to the most convenient centralized operators).
If almost all ETH is staked, the credibility of the reduction mechanism will weaken.
A single liquid staking token can take over most of the equity, even taking over the "currency" network effect of ETH itself.
Ethereum unnecessarily issues about 1 million ETH each year. In the case where a liquid staking token gains dominant network effects, a significant portion of that value may even be captured by LST.
What is it and how does it work?
Historically, one type of solution is: if everyone inevitably stakes and liquid staking tokens are unavoidable, then let’s make staking user-friendly to have liquid staking tokens that are effectively trustless, neutral, and maximally decentralized. One simple approach is to limit staking penalties to 1/8, which would make 7/8 of the staked ETH non-reducible, thus qualifying to be placed in the same liquid staking token. Another option is to explicitly create a two-tier staking: "risk-bearing" (reducible) staking.
However, one criticism of this approach is that it economically seems equivalent to something much simpler: significantly reducing the issuance if equity approaches a predetermined upper limit. The basic argument is that if we eventually enter a world where the risk-bearing layer has a return rate of 3.4% and the risk-free layer (which everyone participates in) has a return rate of 2.6%, then this is actually the same return rate as staking Ether, which has a return rate of 0.8%, while simply holding Ether has a return rate of 0%. The dynamics of the risk-bearing layer, including the total amount staked and the degree of centralization, are the same in both cases. Therefore, we should do something simple and reduce issuance.
The main rebuttal to this argument is whether we can make the "risk-free layer" still have some useful function and a certain degree of risk (for example, as proposed by Dankrad here).
Both suggestions imply changing the issuance curve; if the number of shares is too high, the return rate will be very low.
Left: A proposal to adjust the issuance curve put forward by Justin Drake. Right: Another set of proposals proposed by Anders Elowsson.
On the other hand, two-tier staking requires the setting of two return curves: (i) the return rate for "basic" (risk-free or low-risk) staking, and (ii) the premium for risky staking. There are various methods to set these parameters: for example, if you set a hard parameter where 1/8 of the equity is reducible, then market dynamics will determine the premium on the return rate for the reducible equity.
Another important theme here is MEV capture. Nowadays, MEV income (such as DEX arbitrage, sandwiching...) flows to proposers, i.e., stakers. This is completely "opaque" income for the protocol: the protocol cannot know whether it is a 0.01% annual interest rate, a 1% annual interest rate, or a 20% annual interest rate. From multiple perspectives, the existence of this income source is very inconvenient:
This is an unstable source of income, as each stakeholder can only obtain it when a block is proposed, which is currently about once every 4 months. This incentivizes people to join the fund pool for a more stable income.
It leads to an unbalanced incentive distribution: too many proposals, too little proof.
This makes it difficult to implement a cap on equity: even if the "official" return rate is zero, the MEV income alone may be enough to drive all ETH holders to stake. Therefore, a realistic equity cap proposal must actually bring the return close to negative infinity. This poses more risks for stakers, especially individual stakers.
We can solve these issues by finding a way to make MEV revenue clearly visible and capture it within the protocol. The earliest proposal was Francesco's MEV smoothing; nowadays, it is generally believed that any mechanism that pre-auctions the block proposer's rights (or more generally, has enough power to capture almost all MEV) can achieve the same goal.
What are the connections with existing research?
Issue wtf:
Endgame Staking Economics, Positioning Case:
Issuance level attributes, Anders Elowsson:
Validator size limit setting:
Thoughts on the idea of multi-layer staking:
Rainbow Staking:
Dankrad's liquid staking proposal:
MEV smoothing, Author: Francesco:
MEV burn, Author: Justin Drake:
What else needs to be done, what needs to be weighed?
The main task left is either to agree not to take any action and accept the risk that almost all ETH is within LST, or to finalize and reach consensus on the details and parameters of one of the proposals mentioned above. A rough summary of the gains and risks is as follows:
How does it interact with other parts of the roadmap?
An important intersection is related to solo staking. Nowadays, the cheapest VPS capable of running an Ethereum node costs about $60 per month, mainly due to hard disk storage costs. For 32 ETH stakers (which is $84,000 at the time of writing), this reduces the APY to (60 * 12) / 84000 ~= 0.85%. If the total staking return rate is below 0.85%, then solo staking becomes unfeasible for many at this level.
If we want standalone staking to remain viable, this further emphasizes the need to reduce node operational costs, which will be accomplished in Verge: Statelessness will eliminate storage space requirements, which by itself may be sufficient, and then the L1 EVM validity proof will make costs negligible.
On the other hand, MEV destruction can be said to help individual staking. Although it reduces the returns for everyone, more importantly, it reduces the variance, making staking no longer like a lottery.
Finally, any changes in issuance will interact with other fundamental changes in the staking design (e.g., rainbow staking). One particular issue worth noting is that if staking rewards become very low, it means we must make a choice between the following two: (i) lowering the penalties, which reduces the deterrents against bad behavior; (ii) maintaining high penalties, which can lead to a series of situations where even well-intentioned validators, if they unfortunately encounter technical issues or even attacks, may inadvertently receive negative returns.
Application Layer Solutions
The above section focuses on the changes in Ethereum L1, which can address significant centralization risks. However, Ethereum is not just an L1; it is an ecosystem with important application layer strategies that can help mitigate the aforementioned risks. Some examples include:
Dedicated Staking Hardware Solutions — Some companies (e.g., Dappnode) are selling hardware specifically designed to operate staking nodes as easily as possible. One way to make this solution more effective is to pose a question: If users have already spent the effort to get a box running and connected to the internet, what other services (to users or others) can it provide to benefit from decentralization? Examples that come to mind include (i) running a locally hosted Master of Laws for self-sovereignty and privacy reasons, and (ii) running a node for a decentralized VPN.
Team Staking —— Obol's solution allows multiple people to stake together in an M-of-N format. Over time, this may become increasingly popular as stateless and later L1 EVM validity proofs will reduce the overhead of running more nodes, and the benefits of each participant not having to worry about being always online will begin to dominate. This is another way to reduce the cognitive overhead of staking and ensure that solo staking thrives in the future.
Airdrop —— Starknet offers airdrops to individual stakers. Other projects that wish to have a decentralized and value-aligned user base may also consider providing airdrops or discounts to validators identified as potential individual stakeholders.
Decentralized Block Building Market —— By using a combination of ZK, MPC, and TEE, a decentralized block builder can be created, allowing participation and winning in the APS auction game, while also providing pre-confirmation privacy and anti-censorship guarantees for its users. This is another way to improve user welfare in the APS world.
Application Layer MEV Minimization —— Individual applications can be built in a way that “leaks” less MEV to L1, thereby reducing the incentive for block builders to create specialized algorithms to collect MEV. A simple but general strategy is for contracts to queue all incoming operations and execute them in the next block, auctioning off the rights to jump the queue, although this is inconvenient and disrupts composability. Other more complex methods involve doing more work off-chain, as Cowswap does. Oracles can also be redesigned to minimize the value that can be extracted by oracles.
Special thanks to Justin Drake, Caspar Schwarz-Schilling, Phil Daian, Dan Robinson, Charlie Noyes, and Max Resnick for their feedback and review, as well as the discussions from the ethstakers community.
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
Vitalik: The key goals of Ethereum The Scourge phase
Author: Ethereum founder Vitalik; Translated by: Deng Tong, Golden Finance
Note: This article is the third part of a series titled "Possible futures of the Ethereum protocol, part 3: The Scourge" recently published by Ethereum founder Vitalik on the future development of the Ethereum protocol. The second part can be found in Jinse Finance "Vitalik: How the Ethereum protocol should develop in the Surge phase", and the first part is titled "What improvements can still be made to Ethereum PoS". Below is the full text of the third part:
One of the biggest risks facing Ethereum L1 is the centralization of proof of stake due to economic pressure. If there are economies of scale in the core proof of stake mechanism, this naturally leads to large stakeholders dominating, while small stakeholders exit to join large mining pools. This leads to a higher risk of 51% attacks, transaction censorship, and other crises. In addition to the risk of centralization, there is also the risk of value extraction: a small number of people are obtaining value that would otherwise flow to Ethereum users.
Last year, our understanding of these risks significantly increased. As is well known, this risk exists in two key areas: (i) block construction, and (ii) staking capital regulations. Larger participants can run more complex algorithms ("MEV extraction") to generate blocks, thus bringing them higher block revenues. Large participants can also more effectively address the inconvenience of funds being locked by releasing funds as liquid staking tokens (LST) to others. In addition to the direct issues between small stakers and large stakers, there is also the question of whether (or will) there be an excessive staking of ETH.
Scourge 2023 Roadmap
This year, significant progress has been made in blockchain construction, most notably the integration of "the committee inclusion list plus some targeted ordering solutions" as the ideal solution, as well as important research on proof-of-stake economics, including two-layer staking models and reducing issuance to limit the percentage of staked Ether.
The Scourge Key Objectives
This article is divided into three parts
Fix Block Construction
What problem are we trying to solve?
Currently, Ethereum block construction is primarily achieved through the off-protocol propser-builder separation of MEVBoost. When validators have the opportunity to propose a block, they delegate the task of selecting block content to specialized participants known as builders. The task of selecting block content that maximizes revenue is scale-economy intensive: it requires specialized algorithms to determine which transactions to include in order to extract as much value as possible from on-chain financial instruments and user transactions interacting with them (this is referred to as "MEV extraction"). Validators face a relatively lighter scale-economy "dumb-pipe" task, which involves listening for bids and accepting the highest bid, as well as other responsibilities like proof.
The programmatic diagram of what MEVBoost is doing: dedicated builders take on the red tasks, while stakeholders take on the blue tasks.
There are multiple versions, including "Proposer-Builder Separation" (PBS) and "Attester-Proposer Separation" (APS). The differences between them relate to fine-grained details regarding which responsibilities are borne by which of the two participants: broadly speaking, in PBS, validators still propose blocks but receive payloads from builders, whereas in APS, the entire slot becomes the responsibility of the builder. Recently, APS has been favored over PBS because it further reduces the incentives for proposers and builders to coexist. Note that APS only applies to execution blocks that contain transactions; consensus blocks that contain proof-of-stake related data (such as proofs) will still be randomly allocated to validators.
This separation of power helps maintain the decentralization of validators, but it comes at an important cost: participants executing "specialized" tasks can easily become very centralized. This is the state of Ethereum block building today:
Two participants are selecting the content of approximately 88% of the Ethereum blocks. What if these two participants decide to review the transactions? The answer isn't as bad as it seems: they cannot reorganize the blocks, so you don't need 51% of the review to prevent transactions from being included; you need 100%. Under the 88% review mechanism, users typically need to wait for 9 slots (technically an average of 114 seconds, rather than 6 seconds). For some use cases, waiting two minutes or even five minutes for certain transactions is acceptable. But for other use cases, such as DeFi liquidations, the ability to delay the inclusion of others' transactions by a few blocks poses a significant market manipulation risk.
Strategies that builders of blocks can use to maximize profits may also have other negative impacts on users. "Sandwich attacks" can cause users trading tokens to suffer significant losses due to slippage. To clog the chain with these attacks, the Gas prices for other users have been increased.
What is it and how does it work?
The leading solution is to further break down the block production tasks: we will return the task of selecting transactions to the proposer (i.e., the staker), while the builder can only choose to sort and insert some of their own transactions. This is what the inclusion list aims to do.
At time T, a randomly selected staker creates a list of valid transactions under the current state of the blockchain. At time T+1, the block builder (potentially selected in advance through an internal auction mechanism) creates a block. This block must include each transaction from the list, but they can choose the order and can add their own transactions.
The Fork Choice Mandatory Inclusion List (FOCIL) proposal involves a committee composed of multiple inclusion list creators for each block. To delay a transaction by one block, all k inclusion list creators (for example, k = 16) must review the transaction. FOCIL, combined with the final proposer selected through an auction, needs to include the inclusion list but can reorder and add new transactions, commonly referred to as "FOCIL + APS."
Another way to solve this problem is through multiple concurrent proposers (MCP) schemes, such as BRAID. BRAID attempts to avoid dividing the block proposer role into low-scale economic parts and high-scale economic parts, but rather tries to allocate the block production process to many participants, so that each proposer only needs to have a moderate level of complexity to maximize their income. The way MCP works is by allowing k parallel proposers to generate a list of transactions, and then using a deterministic algorithm (for example, sorting by fees from high to low) to select the order.
BRAID does not seek to achieve that running default software dumb-pipe block proposers are the best target. The two easily understandable reasons it cannot do so are:
In BRAID, provers can still be separated and function as a dumb pipe.
Apart from these two extremes, there exists a range of possible designs that fall in between. For example, you could auction roles that only have the right to attach to blocks, without the right to reorder or prepend. You could even allow them to attach or prepend, but not to insert in between or reorder. The appeal of these techniques lies in the fact that the winners of the auction market may be highly concentrated, thus reducing their authority has many benefits.
memory pool encryption
A crucial technology for the successful implementation of many such designs (specifically, BRAID or APS versions, which have strict limitations on auction functionality) is the encrypted memory pool. The encrypted memory pool is a technology where users broadcast their transactions in encrypted form, attaching some form of validity proof, and the transactions are included in the block in encrypted form, while the block builders are unaware of their contents. The transaction contents are published later.
The main challenge of implementing a cryptographic memory pool is to come up with a design that ensures all transactions will eventually be disclosed: a simple "commit and disclose" scheme does not work, as the choice to disclose or not disclose, if voluntary, itself represents a "last mover" influence on the block that can be exploited. The two main techniques are (i) threshold decryption and (ii) delayed encryption, which is a primitive closely related to the verifiable delay function (VDF).
What connections exist with existing research?
Explanation of MEV and Builder Centralization:
MEVBoost:
Enshrined PBS (the early proposed solutions to these issues):
Mike Neuder's list of related reading materials on inclusion lists:
Includes list EIP:
FOCIL:
Max Resnick's BRAID demonstration:
"Priority is what you need," Author: Dan Robinson:
About the multi-proposer widget and protocol:
VDFResearch.org:
Verifiable Delay Functions and Attacks (with a focus on RANDAO setup, but also applicable to encrypted memory pools):
MEV Execution Ticket Capture and Decentralization:
APS Centralized:
Multiple MEV and inclusion list:
What else needs to be done, what needs to be weighed?
We can regard all the above schemes as different ways to partition the permissions for participating in staking, arranged from lower economies of scale ("dumb-pipe") to higher economies of scale ("specialization-friendly"). Before 2021, all these permissions were bundled into a single participant:
The core issue is: any meaningful power still held by stakeholders could ultimately become "MEV-related" power. We want a group of highly decentralized participants to hold as much power as possible; this means (i) giving a large amount of power to stakeholders, and (ii) ensuring that stakeholders are as decentralized as possible, which means they have little to no integration incentives driven by economies of scale. This is a difficult tension to navigate.
A special challenge is multi-block MEV: in some cases, if the auction winner captures multiple slots in succession and is not allowed to make any MEV-related transactions in blocks other than the last block they control, they can earn more money. If the inclusion list forces them to do so, then they may try to circumvent it by simply not publishing any blocks during those time periods. People can create unconditional inclusion lists, and if the builder does not provide one, that inclusion list will directly become the block, but this makes the inclusion list related to MEV. The solution here may involve some compromises, including accepting some low-level incentives to bribe people to include transactions in the inclusion list.
We can view FOCIL + APS as follows. Stakers continue to retain power over the left side of the spectrum, while the right side of the spectrum is auctioned to the highest bidder.
BRAID is entirely different. The "staker" portion is larger, but it is divided into two parts: light stakers and heavy stakers. At the same time, since transactions are sorted by priority fees in descending order, the selection at the top of the block is effectively auctioned through the fee market, and this scheme can be seen as similar to PBS.
Please note that the security of BRAID largely depends on the encrypted memory pool; otherwise, the block top auction mechanism is easily susceptible to strategic stealing attacks (essentially: copying other people's transactions, swapping the receiver's address, and paying a high fee of 0.01%). This demand for pre-inclusion privacy is also why implementing PBS is so tricky.
Finally, a more "aggressive" version of FOCIL + APS, for example. The options determined by APS only at the end of the block are as follows:
The main remaining tasks are (i) to focus on consolidating various proposals and analyzing their consequences, and (ii) to combine this analysis with an understanding of the goals of the Ethereum community, namely what forms of centralization it will tolerate. Each individual proposal also needs to complete some work, such as:
Additionally, it is worth noting that these different proposals are not necessarily incompatible crossroads with each other. For example, the implementation of FOCIL + APS can easily serve as a stepping stone for implementing BRAID. An effective conservative strategy is the "wait-and-see" approach, where we first implement a solution that restricts the powers of stakers, with most powers being auctioned off, and then gradually increase stakeholders' powers over time as we gain more understanding of how the MEV market operates on the real-time network.
In particular, the centralized bottleneck of staking is:
Solving any one of these four issues will increase the benefits of solving any of the other issues.
In addition, there is an interaction between block construction pipelines and single-slot finality designs, especially in attempts to reduce slot time. Many block construction pipeline designs ultimately increase slot time. Many block construction pipelines involve the role of the prover in multiple steps of the process. Therefore, it is worth considering both block construction pipelines and single-slot finality simultaneously.
Fixing Staking Economics
What problem are we trying to solve?
Currently, about 30% of the ETH supply is actively being staked. This is sufficient to protect Ethereum from a 51% attack. If the proportion of staked ETH increases further, researchers are concerned about different scenarios: if almost all ETH is staked, there will be risks. These risks include:
What is it and how does it work?
Historically, one type of solution is: if everyone inevitably stakes and liquid staking tokens are unavoidable, then let’s make staking user-friendly to have liquid staking tokens that are effectively trustless, neutral, and maximally decentralized. One simple approach is to limit staking penalties to 1/8, which would make 7/8 of the staked ETH non-reducible, thus qualifying to be placed in the same liquid staking token. Another option is to explicitly create a two-tier staking: "risk-bearing" (reducible) staking.
However, one criticism of this approach is that it economically seems equivalent to something much simpler: significantly reducing the issuance if equity approaches a predetermined upper limit. The basic argument is that if we eventually enter a world where the risk-bearing layer has a return rate of 3.4% and the risk-free layer (which everyone participates in) has a return rate of 2.6%, then this is actually the same return rate as staking Ether, which has a return rate of 0.8%, while simply holding Ether has a return rate of 0%. The dynamics of the risk-bearing layer, including the total amount staked and the degree of centralization, are the same in both cases. Therefore, we should do something simple and reduce issuance.
The main rebuttal to this argument is whether we can make the "risk-free layer" still have some useful function and a certain degree of risk (for example, as proposed by Dankrad here).
Both suggestions imply changing the issuance curve; if the number of shares is too high, the return rate will be very low.
Left: A proposal to adjust the issuance curve put forward by Justin Drake. Right: Another set of proposals proposed by Anders Elowsson.
On the other hand, two-tier staking requires the setting of two return curves: (i) the return rate for "basic" (risk-free or low-risk) staking, and (ii) the premium for risky staking. There are various methods to set these parameters: for example, if you set a hard parameter where 1/8 of the equity is reducible, then market dynamics will determine the premium on the return rate for the reducible equity.
Another important theme here is MEV capture. Nowadays, MEV income (such as DEX arbitrage, sandwiching...) flows to proposers, i.e., stakers. This is completely "opaque" income for the protocol: the protocol cannot know whether it is a 0.01% annual interest rate, a 1% annual interest rate, or a 20% annual interest rate. From multiple perspectives, the existence of this income source is very inconvenient:
We can solve these issues by finding a way to make MEV revenue clearly visible and capture it within the protocol. The earliest proposal was Francesco's MEV smoothing; nowadays, it is generally believed that any mechanism that pre-auctions the block proposer's rights (or more generally, has enough power to capture almost all MEV) can achieve the same goal.
What are the connections with existing research?
Issue wtf:
Endgame Staking Economics, Positioning Case:
Issuance level attributes, Anders Elowsson:
Validator size limit setting:
Thoughts on the idea of multi-layer staking:
Rainbow Staking:
Dankrad's liquid staking proposal:
MEV smoothing, Author: Francesco:
MEV burn, Author: Justin Drake:
What else needs to be done, what needs to be weighed?
The main task left is either to agree not to take any action and accept the risk that almost all ETH is within LST, or to finalize and reach consensus on the details and parameters of one of the proposals mentioned above. A rough summary of the gains and risks is as follows:
How does it interact with other parts of the roadmap?
An important intersection is related to solo staking. Nowadays, the cheapest VPS capable of running an Ethereum node costs about $60 per month, mainly due to hard disk storage costs. For 32 ETH stakers (which is $84,000 at the time of writing), this reduces the APY to (60 * 12) / 84000 ~= 0.85%. If the total staking return rate is below 0.85%, then solo staking becomes unfeasible for many at this level.
If we want standalone staking to remain viable, this further emphasizes the need to reduce node operational costs, which will be accomplished in Verge: Statelessness will eliminate storage space requirements, which by itself may be sufficient, and then the L1 EVM validity proof will make costs negligible.
On the other hand, MEV destruction can be said to help individual staking. Although it reduces the returns for everyone, more importantly, it reduces the variance, making staking no longer like a lottery.
Finally, any changes in issuance will interact with other fundamental changes in the staking design (e.g., rainbow staking). One particular issue worth noting is that if staking rewards become very low, it means we must make a choice between the following two: (i) lowering the penalties, which reduces the deterrents against bad behavior; (ii) maintaining high penalties, which can lead to a series of situations where even well-intentioned validators, if they unfortunately encounter technical issues or even attacks, may inadvertently receive negative returns.
Application Layer Solutions
The above section focuses on the changes in Ethereum L1, which can address significant centralization risks. However, Ethereum is not just an L1; it is an ecosystem with important application layer strategies that can help mitigate the aforementioned risks. Some examples include:
Special thanks to Justin Drake, Caspar Schwarz-Schilling, Phil Daian, Dan Robinson, Charlie Noyes, and Max Resnick for their feedback and review, as well as the discussions from the ethstakers community.