The Scourge
The Scourge
.
.
MEV markets
burn in ePBS
building
execution tickets
production
pipeline
minimzation
preconfimations
experiance track
effective balance
operator usability
stake capping
to liquid staking
centralization
Extra-protocol MEV Markets
Live
MEV is inherent in any system with sufficient economic activity,
and is therefore a problem to be mitigated, not solved. This "upgrade" signals the Ethereum community's
successful partial commoditization of MEV via an extra-protocol market. Previously, the majority of MEV was captured by sophisticated
agents, and was not meaningfully redirected to validators, let alone users. Validators now receive the majority of MEV.
This effort was spearheaded by Flashbots.
Resources
Explore ePBS
Ongoing Research
From a practical perspective, Ethereum has already separated block proposers and block builders.
However, this is facilitated by third parties and not necessarily permanent.
At this point, it makes little economic sense for
a block proposer (validator) to spend resources building a block, given they will ultimately receive much of the MEV from its ordering in any case. As such, proposing and building
have been effectively separated from an economic perspective (there are a few dozen builders that dominate the market). There is reason to enshrine this seperation at the protocol level, however, since it may not always be the case.
Moreover, if we enshrine PBS alongside Inclusion Lists, we can force the builders to include transactions that meet some threshold of gas and time.
By doing so, we can effectively prohibit censorship via block builders. It also opens the door for other MEV solutions, such as burning.
Resources
Inclusion Lists
Ongoing Research
While block building and block proposing are not required to be done by different parties, more than 90% of blocks today
are built with MEV-Boost and by professional block builders. In other words, while they represent a minority group, validators may still build
their own blocks. There are anti-censorship and MEV mitigation reasons why we want to enshrine this seperation at the protocol level.
Some block builders (and relays) may choose to not incorporate
transactions from certain addresses sanctioned by the United States government (or other organizations). It is possible to create
a set of criteria where a block builder must include transactions that have met some threshold of relative priority fee, AND, have
not been included after a certain number of slots.
We call these Inclusion Lists, and they are easier to implement after enshrining PBS. I.e.,
if the proposer and builder are the same entity, it's a little trickier due to conflicting incentives.
Resources
Explore MEV Burn
Ongoing Research
To understand the potential benefits of an MEV burn, one should
first familiarize themself with the MEV supply chain. By nature, all MEV originates from user order flow (the beginning of the supply chain), and flows downstream to searchers,
builders, and finally, validators.
While much of this may change after Account Abstraction and private mempools become common, the majority of MEV today is captured by validators.
Some believe the most "fair" MEV treatment would be to burn all the extracted ETH, therefore benefiting all ETH holders, rather than only those running validators.
This research is in early stages, and ePBS is prerequisite, so don't expect it soon.
Resources
Distributed Block Building
Ongoing Research
The current and future
state of PBS means that most blocks are being built by a few dozen professional operators, which isn't ideal: we've created another centralization
vector. To the extent that the transactional flow and MEV supply chain begins to centralize around these block builders,
it may became paramount to decentralize this block building process,
which could be tackled in a number of ways.
But it’s important to remember that other MEV solutions, such as MEV Burn, would greatly alter the incentives of block builders.
Will this problem be relevant if there’s little money to be made by the class of professional builders? Furthermore, Inclusion Lists will limit
the downsides of centralized block building.
Therefore, it's perhaps best to say that decentralized block building is an aspiration, but we're not sure the best
way to do it, or when it should become the priority within The Scourge.
Resources
Explore Execution Tickets
Ongoing Research
This change would introduce an in-protocol market for buying and selling tickets that grant future block proposal rights. These tickets, dynamically priced to maintain a target number in circulation, would be one-time use and valid only for a randomly assigned slot. The mechanism involves two lotteries: one for selecting the beacon block proposer and attesters, and another for selecting the execution block proposer and attesters. The beacon block would include an inclusion list of transactions, while the execution block, proposed by the ticket owner, would include the actual transactions on-chain. Validators would post collateral to ensure they produce a single execution block per assigned slot, with penalties for equivocation or being offline.
Execution tickets would differ from the current perpetual validator rights, requiring explicit purchase of future block proposal rights. This system would introduce a primary market for future block space, separate from the secondary MEV-boost auction market. Although conceptually similar to PBS, execution tickets aim to decouple MEV rewards from beacon block production, mitigating centralizing pressures on the validator set. The beacon and execution blocks would be proposed in separate rounds within each slot, each with its own attesting committee to maintain chain integrity.
Resources
Endgame Block Production
Ongoing Research
Endgame Block Production envisions a future where block production is fully decentralized, economically optimized, and resistant to censorship. By aligning incentives across validators, builders, and users, and integrating innovative mechanisms like MEV Burn and Execution Tickets, Ethereum aims to enhance its security, fairness, and resilience.
The current approach aspires towards widely distributing block production responsibilities, managing MEV to benefit the entire network, and enforcing protocol-level mechanisms that include a variety of transactions, effectively preventing censorship and centralization within the block production process.
Resources
- -
App-layer MEV Minimization
Extra-Protocol
This is not an EIP or a protocol change. Rather this item refers to dApp developers building with MEV in mind. In the context of a decentralized exchange, this could
be as simple as preventing front-running through a secondary mempool or an OFA.
Other more elegant solutions such as pre-determined ordering, or encrypting a transaction before inclusion could be possible, thus preventing substantial MEV.
Resources
Explore Preconfirmations
Ongoing Research
This would require proposer slashing and forced inclusion mechanisms, allowing an L1 proposer to become a preconfer by opting into specific slashing conditions. Preconfers issue signed promises to users, receiving preconf tips in return. Transactions with a preconf promise can be included and executed immediately, while non-preconfed transactions are queued until the first preconfer slot is not missed, ensuring execution precedence for preconfed transactions.
Preconfers are prioritized based on their slot position, with two types of slashable faults: liveness faults and safety faults. Users seeking preconfs acquire promises from the next preconfer in the proposer lookahead. Preconfers may use public APIs or p2p gossip channels to advertise and manage promises, with fallback options for resilience against faults. To mitigate risks like replay attacks and ensure fair exchange, various strategies such as public promise streams, mutually trusted relays, and cryptographic protocols may be employed.
Resources
Raise Max Effective Balance
Awaiting Inclusion in Prague-Electra
Increase the Maximum Effective Balance for Ethereum validators from 32 ETH to 2048 ETH, would address outdated constraints that stem from execution sharding—a previous scaling solution. This shift would simplify operations for those staking large amounts of ETH, reducing the number of required validators and easing network congestion. By consolidating many smaller validators into fewer, larger ones, the proposal aims to enhance overall network efficiency and scalability, allowing for faster validator onboarding and expanded data capacity.
Additionally, MaxEB levels the playing field for smaller node operators by allowing them to earn rewards on amounts exceeding 32 ETH without waiting to accumulate full 32 ETH increments. This change would enable more frequent compounding of earnings, making it easier for individual stakers to grow their stakes and benefit from the network's rewards system. Thus, while MaxEB benefits large stakers by reducing operational complexity, it also democratizes the rewards system, supporting both small and large operators alike.
Resources
Improve Node Operator Usability
Ongoing Research
This is a broad step that includes in protocol solutions (as they relate to enabling faster client syncs) and extra protocol software. For instance, it can be difficult for somebody not familiar with a terminal, or command line interface, to spin up an Ethereum node.
Various software programs, like nicenode.xyz, are building single click node installers for those less technically savvy.
Resources
Explore Total Stake Capping
Ongoing Research
There is ongoing debate around adjusting the ETH issuance curve. Some believe this issuance curve was sub-optimally selected, and that ETH holders are currently overpaying for security, and therefore not abiding by the desired “minimal viable issuance” philosophy. Others say economic changes like this hurt Ethereum’s neutrality.
Capping the total amount of ETH staked on the network is one solution to ensuring Ethereum loyally subscribes to minimal viable issuance. This is an active area of research and debate; there is some nuance around disproportionately hurting smaller operators.
Resources
Liquid Staking Centralization
Ongoing Community Effort & Research
It is bad if more than one entity controls a large share of staked ETH; Lido has a lot. There are various limits at which it becomes worse, and it's not clear where the line should be drawn; Danny Ryan famously
suggested 33%. In the limit, a single dominant, centralized LST provider would make Ethereum a de-facto delegated proof of stake system: we need to avoid this.
Similar to client diversity, this could be solved by the community.
There are also some potential technical solutions, but some would consider them less preferable to a social layer remedy.