The Ethereum Roadmap

The Merge, the Surge, the Scourge, the Verge, the Purge, and the Splurge

Mar 30, 2024

Introduction

Before we talk about Ethereum, I just want to say thanks - to all of you. The developers, the researchers, the reply guys (me), the educators, the gigabrains, the founders, et cetera et cetera. None of this was possible without any of you.

This work stands on the shoulders of giants. I didn’t come up with any of the EIPs, or the scaling plan, or any of it. What I did do was take smarter people's ideas and input, pooled it together, and (attempted) to summarize it.

For me, it’s fun to nerd out on things like this, and if you're reading this, I’m guessing you feel similar. Ethereum is an endless black hole of things to learn about, and so it’s really easy to nerd out. It’s a never ending game of learning, touching so many different sectors, like cryptography, finance, programming, game theory, economics, law, etc. On top of that, the community is filled with so many cool, smart, down to earth people, and it is something I’m proud to be a part of.

I have tried to reference all of the topics discussed with links to the original posts/research, so if I missed any, please let me know. I hope you all enjoy it, and thanks again to everyone who helped.

Getting Back on Track; Ethereum

Ethereum was conceived in 2013 by Vitalik Buterin and later developed throughout 2014 by him and other co-founders (Gavin Wood, Charles Hoskinson, Anthony Di Iorio, Joseph Lubin to name a few). Ethereum officially went live on July 30th, 2015.

Ethereum is a decentralized and open source distributed computing platform that allows for the creation of smart contracts, which in turn allows for the creation of decentralized applications. Ethereum has the ability to process general-purpose code, which in more crypto-native terms means it can process smart contracts. Smart contracts facilitate agreements from contract -> contract and/or from contract -> user, which means that different parties (contracts & users) can enforce and verify agreements between each other. This was (and is) a huge unlock for the crypto industry.

Smart contracts operate on an if-then logic, meaning that if X event occurs, then Y will follow. Unlike real world contracts, smart contracts are auto executing and programmed onto a blockchain, in this case Ethereum. Ethereum made it so applications and developers no longer had to be siloed into the limitations of certain blockchains, like Bitcoin for example, and allowed them to build on something more generalizable that can facilitate agreements via smart contracts.

With the ability to natively support smart contracts, Ethereum has ushered in hundreds of applications to come and build on top of the shared platform, and compose with other applications doing the same. The composability that Ethereum unlocks can be analogized to lego: smart contracts are like lego pieces that can mix and match with other lego pieces, and this composability is what made things like DeFi (money legos) possible.

source

Roadmap Overview

Vitalik and the community have released plans to improve Ethereum over the next 5-10 years and I am going to break them down. I'll start by showing you the former roadmap to serve as a reference point, and then I’ll go over the current roadmap.

The former roadmap, presented by Vitalik in 2022:

And the current roadmap:

This report is going to break down each section and each subsection of the current roadmap.

Thanks to Mattison Asher for comments.

Enjoy! Thanks for reading :)

The Merge: Full Transition to Proof of Stake

Goal: Have an ideal, simple, robust and decentralized Proof-of-Stake consensus.

Status: More than halfway complete!! I’d say around 60%.

Ethereum’s transition to Proof of Stake occurred on September 15th, 2022, with withdrawals shipping 7 months later in April. What’s left to do in this section would be to implement SSLE (single secret leader election), SSF (single-slot finality), further develop DVT, view merge, fork choice improvements, quantum safe signatures, and continue to increase the validator count.

What’s Been Implemented?

Beacon Chain Launch: The Beacon Chain launched on December 1st, 2020. It was the first step in Ethereum's transition to PoS, besides all of the initial research & development that went into PoS.
Warmup Fork (Altair): Altair was another important step in the transition to PoS. It served as a test for the Beacon Chain & its validators, ensuring they were ready for the big changes that came with the merge (like merging Ethereum mainnet with the Beacon Chain).
The Merge: The Merge went live on September 15th, 2022, and transitioned Ethereum from a Proof of Work consensus mechanism to a Proof of Stake one.

Withdrawals: Withdrawals were enabled on April 12th, 2023 as part of the Shanghai/Capella upgrade. Enabling withdrawal functionality finally allowed staked ETH to leave the consensus layer (the Beacon Chain) and go onto the execution layer to be transacted with.

What’s Left To Implement?

Distributed Validators
Single Slot Finality (SSF)
Secret Leader Election (SLE)
Other Fork-Choice Improvements
View Merge
Quantum-Safe Signatures
Increase Validator Count

The Merge

The Merge is finally complete!! Ethereum has successfully moved from Proof of Work (PoW) to Proof of Stake (PoS), with the transition going extremely smooth. Huge congratulations to the development team and the Ethereum community. The Merge is just an incredible technical feat, being one of the most complex upgrades to any cryptocurrency network ever, and was easily the most important development of 2022.

Let's dive a little deeper into Proof of Stake, and on why Ethereum decided to make the change.

What is Proof of Stake?

Proof of Stake (PoS) is a consensus mechanism used by blockchains, similar to Proof of Work (PoW).

A PoW system has participants called “miners” who use hardware and electricity to solve complex mathematical puzzles to validate and propose blocks. This works differently from a PoS system, where participants called “validators” purchase the native token of a protocol and put it up as “stake,” allowing them to then validate transactions and propose blocks.

Staking just means to lock up a certain amount of cryptocurrency as collateral to a blockchain, subjecting you to rewards and (potential) penalties. To become a validator on Ethereum, you buy the native token of the network, ETH, and put it up as stake on the blockchain, Ethereum. How much ETH you have will determine whether you can solo stake (32 ETH minimum), or use a third party service (no minimums).

When a validator on Ethereum behaves accordingly, they are rewarded by the network in three ways: protocol emissions, MEV, and inclusion fees. When a validator fails to participate (e.g. going offline), they will miss out on rewards, but when a validator misbehaves (e.g. double signing), they can be penalized, aka slashed. To give a little more context, validator misbehavior can describe a couple things, like:

Double signing
Surrounding votes
Downtime
Invalid block proposals
Unresponsiveness during finality

These behaviors are viewed as an attack and will not be tolerated by the protocol.

Carrots & Sticks

PoW systems only offer carrots (rewards) while PoS systems offer both carrots and sticks (rewards & penalties). This simple distinction has a massive impact on what can be built on top of the different mechanisms.

Benefits of Proof of Stake?

Vitalik had a great blog post covering the reasons to switch to Proof of Stake in this piece: Why Proof of Stake, where he describes 3 reasons why Proof of Stake is a superior blockchain security mechanism compared to Proof of Work.

Security: Proof of Stake offers more security for the same cost.
Attacks: Attacks are much easier to recover from in Proof of Stake.
Decentralization: Proof of Stake is more decentralized than ASICs.

Diving Deeper:

Benefit #1 - Security: “Proof of Stake offers more security for the same cost.”

Uh, okay. How? By eliminating expensive computation.

In PoW, miners need to invest in powerful hardware, such as specialized mining rigs, so they can then consume substantial amounts of electricity and solve complex mathematical puzzles. The miner that solves the puzzle first will get the block reward (6.25BTC). Buying and maintaining mining rigs requires a significant investment and is highly competitive, and so there is a very high barrier to entry to becoming a successful miner.

In PoS, the need for computational work is eliminated or significantly reduced. This is because validators are chosen based on the number of tokens they hold and are willing to stake as collateral, rather than the computational power they possess. This eliminates the need for expensive mining equipment and reduces the associated costs, making the network more secure for the same investment.

Vitalik made a great point on this topic: “Unlike ASICs, deposited coins do not depreciate, and when you’re done staking you get your coins back after a short delay. Hence, participants should be willing to pay much higher capital costs for the same quantity of rewards.”

I just want to point out that while it is true that deposited coins don’t depreciate like an ASIC will, they can still go down in value. ETH is volatile, so be mindful of this.

Now, remember, the more computation you control on a PoW system means the higher chance you have of solving the mathematical problem first, and therefore a better chance of getting the block reward. This works very similarly on PoS - the more stake you have, the higher the chance you are chosen to propose the next block and receive the block reward.

Benefit #2 - Attacks: “Attacks are much easier to recover from in Proof of Stake.”

Let’s go over a few types of attacks:

Spawn Camping Attack: A spawn camping attack is when an attacker exploits a vulnerability in a blockchain, which is then fixed by the blockchain by deploying a countermeasure. The countermeasure is successful and removes the attackers initial advantage, though it doesn’t matter. The attacker was prepared to incur the initial cost, and follow it up with continued attacks that require more fixes. This allows the attacker to continuously be at an advantage, similar to how a player can “spawn trap” other players in games like Call of Duty.

The 51% Attack: The 51% attack refers to a blockchain attack where a single entity acquires control of more than 51% of the protocol. This could mean controlling 51% of the hash rate in a PoW system, or controlling 51% of the stake in a PoS system. Having this level of control over a system gives the attacker the ability to exploit the network and potentially destroy it in the process. Specifically, it allows the exploiters to take control of future block propagation and change transactions in current/future blocks. Furthermore, any transactions completed while the attacker(s) is in control of the chain would be able to be reverted by the attacker(s). Reverting transactions would allow the attacker(s) to spend those same coins again, called a double-spend attack. In other words, double spending means the same unit of cryptocurrency can be used more than once, and can be detrimental to a blockchain.

These are some of the attacks that can happen to blockchains. Let’s talk about why PoS systems can handle them better than PoW systems:

Slashing Mechanism: Proof of Stake introduces a slashing mechanism where validators' staked tokens can either be partially or fully destroyed as a slashing penalty for misbehavior or malicious activity. When a validator tries to attack the network or acts against consensus rules, their stake (and not anyone else's) can be slashed. Slashing penalties present a huge incentive to act accordingly, as validators risk losing a partial or full amount of their stake when misbehaving. There is no equivalent to slashing in PoW systems as they can only offer rewards, unlike PoS which can offer rewards and penalties. Here’s a Vlad Zamfir quote on slashing and Proof of Work: “It would be like if the ASIC farm burned down when it mined an invalid block.”
Majority Stake: Proof of Stake systems select the next blocks validator based on their token holdings (ETH staked), and the more ETH staked, the higher chance you get selected to validate the next block. This works similarly in PoW, where computational power determines mining rewards. Because of this fact, attackers in either system look to acquire as much computation or stake as possible to then have control over the network. Although maybe counterintuitive, successfully acquiring a majority stake in a PoS system is much harder than acquiring a majority of computation in an ASIC dominated PoW system.

Why is That?

Let’s say there is an attack on an ASIC based system and the attacker is trying to control the majority of computation by acquiring all the ASICs. The system can respond to the initial attack by hard-forking to change the PoW algorithm, which will render all ASICs useless (both honest & attacking miners). This is a step in the right direction, however, if the attacker can accept the blow of the initial cost related to the ASICs, he/she can potentially continue the attack. This is because the chain won’t have enough time to develop and distribute new ASICs for the updated algorithm, and will have to revert to using GPUs. Because GPUs are so cheap relative to ASICs, the attacker can (potentially) continue the attack by buying up all of the GPUs and acquiring a majority of computation. Also, it’s important to note that there are services that lease out GPUs and ASICs, which could enable this attack to occur more easily.

The Same Attack on Ethereum (PoS):

Acquiring the majority stake means you have to buy a majority of the ETH that is staked, which is a lot (as of writing, 26% of ETH is staked, which is 31M ETH or $123B!). Buying $123B of ETH is basically impossible to do at once, and even if it was possible, the price would rise dramatically. The contrast to Bitcoin is noticeable here: attacking Bitcoin gets cheaper the longer the attack goes on as the chain has to switch from using ASICs to GPUs, whereas attacking Ethereum gets more expensive the longer it goes on as the attacker is constantly forced to buy more of the same token. Ethereum also has the ability to respond to the attacker by slashing their coins, ultimately forcing them to buy more. The more the attacker tries to buy, the more they will push the price higher. It’s impossible to amass such a large stake without significantly impacting the market price, and at some point the attacker will run out of money.

In Vitalik's words: “The game is very asymmetric, and not in the attackers favour.”

Benefit #3 - Decentralization: “Proof of Stake is more decentralized than ASICs.”

Staking is much easier to profitably participate in when compared to becoming a profitable miner. Bitcoin mining is dominated by ASICs, and setting up an ASIC farm to mine BTC will cost you millions of dollars. Solo staking isn’t exactly cheap (32 ETH), but it is cheaper than setting up a successful ASIC farm.

On Ethereum, it’s possible to become a solo staker if you meet the requirements: 32 ETH and some hardware. The Ethereum community encourages people who can solo stake to do so as it massively improves the decentralization properties of the network. It’s great that solo staking is an encouraged option for the Ethereum community, the problem is that it is just too expensive and/or too technically intimidating for the average Joe.

Enter: Staking Providers

You can think of staking providers as the equivalent to Bitcoin mining pools. They do a couple things:

Allow individuals or entities to stake with less than 32 ETH.
Maintain the necessary staking infrastructure: servers, network connectivity, etc.
Assist in setting up validator nodes, configuring necessary software, and meeting the Ethereum networks requirements.
Monitor the nodes, perform any updates, and ensure high uptime.
Offer tools to users like staking dashboards.
Distribute rewards to users.
Unlock capital efficiency.

Aside from allowing you to stake with less than 32 ETH, I think the biggest unlock as a user is the capital efficiency. Staking providers equip you with a liquidity token which represents your staked ETH and is backed 1:1. This token can then be used across the Ethereum ecosystem, instead of sitting idly in a staking contract. Common liquid staking tokens include Lido’s stETH or RocketPool’s rETH. Staking pools seem best suited for most users as 32 ETH is hard to come by ($127,520) and maintaining the technical aspects of staking is difficult.

It’s important to note that centralization issues can arise with staking providers just like how they do in mining pools. As of writing, the most dominant staking provider is Lido with 32% market share, which could become a serious problem if this share keeps growing (some people think that it already is a problem at 32%, read more about the discussion here). It’s important to note that Lido isn’t 1 single validator, as Lido outsources to several service providers, totaling to around 37 trusted parties).

Here’s a view of Ethereum’s staking services and their market shares:

source

And a view of Bitcoins mining pools & their market shares:

source

What are the Problems with Large LSTs?

An LST that has above 33% market share can disrupt finality.
An LST that has above 50% market share can censor the network.
An LST that has above 66% market share can achieve finality.

These are the problems with LSTs gaining larger and larger market share. Some members of the community want Lido to self limit growth, while others are neutral. Lido voted in favour of not self-limiting a while back, while other providers like Rocketpool and Stader have voted in favour of self limiting (specifically, RP voted to self limit at 33%, Stader voted to at 22%).

This is the best discussion/debate I’ve seen over LSTs and their relationship with Ethereum, specifically Lido and its market share. Check the replies.

All in all, securing a PoW system is harder to do as it has higher barriers to entry, whereas staking in a PoS system (whether your solo staking or in a staking pool) is more accessible and open to the average Joe.

Benefit #4 - Energy Expenditure: “The Merge has had huge implications on Ethereum’s energy expenditure and its carbon footprint.”

Some numbers:

Energy expenditure: reduced 99.988%
Carbon footprint: reduced by 99.992%
PoW electricity consumption: 22,900,320 MWh/yr
PoS electricity consumption: 2,600.86 MWh/yr

The numbers are just incredible. This report from CCRI goes really deep into the Merge’s impact on Ethereum's energy consumption.

Look at the drop off in this chart!

& here are the consumption numbers over the past 3 months:

Ethereum’s energy consumption went from averaging above 75 TWh/year to below .01 TWh/year!

Whether you believe PoW is a waste of energy or not, lots of other people do, and it’s generally a headwind from a narrative perspective. ESG is only becoming more entrenched on Wall St. and in the mainstream media, and it seems like the only letter that matters to them is E (environment). Mainstream media, Wall Street, and the like do NOT appreciate things they consider harmful to the environment, period. I think it's a big deal that Ethereum won't have to defend itself from the ESG opposition targeted at PoW blockchains, and can be viewed as a green investment to institutions and other big players.

“It is easier to change the narrative than to win the war.” - DegenSpartan, probably.

We talked about the benefits, now let’s talk about some drawbacks.

Drawbacks to Proof of Stake

Less Established History
Harder to Implement
More Complex
Higher Setup Cost

Drawback #1 - Less Established History: “Proof of Stake is less battle tested compared to Proof of Work.”

The statement has some truth to it. PoW has been the dominant consensus mechanism throughout the life of the crypto industry (though its relevance is declining). In the early -> middle years of crypto (I’ll say 2009-2016), basically every single new protocol adopted Proof of Work as their consensus mechanism, or piggy-backed (merge-mined) off of another Proof of Work protocol.

Ethereum was no different, and was the second biggest PoW chain for much of its lifetime behind Bitcoin, before making the transition to Proof of Stake in 2022. So much activity and research lived on Proof of Work systems before Proof of Stake systems were even conceived, let alone implemented, and so the argument is that PoW is more battle tested then PoS.

Counter-Argument

Although the argument somewhat still holds, the “battle-tested” point in favor of PoW has become weaker over the years. PoS is used by the second largest protocol, Ethereum, along with a lot of other protocols, like Cardano, Solana, Avalanche, Tron, Polkadot, Polygon, Cosmos, Algorand, Mina, etc. A large portion of crypto activity happens on PoS chains, not PoW ones (although PoW chains make up a bigger market capitalization than PoS chains). When I say activity, I mean DeFi (swaps, borrow/lend, stables) NFTs, payments, DAO creation, research, etc etc.

So, I think it's naive to blanketly say “PoW is more battle tested than PoS.”

Now, is PoW more battle tested because:

It was the first consensus mechanism used by crypto protocols and has survived the longest?
It has the most research behind it and has had the longest time in the market?

Yeah, point taken.

But, is PoW more battle tested in terms of hosting applications and the user activity on top?
Can it provide the necessary infrastructure to build the applications and support that activity?

No, not even close.

All of this usage brings feedback, and things are improved accordingly. The infrastructure (L2s, oracles, bridges, wallets, etc) that support this activity are much more mature and more abundant on PoS chains compared to PoW ones. Take Bitcoin for example - the infrastructure just isn’t there.

And although not there yet, the infrastructure could be coming. Ordinals recently hit the scene and have sparked discussion around the infrastructure on Bitcoin and what more needs to be done to host a successful Bitcoin economy in the future. I think it’s great that there is a discussion about Bitcoins (lack of) infrastructure, this just wasn’t happening in previous years.

Also, I think the fact that there is now serious discussion around improving Bitcoins infrastructure highlights an important culture change that’s been ongoing between Ethereum and Bitcoin:

“Ethereum used to be downstream of Bitcoin culture. Now, it’s the other way around.” - David Hoffman.

Drawback #2 - Harder to Implement: “Proof of Stake will never actually be implemented on Ethereum successfully.”

Implementing a PoS mechanism is much more complex than implementing a PoW one, especially when considering that Ethereum was doing a swap of the two systems on a live protocol. Ethereum was basically trying to change the engine of the plane while it was still flying, and so people heavily doubted the upgrade would ever go live.

After many missed timelines and a wait longer than expected, the merge finally came. On September 15th, 2022 Ethereum successfully implemented PoS - and impressively, it didn't skip a beat. Basically nothing went wrong, which is just an incredible technical feat for an upgrade of this size.

Next.

Drawback #3 - More Complex: “PoS is more complex to run than PoW.”

This is true. Validators on Ethereum need to run 3 pieces of software now, compared to only 1 piece previously on PoW. These include an execution node, the beacon node, and a validator client. Running multiple instances of software is more complex than running one piece of software, so no argument here. Proof of Work is also an objectively less complex consensus mechanism than Proof of Stake.

Drawback #4 - Higher Setup Cost: “It’s cheaper to become a miner on PoW than to become a staker on PoS.”

True, PoW has the advantage in the sense that you can become a miner with a balance of 0, whereas with PoS you need to actually have an ETH balance to become a staker. Though I find this to be a weak point - you have to buy mining equipment to become a miner. It’s not free.

Withdrawals

Staking withdrawals have been shipped! Shapella (the Shanghai + Capella upgrade) went live on April 12th, and enabled withdrawals. Withdrawal functionality was the cornerstone of the Shapella upgrade and a main priority for Ethereum developers once the merge was complete. Shoutout to the devs as they did an excellent job.

Read More About Withdrawals: Here, and here

What is the Shanghai/Capella Upgrade?

The Shapella (Shanghai + Capella) upgrade went live on April 12th, 2023. The upgrade enabled withdrawals, which was the final puzzle piece to place on the board of Proof of Stake.

Distributed Validators (DVT)

Distributed Validator Technology (DVT) allows the current duties of an Ethereum validator to be separated among several nodes, who can then all act as one validator together.

Motivation

Distributing the responsibilities of validators can help reduce some of the issues Ethereum validators of today can experience, like downtime, client bugs, hardware failures, config issues, connectivity issues, and more. In a DVT world, if a node fails to do their job, such as not staying online, the connected validator will not be affected and can continue on its course of operations. At its core, DVT is about removing single points of failure for validators, which will improve the robustness of Ethereum’s security.

source

Mental Models

DVT is like a multisig but for staking.

Risks to Staking

Here are the current risks to staking that Ethereum wants to eliminate:

Risk #1 - Key Theft: Institutions trusting one employee to handle the validator key, or individuals trusting institutions to handle the validator key.
Solution: Split a validator key into smaller keys and distribute it (Shamir Secret Sharing). You then recombine signatures from the smaller keys to produce a single signature (Threshold Signature Scheme).

Risk #2 - Node Failure: Connectivity issues, software bugs, hardware failures, config issues.
Solution: DVT uses redundancy to protect from node failure; operate the same node in multiple places. Now, although this helps, it creates another issue: if two nodes are not in the same state, they can vote for two different chains accidentally, resulting in slashing. To solve this issue, we need to reach consensus among these nodes. By achieving consensus between these different nodes you allow for them to vote on the same state and avoid slashing penalties. We will get to consensus later.

How Does DVT Work?

To make DVT work we need to use a few different primitives:

Distributed Key Generation (DKG): Distributed key generation is the process in which key shares are generated and split up amongst a set of validator nodes. Each node will only hold a portion of the validator key, which is opposite of the current architecture where one validator holds the entire key.
Shamir Secret Sharing: Shamir secret sharing allows for the individual key shares to be combined into 1 key. In a DV cluster, each validator has a key share, which can also be thought of as a signature. Using Shamir secret sharing, all of the different signatures (aka key shares) can be combined into 1 final signature, which yields the validator signing key (the private key).

Threshold Signature Scheme (TSS): The threshold signature scheme decides how many different signatures (key shares) are needed to sign something. Reaching the required amount of key shares, aka the threshold, will differ for different clusters of nodes. Some might require 3 out of 4, some might require 4 out of 6 - it all depends.

Multi-Party Computation (MPC): MPC allows multiple different parties to combine their own unique private data (in this case key shares) and secretly reconstruct the private key, without revealing their own data in the process. This setup makes it impossible for any 1 validator to generate the private key, as the validators only have access to their personal key share and no one else's.

Consensus: And finally, we need to reach consensus among these nodes. To do this, a block proposer is selected. Their job is to propose a block and share it with the other nodes in the cluster. The other nodes then add their key shares to the aggregated signature. Once the threshold of signatures is reached, the block is proposed on Ethereum.

Benefits of DVT

Lowers risk of slashing
Eliminates key theft risk
Reduces node failure (connectivity issues, hardware/software bugs, config issues)
Lowers the barriers to entry for solo stakers (don’t need 32 ETH)

Projects Implementing DVT

SSV Network: SSV Network is building an implementation of DVT. SSV’s mainnet went live in September 2023, and so far they have amassed 100+ operators, 2000+ validators, and 70,000+ETH ($278M).

Obol: Obol is also building an implementation of DVT. They recently went live on December 1st. Lido recently announced they will be using Obol (& SSV) to provide DVT to their current set of validators. Here are some stats from the SSV testnet: Lido

Stader Labs: Stader will be adopting DVT technology into the DVT stake pool - one of three pools soon to be offered by them (permissioned and permissionless being the other 2 pools.) The permissionless pool has a bonding requirement of 4 ETH, which is the lowest in the industry. Stader will continue to drop the bonding requirements by at least 50% when the DVT pool goes live, which is currently on testnet with SSV. Stader

Diva Labs: Diva is a liquid staking provider that is fully powered by DVT. Diva stands for distributed validation - aka squad staking, which allows users with less than 32 ETH to pool their assets together. Research is showing that diva operators will only need 1 ETH to run a validator. Diva Labs

ClayStack: A DVT based Ethereum LST. Claystack

Future of DVT

Although there already are live DVT implementations (Obol, SSV), and DVs have been marked as complete on the roadmap, there is still a ton of work to be done. Oisin Kyne (co-founder & CTO of Obol) released a fantastic blog post covering his view on the future of distributed validators, and a roadmap on how to get there.

One-Shot Signatures

One-shot signatures could play a role in the future of DVT.

One-shot signatures are special cryptographic signatures where a private key can only sign one message. The private key cannot be copied and must be destroyed to produce a signature. Despite their quantum basis, the signatures themselves are just bits and bytes, which do not require quantum communication.

Benefits of One-Shot Signatures

Enhanced privacy
Enhanced security
Mitigation of key reuse issues
Lower complexity
Quantum resistant (one shot signature schemes based on hash functions are quantum resistant)

Justin Drake had a great response related to one-shot signatures when asked about the future of DVTs.

Question:

“Is secret shared validator, or DVT a must for Ethereum?”

Justin Drake (bobthesponge1 on reddit) response:

“I've partially changed my mind on this! In the long term, thanks to one-shot signatures, the importance of operators (and therefore the importance of distributing the control of operators) will dramatically go down. The reason is that operators won't be able to slash stakers and trustless delegation will be possible. One-shot signatures won't be ready for decades and in the meantime DVT is a useful mechanism to remove the need to trust a particular operator (e.g. in the context of staking delegation, liquid staking, and restaking).”

Justin also talked about what one shot signatures can unlock:

slashing removal: The double vote and surround vote slashing conditions can be removed.
perfect finality: Instead of relying on economic finality we can have perfect finality that is guaranteed by cryptography and the laws of physics.
51% finality threshold: The threshold for finality can be reduced from 66% to 51%.
instant queue clearing: The activation and exit queues can be instantly cleared whenever finality is reached without inactivity leaking (the default case).
weak subjectivity: Weak subjectivity no longer applies, at least in the default case where finality is reached without the need for inactivity leaking.
trustless liquid staking: It becomes possible to build staking delegation protocols like Lido or RocketPool that don't require trusted or bonded operators.
restaking-free PoS: It becomes possible to design PoS where restaking is neutered.
routing-free Lightning: One can design a version of the Lightning network without any of the routing and liquidity issues.
proof of location: One can design proof-of-geographical-location which use network latencies to triangulate the position of an entity, without the possibility for that entity to cheat by having multiple copies of the private key.

Read more about one shot signatures: Reddit AMA

Closing Thoughts

Staking centralization is a hot topic in crypto (and for good reason). A core tenet of Ethereum is decentralization, and so using technology like DVT to distribute and therefore decentralize the validator set is a big plus for the ecosystem as a whole. Until things like one shot signatures are ready, DVT will serve as an excellent mechanism to reduce the need to trust operators and mitigate the risks involved with that trust.

Single Slot Finality (SSF)

Finality refers to the point in time when a block is fully settled on a blockchain. The SSF upgrade looks to speed up the time it takes to finalize blocks on Ethereum.

Motivation

Ethereum finalizes every 2 epochs (or every 64 slots). Each slot is 12 seconds, and so finalization takes around 12.8 minutes, which is too long. Single slot finality would change this setup so a block is finalized every slot (hence the name).

Finality refers to the point in time when a block is fully settled on a blockchain. Once a block is considered final, it is set in stone and cannot be reversed. That is unless 33% or more of the total ETH staked was compromised. Attackers with over 33% control of staked ETH can stop the chain from finalizing. “If 1/3 or more of the staked ether is maliciously attesting or failing to attest, then a 2/3 supermajority cannot exist and the chain cannot finalize.”

What’s a Slot?

A slot is an opportunity for a block.

Ethereum PoS contains slots and epochs. Each slot (12 seconds) represents a fixed time period within an epoch (approximately 6.4 minutes), meaning there are 32 slots per epoch. At the beginning of each epoch, the entire validator set is randomized into 32 committees, with 1 committee per slot. Each committee votes on the block in their slot, with each validator voting once per epoch. In the following epoch, we double check that everyone has received the votes from the previous epoch. So the voting happens in the first epoch, and the second epoch is to double check everyone received the votes. After two epochs, finalization has been achieved. This is how Ethereum works today.

SSF changes this framework by introducing the notion of finality on a per-slot basis. At the end of each slot, a block proposer is selected to propose a block for that slot. Once the block is successfully proposed and included onchain, finality is achieved.

By guaranteeing that each slot only has one block proposer, and by finalizing the block proposed within that slot, SSF significantly reduces the chance of reorgs. Since only one block is chosen for each slot, there is no competition between multiple branches or forks for the same time period. This means that blocks will not be competing with each other for the same slot (which is the #1 cause of reorgs), and because of that the chance of reorganizations drastically decreases. Reducing reorgs means a more stable and consistent blockchain history and is what we want to achieve.

What’s a Reorg?

A blockchain reorganization (reorg) is what happens in blockchain networks when the existing consensus on a chain is disrupted and the chain of blocks is rearranged. Reorgs can happen for several reasons, such as:

A blockchain produces different blocks at the same time (most common)
Client bugs
Interaction bugs
Malicious attacks

Reorgs result in forks, where there are now two chains. A group of validators known as attesters will vote on the head of the canonical chain, and the block with the most attestations (the most ‘weight’) is the winner.

Single slot finality would take the current 12.8 minute finality time and reduce it to 12 seconds (12 seconds is equal to a single slot on Ethereum today, ergo single slot finality). This would be a massive reduction in time to finality and have several positive implications.

Benefits of SSF

Improved UX: Instead of waiting 12 minutes for your transaction to finalize in a block, your transaction could be finalized in 12 seconds. This is an order of magnitude improvement, and would result in a better UX for everyone. Makes you wonder what could be built on the protocol when finality is 12 seconds and not 12 minutes.

Eliminate Multi-Block Reorgs: Multi block MEV re-orgs can be eliminated as it only takes 1 block for the chain to finalize instead of multiple.

Reduced Bugs/Complexity: LMD-GHOST & Casper-FFG have to interact with each other to operate, which can lead to attacks (balancing attacks, withholding and savings attacks). The complexity that arises from this interaction means that patches are 1.) tough to identify and 2.) tough to fix, with new problems still being discovered. The fork choice rule (in this case, LMD-GHOST) determines which chain is the correct one when there are multiple options. This could be because a reorg occurred, and the fork choice rule has to pick which of the chains is the correct one. With regards to SSF, finality occurs in the same slot as the block proposed - this means there is only 1 block for the fork choice rule to consider. Because there is only 1 block for the fork choice rule to consider, you can either have a fork choice or a finality gadget running. The finality gadget would finalize blocks where 2/3 of validators were online and attesting honestly. If a block is not able to exceed the 2/3 threshold, the fork choice rule would kick in to determine which chain to follow.

Relevant Research/Proposals

I’m going to break-down two posts: paths toward SSF & 8192 signatures per slot post-SSF. Lets start with paths toward SSF:

Paths toward SSF from Vitalik is the OG paper on the topic. The paper doesn’t go over a specific design, but instead asks and (tries to) answer a lot of questions surrounding SSF.

Vitalik starts out with three open questions:

What will be the exact consensus algorithm?
What will be the aggregation strategy (for signatures)?
What will be the design for validator economics?

1.) Developing the Exact Consensus Algorithm

Ethereum wants to implement something that mirrors the Gasper style. This means that under extreme conditions the optimistic chain can revert, but the finalized chain can never revert. As it works today on Ethereum, both the fork choice (LMD-GHOST) and the finality gadget (Casper FFG) are running, though following an SSF implementation, there could be a fork choice or a finality gadget running. This means the finality gadget would finalize blocks where 2/3 of validators were online and attesting honestly, and if a block is not able to exceed the 2/3 threshold, the fork choice rule would kick in to determine which chain to follow. Consensus algorithms to accommodate SSF are in progress, although nothing formal has been released.

2.) Determining the Optimal Aggregation Strategy

To achieve SSF, each validator has to vote on each slot, and with 500k validators voting every 12 seconds, problems like congestion can and will occur. Each vote comes with a signature, and with 500k validators, that’s 500k signatures every twelve seconds!

Enter: signature aggregation. It is an obvious solution, and lucky for us, the efficiency of BLS signatures have gotten incredible throughout the past three years (BLS is the current signature scheme used by Ethereum validators). Important to note that aggregating signatures needs to factor in the level of node overhead the community is willing to accept.

Although its a step in the right direction, aggregating BLS signatures will not be enough to support all the validators participating in SSF. As Vitalik notes in his report paths toward single slot finality, Ethereum has to make one of two sacrifices:

Option 1: Increase validators per committee or the committee count: Ethereum can use 1 or both of these strategies to accommodate a higher validator count.
Option 2: Introduce another layer of aggregation: Take all the signatures and aggregate them into an initial group, and then continue recursively aggregating up the stack, for a total of three layers. Each aggregation step builds on the previous layer's aggregated group, further consolidating signatures and improving efficiency.

Option 1: Results in a much higher load on the peer-to-peer (p2p) network. Meaning that more data needs to be transmitted and processed across the network, resulting in worse congestion.

Option 2: The trade off here is mainly around latency. Aggregating signatures at multiple layers requires additional steps, which can increase latency. This option also leads to a higher count of p2p subnets, and more p2p subnets means a larger attack surface. Also, preserving the integrity of the view-merge process becomes more complex as it needs to protect against potential malicious actors at each level of aggregation.

Signature Aggregation Proposals

Horn: Collecting Signatures for Faster Finality

Work is still ongoing to determine the optimal aggregation strategy.

3.) Determining the Validator Economics

Despite all the potential improvements around signature aggregation, problems can and will arise if more validators want to participate in the validation process than the network can handle - and in this scenario, how do we decide who gets to participate and who does not? Solutions to this question can result in important trade offs for the staking ecosystem that are viewed as guarantees today.

Some Positives

The adoption of single-slot finality eliminates the need for fixed-size committees and the 32 ETH validator balance cap. Consolidating validator slots previously owned by wealthy users into a smaller number of slots becomes feasible. Zipf's law accurately approximates the distribution of stakers, indicating that removing the balance cap would reduce the number of validator slots to be processed to 65,536. Increasing the cap to 2,048 ETH would only add approximately 1,000-2,000 validators, requiring a modest improvement in aggregation technology or increased load to handle single-slot finality effectively. This consolidation promotes fairness for small stakers who can stake their entire balance, and with rewards being automatically reinvested, allows them to benefit from compounding. However, exceptional cases require special considerations, such as:

Non-Zipfian distributions
Wealthy validators opting out of consolidation
A significant increase in staked ETH

Vitalik had 2 suggestions in regards to these cases:

Suggestion #1: Super Committees

A super committee of a few tens of thousands validators are randomly selected to participate within a round of consensus instead of all validators. This means that each Casper FFG round could happen in a single slot. Every slot, the committee will change, either partially or fully. The size of the committee is determined based on the desired level of security against a 51% attack. Obviously, the cost of the attack should be more than the potential revenue gained. A few factors go into the cost:

What % of ETH should be burned during recovery events?
What should the cost per second on reorg attacks be?
What should be the one time cost of 51% attacking Ethereum?
How long should a 51% attack with stolen funds carry out?

Drawbacks to Super Committees

Lowers cost of attack.
Develop hundreds of lines of specification code to select and rotate committees.
Wealthy validators distributing their ETH among multiple slots means we lose some of the benefit of raising the 32 ETH cap.
In high MEV environments, committees can delay finality to continue collecting fees.

Suggestion #2(a): Capping the Validator Set

To address excessive validator participation, put a cap proportional to the number of validators itself.

A second approach would target a floating minimum balance: if the validator count exceeds the cap, kick the lowest balance validator out. However, this could result in the griefing attack, where wealthy validators split up their stake to push out small validators and increase their rewards (less validators = higher staking yield).

Suggestion #2(b): Capping the ETH Deposited

Another way to address excessive validator participation is to put a cap on staking rewards, with rewards decreasing as the active validator set increases. You might be thinking, isn’t that already the case - the more ETH staked the lower the rewards? Yes, that’s correct. But the current reward curve will be modified even more and decrease faster as the total ETH deposited grows, eventually dropping below 0% at 25 million ETH. Around 33.5 million ETH is the reward curves limit, preventing the validator set from growing beyond that. However, despite rewards dropping to or below zero, validators may still be incentivized to participate in scenarios with high MEV.

Strengths

Avoids queueing dynamics by ensuring an equilibrium among the validator set.

Drawbacks

Discouragement attacks driving out other validators, although costly.

It's possible that most validators become “marginal” which gives an advantage to large validators over small ones.

8192 Signatures Post SSF

Sticking to 8192 signatures per slot post-SSF: how and why is a newer piece of research from Vitalik regarding approaches to SSF.

TLDR: Post SSF, Ethereum should maintain a maximum of 8192 signatures per slot. This massively simplifies technical implementation. The load of the chain is no longer an unknown #, and so clients, stakers, users, etc all have an easier job as they can work off of the 8192 assumption. The 8192 number can be raised through hard forks if needed/wanted.

In the post, Vitalik talked about three viable approaches that could bring us to SSF. Let’s go over them:

Approach 1: Go All-In on Decentralized Staking Pools

Key Idea: Abandon small-scale solo staking (individuals staking on their own) and focus entirely on decentralized stake pools using Distributed Validator Technology (DVT).
Changes: Increase the minimum deposit size to 4096 ETH, cap the total validators at 4096 (~16.7 million ETH), and encourage small-scale stakers to join DVT pools.
Node Operator Role: This role needs reputation-gating to prevent abuse by attackers.
Capital Provision: Open for permissionless capital provision.
Penalties: Consider capping penalties, e.g., to 1/8 of the total provided stake, to reduce trust in node operators.

Approach 2: Two-Tiered Staking

Key Idea: Introduce two layers of stakers - a "heavy" layer (4096 ETH requirement) participating in finalization and a "light" layer with no minimum requirement but adding a second layer of security.
Finalization: Both layers need to finalize a block, and the light layer requires >= 50% of online validators to attest to it.

Benefits: Enhances censorship and attack resistance by requiring corruption in both layers for an attack to succeed.
Use of ETH: The light layer can include ETH used as collateral inside applications.
Drawback: Creates a divide between small-scale and larger stakers, making staking less egalitarian.

Approach 3: Rotating Participation (Committees but Accountable)

Key Idea: Adopt a super-committee design where 4096 currently active validators are chosen for each slot, adjusting the set during each slot for safety.
Participant Selection: Validators with arbitrarily high balances participate in every slot; those with lower balances have a probability of being in the committee.
Incentives: Balance incentive purposes with consensus purposes, ensuring equal rewards within the committee while weighting validators by ETH for consensus.
ETH Requirement: Breaking finality requires an amount of ETH greater than 1/3 of the total ETH in the committee.
Complexity: Introduces more in-protocol complexity for safely changing committees.

The remaining work is in deciding which of the three approaches we want to go with, or if we want to do something else entirely.

Roadmap to SSF

Single-slot finality is not expected to be live for several more years as it’s still in the research stage. Lots of the approaches to SSF are still being researched, and some are still even being conceived. Once the right approach is selected by the community, the heavy work on the upgrade can begin (like specs and testing).

Secret Single Leader Election (SSLE)

What is SSLE?

In the current Proof of Stake consensus mechanism, the Beacon Chain elects the next 32 block proposers at the beginning of each epoch. The list of block proposers includes their IP addresses, which opens the door for potential attackers to target these validators with denial-of-service (DoS) attacks and effectively prevent them from proposing blocks on time.

SSLE could prevent DoS attacks by only revealing the block proposers identity after the epoch is finalized.

In an SSLE world, a group of validators could register to participate in a series of elections, with each election choosing only one leader (ergo single in SSLE). Validators in the group submit commitments to a shared secret, which are then shuffled to prevent identification by others (validators retain knowledge of their own commitment). Then, one commitment is randomly selected, and if a validator recognizes it as their own commitment, they know it's their turn to propose a block.

SSLE can improve privacy for validators, help them avoid DoS attacks, and also reduce protocol waste (by only electing a single leader).

Motivation

Let’s imagine an attacker who is selected as the block proposer for the next slot (slot n+1). The attacker could launch a denial-of-service (DoS) attack on the proposer in the current slot (slot n), causing them to miss their chance to propose a block. If the DoS is successful, the attacker can then “fill the shoes” of the proposer they attacked, and become the leader of that slot. This gives the attacker control over two slots in a row (slot n and slot n+1), which means they have control over the transactions related to these slots. Having two blocks worth of transactions in their control means that the attacker can decide what to do with two blocks worth of MEV, which isn’t ideal.

A big problem with DoS attacks is that they are much more likely to impact individual home validators than they are to impact institutional validators. This is because the big boys have more resources and expertise to defend themselves against attacks compared to the little guy. If individual home validators are disproportionately impacted by these attacks compared to institutional validators, power will centralize to the larger players. Secret Single Leader Election (SSLE) is a possible approach to avoid centralization dynamics playing out at the validator level.

Benefits of SSLE

Protects against denial of service (DoS) attacks
Helps avoid power centralizing to institutional validators
Avoids potential forks, and wastes less effort (this is because SSLE only elects one leader, unlike other SLE implementations)

Relevant Research/Proposals

SSLE: Single Secret Leader Election from Dan Boneh, Saba Eskandarian, Lucjan Hanzlik, and Nicola Grecois is the OG paper on SSLE.
Whisk: Whisk is the leading implementation of SSLE. It is a privacy-preserving protocol for electing block proposers on the Ethereum beacon chain.
SnSLE: SnSLE (Secret non-single leader election) is another option. It aims to mimic the randomness of block proposals in POW systems. A possible way to do this would be using the RANDAO function, which is already used today to randomly select validators. We can use RANDAO to combine independent validators hashes to generate a random number, which forms the basis of the SnSLE proposal. We can use these hashes to choose the next block proposer, for example, by using the lowest value hash.
Simplified SSLE: sSSLE is a maximally simple version of SSLE, research by Vitalik.
SLE: Secret Leader Election research from ethereum.org.

Roadmap to SSLE

SSLE is still in the research phase.

Recently, dapplion released a stable devnet that is running a proof of concept (PoC) of Single Secret Leader Election on a fork of Lighthouse & Geth. Read more about it here.

Fork Choice Improvements

The current fork choice rule in Ethereum is LMD-GHOST. Ethereum’s LMD-GHOST works in tandem with Casper FFG to achieve consensus, colloquially known as Gasper.

Casper FFG = Casper Friendly Finality Gadget
LMD-GHOST = Last Message Driven Greediest Heaviest-Observed Sub-Tree

Gasper is a hybrid (or a compromise) between chain-based consensus & traditional BFT consensus, the two most popular consensus models in Proof of Stake blockchains. Things like Cardano, Polkadot, and others use longest chain protocols (chain based consensus). Things like Tendermint and Hotstuff fall under asynchronous BFT protocols - the Flow blockchain uses Hotstuff, and Cosmos uses Tendermint. And then you have Ethereum which is trying to be both.

Motivation

The LMD-GHOST fork choice rule is a notoriously weak part of Ethereum’s PoS consensus protocol. The interface between Casper FFG and LMD-GHOST is complex and has led to a attacks (such as balancing attacks and “withholding and saving” attacks), along with more inefficiencies still being uncovered. Getting rid of LMD-GHOST would reduce lots of complexity in regards to the consensus protocol, and would therefore harden the security of the system.

From Vitalik:

“The ‘interface’ between Casper FFG finalization and LMD GHOST fork choice is a source of significant complexity, leading to a number of attacks that have required fairly complicated patches to fix, with more weaknesses being regularly discovered.”

Benefits of Improving the Fork Choice Rule

Reduce lots of complexity
Could help avoid several types of attacks

Relevant Research/Proposals

RLMD-GHOST: Recent Latest Message Driven GHOST: Balancing Dynamic Availability With Asynchrony Resilience
Goldfish: Goldfish is a drop-in replacement to LMD-GHOST and is much more performant. Put forward by Francesco D’Amato, Joachim Neu, Ertem Nusrat Tas & David Tse, Goldfish is a promising proposal.
Casper CBC: Casper 101 covers Casper Correct-by-Construction from Vlad Zamfir.
View-Merge: View-Merge as a Replacement for Proposer Boost
Single Slot Finality: Reorg Resilience and Security in Post-SSF LMD-GHOST from Francesco.
Fork Choice: eth2book/forkchoice from Ben Edgington covers Ethereum’s fork choice and the history of it in great detail.

View Merge

*This section was removed from the most recent roadmap iteration, but I’m going to leave it here*

View merge is a proposed upgrade that targets the fork choice rule (LMD-GHOST), which is susceptible to two types of attacks:

Balancing attacks
Withholding and Saving attacks

The idea of view-merge is to empower honest validators to express their views on the fork choice, which will help mitigate both kinds of attacks. By empowering honest validators to vote on the head of the chain, you can reduce the chance that malicious validators get to split the vote and reorg the chain.

From the view merge proposal:

“View-merge can almost be viewed as a reorg resilience gadget, able to enhance consensus protocols by aligning honest views during honest slots. In LMD-GHOST without committees, i.e. with the whole validator set voting at once, it is sufficient to have reorg resilience under the assumptions of honest majority and synchronous network. With committees, i.e. in the current protocol, it is not quite enough for reorg resilience because of the possibility of ex ante reorgs with many adversarial blocks in a row and thus many saved attestations. Nonetheless, the view-merge property is arguably as close to reorg resilience as we can get while having committees.”

High Level

Attesters freeze their fork-choice view Δ seconds before the start of a slot.
Proposers propose based on their current view of the chain's head at the beginning of their slot.
Proposers reference all the attestations and blocks used in their fork-choice in a p2p message that accompanies the block.
Attesters include the referenced attestations in their view and make attestations based on the "merged view."

Conditions For The Mechanism To Work

Network delay < Δ ensures the merged view aligns with the proposer's view, preventing balancing attacks.
Fork-choice output depends solely on the view or referenced objects. Network delay < Δ implies agreement on the fork-choice output and honest validators attesting to honest proposals.

Benefits of View Merge

Not abusable by proposers
More powerful reorg resistance
Higher resistance to balancing attacks
Compatible with dynamic-availability

Related Research/Proposals

Quantum-Safe Aggregation-Friendly Signatures

Quantum computing has the potential to break traditional cryptographic algorithms, such as the widely used RSA and elliptic curve based algorithms. And although quantum computing is probably a few decades away from being a serious threat, all blockchains rely on cryptography and therefore need to be ahead of the curve when it comes to quantum risks. In the context of Ethereum, one of the risks we have is the BLS signature scheme, which relies on elliptic curve cryptography and is known to be broken by quantum computers.

Quantum-safe aggregation-friendly signatures are being considered to enhance protocol security against quantum attacks.

Quantum safe: Cryptographic operations are protected from future quantum attacks.
Aggregation friendly: A signature scheme that can aggregate large amounts of signatures in an efficient manner.

Related Research/Proposals

BLS-Scheme: Aggregation-friendly but not quantum-safe.
STARK-Based Scheme: Quantum-safe but not very aggregation-friendly.
Lattice-Based Scheme: Quantum-safe but not very aggregation-friendly.
Horn: Signature aggregation scheme.

Increase the Validator Count

One of Ethereum's long-term goals is to safely increase the validator count (following an implementation of SSF).

Ways to Increase the Validator Set:

Continue trying to keep hardware requirements as low as possible to allow as many people as possible to participate.
Continue riding the coattails of constant improvements to hardware and bandwidth.

The Surge: Massive Scalability Increases For Rollups Via Data Sharding

Goal: 100,000 transactions per second and beyond (on rollups).

Status: I’d say we are about 35% of the way to completing the Surge section. EIP-4844 is complete and has shipped as of March 13, 2024, however there is still tons of work to be done on the other stuff like danksharding, fraud provers, zk-evms, and quantum safe/setup-free commitments.

What’s Been Implemented?

EIP-4844 Specification is complete!
EIP-4844 Implementation is also complete!
Handful of zk-EVMs: A few zk-EVMs released in 2023, like zkSync Era (March 24th), Polygon zkEVM (March 27th), Linea (July 18th), Scroll (October 8th)
Optimistic Rollup Fraud Provers (Whitelisted Only)

What’s Left To Implement?

Danksharding (Full Rollup Scaling)
Optimistic Rollup Fraud Provers
Quantum-Safe and Trusted-Setup-Free Commitments zk-EVMs
Improve Cross Rollup Standards + Interop

Basic Rollup Scaling: EIP-4844

EIP-4844 is an upgrade that changed the way rollups post data to the Ethereum L1. Instead of using call-data, which is very expensive, rollups now use a new data format, called blobs.

Motivation

Rollups have been chosen as the preferred scaling method to bring Ethereum to mass adoption, as evident by the rollup-centric roadmap. Using a rollup on Ethereum costs significantly less than using mainnet - transfers are currently $.05 on Optimism vs $.85 on mainnet and swaps are $.11 on Optimism vs $4.26 on mainnet. This is great and shows significant progress from a few years ago when rollups weren’t even around. And though it's all well and good that rollups are much cheaper to use than mainnet, they are still just too expensive for many Ethereum users, which is a problem that is only going to accelerate as more and more people are onboarded.

The EIP-4844 upgrade targeted this exact problem: making rollups cheaper. Specifically, the upgrade changed how data is handled by Ethereum and its rollups. Let’s first discuss how data was handled on Ethereum pre EIP-4844, followed by how it will be handled post EIP-4844.

Pre EIP-4844

How data was handled pre EIP-4844: rollups received transactions from users offchain and put them into a “batch” of transactions that was then posted to the L1. The data associated with all of the transactions inside a batch is known as calldata. Rollups (and therefore their users) had to pay for calldata to be posted to Ethereum, and it was not cheap. Posting calldata was amounting to anywhere between 90-99% of rollups expenses. The rollups couldn’t get around the fact that they had to post calldata to the L1, that is unless they wanted to start posting their data offchain and become a validium. For rollups to be cheaper to use without sacrificing their security properties, they had to transition from calldata to a cheaper solution.

Enter: Blobs

Post EIP-4844

How data is handled today (post EIP-4844): Blobs were introduced as part of the EIP-4844 upgrade. Blobs introduce a separate gas market (blobs) and a separate gas type (blob gas, or data gas) for rollups to use, effectively replacing calldata as a cheaper solution (calldata is priced around 16 gas/byte while blob data is priced around 1 data gas/byte). Blob data is verified by consensus nodes via a *sidecar* implementation. It's important to note that blobs can’t be accessed by EVM execution, and only the commitment to the blob can be accessed. This is because blobs only exist in beacon nodes, and not in the execution layer. This setup means that future work on danksharding is contained to the beacon node (the consensus layer) and no work needs to be done on the execution side, which is a big plus.

Blobs let Ethereum rollups to transition to a new format for posting data and start fresh instead of forever trying to optimize and compress calldata to make it cheaper.

*Sidecar*: A sidecar is an auxiliary piece of tech that’s used to enhance the scalability & efficiency of a blockchain and their applications. Sidecar’s can provide things like additional functionalities, data storage, or off chain tx processing. A great example of sidecar technology is MEV-boost.

Pruning

Post-EIP-4844, consensus nodes are required to download all of the data from the beacon chain (this is unlike post-danksharding where nodes will instead download a piece of sharded data via DAS). EIP-4844 contributors recognized that requiring consensus nodes to download all this data from the beacon chain without proper intervention would completely congest the nodes, and so to alleviate storage requirements the data blobs are pruned from the nodes after roughly two weeks (18 days in this case). The goal is to have the data available long enough so that any participants in an L2 ecosystem can retrieve it, but short enough so that disc use remains practical.

Why is Pruning Acceptable?

Pruning the data is acceptable because rollups only need data to be available long enough to ensure honest actors can construct the rollup state. The rollups don’t need the data forever, and so unnecessary data can be pruned after an agreed upon date (18 days). It’s important to note that although the data is pruned, it is not lost, as third parties can step in, such as:

Layer 2s
Decentralized Storage Networks (IPFS, Arweave)
DACs
Voluntary Node Operators
Specialized Data Hosting Services (built specifically for storing pruned blobs)
Academic/Research Institutions
Archive Nodes

Benefits of EIP-4844

Cost Reduction: Blobs are already much cheaper for rollups to use than calldata (EIP-4844 lowered rollup fees by a factor of 5-10x).

Good Intermediate Solution: Danksharding is the endgame of Ethereum, but will take a looong time to implement. Rollups are live now, and so waiting a few years for them to get cheaper is not feasible. The EIP-4844 upgrade made rollups cheaper in the interim while we wait for danksharding.

EIP-4844 Makes the Transition to Danksharding Much Easier: Aside from cheaper costs, EIP-4844 makes the eventual transition to danksharding much easier. This is because many of the features that will be implemented as part of EIP-4844 will also be needed in the danksharding upgrade. Here are some of the danksharding upgrades that will piggy-back off of EIP-4844:

The data-blob transaction format.
KZG commitments to commit to the blobs.
All of the execution layer logic required for danksharding.
Layer separation between beaconblock verification and DAS blobs.
Most of the beaconblock logic required for danksharding.
All of the execution/consensus cross verification logic required for DAS.
A self adjusting independent gas price for blobs.

The Complexity of the Danksharding Upgrade is Isolated to the Consensus Layer: To get from EIP-4844 to full danksharding, a few things have to be done:

1.) PBS
2.) DAS
3.) Enabling 2D sampling
4.) In-protocol requirement for each validator to verify a piece of sharded data
Notice that all of this work needs to be done on the consensus layer and not the execution layer. This means that following EIP-4844’s introduction, the execution layer client teams, rollup developers, etc, will be ready for danksharding and won't have to implement any more changes or do any more work to get ready for the upgrade. This really simplifies the implementation of danksharding following EIP-4844, and is a very underrated benefit of the upgrade.
Isolating Future Sharding Work to the Beacon Node: Blobs only exist in the beacon node (aka the consensus client) and not the execution layer (meaning blobs exist in Lighthouse and not Geth, for example). This means that blobs can’t actually be accessed by EVM execution, and only the commitment to the blob can be accessed by EVM execution. This setup means that any future sharding work falls on the beacon node and the beacon node alone, allowing the execution layer to work on other upgrades.

KZG Ceremony

The KZG ceremony consists of a group of participants that come together to use certain secret information to generate different data sets. Each participant has a job of generating unique data which is then used to generate the parameters needed. We trust these participants to (i) generate secrets, (ii) use the secrets to create & publish data sets, and (iii) to ensure their contributions are kept secret and forgotten. Because we trust these participants to destroy their secrets, the KZG ceremony is known as a trusted setup.

Read More about the KZG ceremony here

Motivation

The KZG ceremony is a key part of EIP-4844 as the upgrade requires a commitment scheme for the underlying data blobs. The scheme needs to be:

Fast to prove and verify
Have small commitment sizes

KZG commitments (aka Kate commitments) meet both of these requirements, and because of that they have been chosen as the commitment scheme for data blobs in EIP-4844.

Trusted Setups

To break down trusted setups more, the ‘unique data’ supplied by a participant is just a secret number, which is combined with other participants secret numbers to create a larger, random number. The final number has to be unknown to anyone, otherwise the entire proof system is vulnerable.

One of the most famous trusted setups in the crypto industry was done by Zcash in 2016. It’s a pretty fascinating story, you can read more here.

Why is a KZG Ceremony Needed?

EIP-4844 needed a commitment scheme to serve the underlying data blobs, specifically one that is fast to prove/verify with small commitment sizes. KZG commitments fit the criteria and so they were selected. The KZG ceremony is used to generate KZG commitments -> KZG commitments generate KZG proofs -> KZG proofs commit blobs of data.

KZG Ceremony Page

Fun Facts

The name proto-danksharding pays homage to two core contributors - the ‘proto’ part comes from proto-lambda (Proto) and the ‘dank’ part comes from Dankrad Feist (Dankrad).
KZG commitments are named after their creators: Aniket Kate, Gregory M Zaverucha, and Ian Goldberg. They wrote the paper in 2010 (Original Paper).
The KZG ceremony for EIP-4844 received 141,416 contributions from different contributors, making it the largest trusted setup in history.
EIP-4844 introduces a new pre-compile called “point evaluation”. Its job is to verify a KZG proof, which claims that the blob (represented by a commitment) consists of the correct data.

Read More: EIP-4844

Roadmap to EIP-4844

EIP-4844 is complete! It was rolled out as part of the Dencun (Deneb + Cancun) upgrade on March 13th, 2024. Next up, danksharding!

Full Rollup Scaling: Danksharding

Danksharding is an evolution to EIP-4844 and is looked at as part of the endgame to scaling Ethereum.

Motivation

The motivation to the danksharding upgrade stems from the same place as EIP-4844: making rollups cheaper. Much cheaper. Rollups are very data heavy, and so they need scaling solutions that are designed to handle data.

Now, EIP-4844 is great because it 1.) achieves the goal of making rollups cheaper, and 2.) it can be implemented much earlier than danksharding. HOWEVER, EIP-4844 just doesn’t provide enough scale for the long term - which brings us to danksharding.

First of all, what is Sharding?

I’m going to briefly go over sharding, Ethereum's original scaling design, colloquially known as ETH 2.0. Read more here.

Sharding means to divide up a network into smaller components called shards. Ethereum’s original sharding design had validators split up between shards (64 of them) who took on the responsibility of storing data and handling transactions in their respective shard. By distributing the workload, the shards increase the throughput of the network, and is why Ethereum initially had plans of adopting the design (although it was eventually scrapped). The conclusion was that the security properties of the shards were not strong enough and that there was too much complexity involved in things like cross-shard communication and shuffling validators.

Ultimately, the rollup-centric roadmap emerged and danksharding replaced the original execution sharding design.

Danksharding

Danksharding (aka data sharding) is looked to be the final boss of scaling solutions on Ethereum. Instead of deploying execution shards like previous designs (ETH 2.0), Danksharding uses data shards. As the name implies, the focus has switched from sharding execution to sharding data. Full nodes & light nodes (the consensus layer) can ensure the data is available by downloading it.

EIP-4844 vs Danksharding

Danksharding is an evolution of EIP-4844. It is built on much of the same foundations as its predecessor, like the blob for example. Both Danksharding and EIP-4844 use blobs, though Danksharding plans to increase the maximum amount of blobs allowed to be in a block, which is a big advantage. More blobs/block = more data/block, which = more txs/block. For reference, EIP-4844 plans to have 3 blobs per block, with each blob offering 0.125MB of space for data.

Another big advantage for Danksharding relative to EIP-4844 is that data availability sampling (DAS) will be used in the process. DAS is a mechanism that allows light clients verify that the data in a block is available by only downloading a portion of it. This is unlike EIP-4844, which requires nodes to download all of the data in a blob. Dankshardings approach is much more efficient.

DAS is way more efficient than downloading an entire block and its implementation will lead to much more nodes participating in data sampling, which means more scale. The more nodes there are, the more data can be handled.

Concrete Numbers

When implemented, Danksharding will increase the maximum number of blobs allowed per block relative to EIP-4844. Danksharding will increase the amount of data available by a factor of around 60x, bringing the available data from around 0.5MB/block (EIP-4844) to around 30MB/block (danksharding). h/t a16z

h/t Sreeram Kannan

Merged Fee Market

Previous sharding designs were much more complex as they had a fixed number of shards that each had distinct blocks and distinct block proposers. Danksharding improves on the design by merging all of this together into one merged fee market. This means that there will only be one proposer who chooses all the transactions & all the data going into a slot, which will massively reduce the complexity of the network.

Benefits of Danksharding (& the Surrounding Upgrades; PBS, DAS)

Lower Fees: Danksharding massively reduces costs for rollups and therefore fees for end users.

Merged Fee Market: Unlike previous designs which had a fixed number of shards that each had distinct blocks and distinct block proposers, danksharding merges the fee market. This means that there will only be one proposer choosing all transactions & all data going into a slot. This massively reduces the complexity of the network.
Redirect Scaling Focus: Finishing the danksharding upgrade would not only be great because 1.)Ethereum would finally have a really solid way to handle data for the long term, but also because 2.)Ethereum could redirect all scaling energy from danksharding to the state side of things and focus on implementing things like state expiry and statelessness (this is really important because long term, state is the bottleneck, not data).
Synchronous Calls Between ZK-Rollups and L1 Ethereum Execution (potentially): Transactions from a shard blob can immediately confirm and write to the L1 because everything is produced in the same beacon chain block.
Improved Censorship Resistance: Splitting the responsibilities of block proposers and block builders makes it much harder for block builders to censor transactions. Things like inclusion lists can be used to make sure no censorship has taken place before the block is proposed.
Proof of DA with Fewer Resources: (Full or light) nodes can be sure that a blob is available and correct by only downloading a small random portion of the blob and not the entire thing.
Reduced MEV: PBS could reduce the risk of frontrunning substantially. This is because pre-PBS-proposers are looking at the highest paying priority fee txs in the mempool, which they can frontrun. Post-PBS-proposers cannot frontrun, as they cannot see the contents of the block. Their job is just to accept the highest bid.
Keeping the Validator Barrier to Entry Low: Ethereum wants to avoid impacting the barrier to entry to become a validator, as doing so would result in a less diverse group of participants. PBS gives the compute-heavy work to the block builders and away from the validators, keeping validator requirements low.

Required Upgrades for Danksharding

Proposer-Builder Separation (PBS).
Data Availability Sampling (PeerDAS & SubnetDAS).
KZG Commitments (will be introduced previously to danksharding as part of the EIP-4844 upgrade).
Parameter Changes (increase the maximum number of blobs per block).
Proof of Custody or similar in-protocol requirements for each validator to verify a particular part of the sharded data in each block.

Proposer-Builder Separation (PBS)

PBS refers to separating the proposer role and the builder role. Block proposing and block building responsibilities will be split into two separate entities.

As it works today, the validator performs both these tasks as they create (aka build) as well as broadcast (aka propose) blocks. In a PBS-world these tasks are divided up - the block builder creates the block and bids it to the proposer in the current *slot*. The proposer then looks through the blocks and chooses the most profitable bid with a valid header. Once chosen, they send the block to other proposers.

By separating the responsibilities of the proposer and the builder, Ethereum can avoid requiring at-home validators to generate commitments and proofs for large blobs of data (32MB in this case), and instead give that responsibility to the block builders. Generating commitments and proofs for blobs is compute-heavy work that requires beefy hardware and so giving this job to block builders instead of validators is in Ethereum’s best interest. The network wants to avoid impacting individual validators as it hurts decentralization and so the compute-heavy work is given to the block builders.

I’m going to go over slots again as a reminder:

Proof of Stake Ethereum contains slots and epochs. Each slot (12 seconds) represents a fixed time period within an epoch (an epoch is approximately 6.4 minutes), meaning there are 32 slots per epoch. At the beginning of each epoch, the entire validator set is randomized into 32 committees, with 1 committee per slot. Each committee votes on the block in their slot, with each validator voting once per epoch. In the following epoch, we double check that everyone has received the votes from the previous epoch. So the voting happens in the first epoch, and the second epoch is to double check everyone received the votes. After two epochs, finalization has been achieved.

Data Availability Sampling (DAS)

Data availability sampling means to sample different segments of data from a blob of data, with the end goal of making sure the data is available and correct. It’s a really innovative solution that will greatly improve node efficiency and network scalability on Ethereum.

DAS works as follows: nodes download some small, random sample of data from a blob, and if enough samples are downloaded successfully, the nodes can be confident the data is available. It’s important to note that the nodes can only be confident that the data is available if it was erasure-coded first - just randomly checking chunks of data without any redundancy scheme could result in missing important transactions like the ones that try to steal your money.

So, to avoid missing important transactions, the data is erasure-coded first. This involves adding redundant information to a dataset by employing a polynomial function over the data and evaluating it at additional points. This redundancy enables the recovery of the original data when necessary.

If you want to understand polynomials better, Jon Charb explains them beautifully here, much better than I could.

Data sampling makes it so that nodes don't need to individually inspect the entirety of the data inside a given blob themselves. They can instead collaboratively validate the network by randomly sampling different data points within a blob. This allows the nodes to ensure that a blob is available and correct, and they only have to download a small piece of data from the blob instead of the whole thing.

The sampling process is significant because it provides a high level of confidence that the entire blob was indeed available and accurately committed. If any part of the blob data is missing or inaccessible during the sampling process, nodes can (and will) quickly identify it and then reject it. Having the ability to reject blobs that have missing or inaccessible data is key. It means only complete and accurate blobs are accepted to the network, and helps the Ethereum network maintain integrity.

So, alongside PBS, DAS is another upgrade that is required to make danksharding possible.

Related to DAS

PeerDAS
SubnetDAS
Efficient DA Self-Healing

PeerDAS

Peer stands for p2p, and DAS data availability sampling. PeerDAS is a stepping stone in between EIP-4844 and danksharding, and will provide more blobs than EIP-4844, but less than danksharding (specifically, PeerDAS is targeting 9 blobs/block, whereas EIP-4844 offers 3 blobs/block).

SubnetDAS

SubnetDAS is a subnet-based proposal where each data sample has its own corresponding subnet. Similar to PeerDAS, it’s an intermediate solution between EIP-4844 & danksharding.

Related Research

Efficient DA Self Healing

Being able to efficiently reconstitute all the data in the harshest network conditions (e.g. malicious validators attacking, or prolonged downtime of a big chunk of nodes).

Related Research

Efficient DA Self Healing - Dom & Mike

Now, the main benefit of DAS is the ability to verify that the data was made available without having to download all of it - but what happens when the data you're verifying was encoded incorrectly? Well, the data not only becomes useless, but potentially harmful. You’re verifying data that isn’t true. This needs to be solved, but how?

KZG Commitments

“DAS allows us to check that erasure coded data was made available. KZG commitments prove to us that the original data was extended properly and commit to all of it” - Jon Charb.

KZG commitments are used in danksharding for the same reason as EIP-4844: making cryptographic commitments to blobs. Think about all of the different blobs of data that are going to be submitted by all of the different rollup providers - each blob has to be *verified* for good behavior via KZG commitments. Specifically, the KZG commitments are used by provers to prove that they 1.)extended the data properly and 2.)are committed to the data. Sampling nodes can then look at these commitments as proof that the data was extended correctly. Incorrect data is useless but also potentially harmful.

*Verified*: To verify a blob a prover has to re-execute the transactions inside the blob to check that the commitment was valid.

Parameter Changes

Following EIP-4844, there is only 1 hard fork needed to get to full danksharding, which is changing the maximum number of blobs per block. It's just a parameter change.

Ethereum x Solana Endgame Similarities

Although popular blockchains like Ethereum and Solana currently have different designs to scaling, their endgame approaches to scaling are very similar; centralized production & decentralized validation. Vitalik pointed this out in his endgame blog post:

The “traditional big blockchain” is Solana in this example. Colluding-node highlighted this point further here.

No Man's Land

There is a large gap in the timeline (we’re talking years) between the proto-danksharding upgrade and a full danksharding implementation. This gives the Ethereum community ample opportunity to make improvements in between the two upgrades. Here are some things we can do:

Erasure code extending current 3/6 target max blobs to something higher like 6/12.
Apply DAS to EIP-4844. Extend the first idea & add DAS on top.

Credit to Terence Tsao for these ideas, you can read further into them here.

EF Research also talked about this and put out more direction on what they want the in-between period from proto-danksharding -> danksharding to look like (youtube)

The goal is to have a 3x the blob space on Ethereum every year for 4 years (more of a meme than a guarantee, but a good goal):

3x #1: EIP-4844 adds 3 blobs per block (2023) although we’re late & 4844 went live March 13, 2024.
3x #2: PeerDAS: Approximately 9 blobs per block, depending on what’s decided (2024).
3x #3: Further DAS improvements (2025).
3x #4: Danksharding (2026).

3x3x3x3=81, meaning Ethereum’s available blob space could be 81x bigger in 4 years!

Roadmap to Danksharding

A full-danksharding implementation is still several years away :(

So much stuff still needs to be done, like DAS & PBS for example, and so it’s going to take a while for us to get there.

EIP-4844 + things like PeerDAS will fill the gaps until we get there.

Rollups

The biggest benefactor of danksharding is rollups. Let’s go over some different rollup projects (ZK, optimistic, volition/validium), as well as the ecosystem surrounding them (RaaS, Rollup SDKs).

Optimistic Rollups: Optimistic rollups process transactions off chain instead of onchain. They come to consensus via fraud proofs.

Optimism
Arbitrum
Metis
Fuel
Mantle
Base
Boba

ZK Rollups: ZK rollups process transactions off chain instead of onchain. They come to consensus via validity proofs.

Loopring
Aztec
Starkware
zkSync
Polygon zkEVM
dYdX
Linea

Validiums/Volitions: Validiums are similar to ZK-rollups, as both enforce transaction integrity via validity proofs. The difference is in the treatment of data: validiums publish transaction data off-chain whereas ZK-rollups publish the data on-chain. Volitions combine the two (zk-rollups & validiums) and give the user the option to either post the data on or off chain.

Polygon: Polygon recently announced they will be transitioning the Polygon PoS chain into a zkEVM validium. Polygon zkEVM
Immutable
Sorare
Myria

Rollup SDKs: Provide software used to build rollups.

RaaS (Rollups as a Service): Hosting provider for deploying & running rollups. Also includes things like APIs, explorers, client SDKs, etc.

Eclipse
Dymension
Caldera
Vistara Labs
AltLayer
Snapchain
Conduit
Saga
Slush
Gelato
Astria

Removing Rollup Training Wheels

Ethereum wants to continue rollup progression by removing the training wheels attached to them. This means a few things:

Trustless Optimistic Rollup Fault Provers
Decentralized Sequencers
Contracts: should be immutable, open source, etc

Optimistic Rollup Fault Provers

Fraud proof = fault proof. Read more about the naming here: Fraud/fault proof rename.

Currently, Ethereum’s biggest rollups (in terms of activity and TVL) are optimistic rollups, with the top two projects being Optimism and Arbitrum. Neither of these projects have a live proof system for the community to use - Arbitrum has a live proof system, but it is only available to whitelisted actors (*this won't be true if/when the BOLD proposal passes, more on that below), and Optimism doesn't even have a live proof system (currently on testnet). For Arbitrum this means that funds can be stolen if none of the whitelisted actors verify the published state, and for Optimism it means that funds can be stolen if an invalid state root is submitted to the system.

Imagine you asked the average crypto participant if fault proofs are live or not on Optimism (assuming they know what both things are), what do you think they would say? I think most people would answer incorrectly and say yes they are live, and that’s a problem. Lots of the marketing surrounding rollups focuses on how they inherit security from the underlying chain, but that is misleading if the community cannot validate the state, or the ability to validate the state is only gatekept to whitelisted actors. We can do better.

Optimistic rollups not having live proof systems is a major censorship risk that needs to be addressed especially when you consider the fact that these two rollups account for 84% of the rollup market share on Ethereum.

Optimism & Arbitrum have been singled out here although this applies to all optimistic rollups without a live proof system.

Steps in the Right Direction

Recently there has been some positive developments from the Rollup ecosystem:

Arbitrum Bold
Optimism Cannon
Métis

Arbitrum Bold: Abritrum announced Bounded Liquidity Delay (BOLD), which brings permissionless validation to Arbitrum chains. By making validation permissionless, BOLD will allow a single honest validator post fraud proofs, whereas previously posting proofs was only available to whitelisted actors. This will greatly improve decentralization.

Read More: BOLD

L2beat will update the fault proof section of Abritrums “risk pie” if/when the proposal passes. If the proposal passes, the state validation (fault proofs) section on the risk pie will go from yellow to green, bringing Arbitrum to ⅘ green pieces. Huge shoutout to Abritrum for taking this initiative.

Arbitrums Risk Pie

Optimism Cannon

Optimism announced that following the shipping of bedrock, their focus has shifted to implementing fault proofs. Hats off to Optimism.

Permissionless fault proofs recently went live on OP Sepolia (testnet): op.labs.blog

Optimism’s Risk Pie

Metis

Métis has upgraded their mainnet recently and introduced a decentralized sequencer. This is fantastic news!

Decentralized Sequencer - Metis:

“As of right now, there are two (2) sequencers, both run by the Metis Foundation, operated by Artemis Finance, and Enki Protocol. Throughout the next few weeks and months, there will be more nodes, as well as LST providers, integrating the decentralized sequencer model employed by Metis. This is just the beginning of a very exciting future.”

Benefits of Fault Proofs

Trustlessness: One of the fundamental principles of blockchain technology is trustlessness, where participants can interact without relying on centralized authorities or intermediaries. Fault proofs enable participants to verify the correctness of off-chain transactions on the main chain without trusting any single entity.

Security: Fault proofs act as a safety mechanism to detect and prevent fraudulent or invalid transactions from being committed to the main chain. By allowing anyone to challenge and submit evidence of fraudulent behavior, the system can quickly identify and penalize dishonest actors, disincentivizing them from attempting to misbehave in the first place. The validity of the chain is only reliant on 1 honest node, as they can advance the chain correctly either by posting valid assertions or disputing invalid ones.

Decentralization: Fault proofs promote decentralization by empowering anyone in the network to participate in the validation process.

Economic Incentives: Participants in optimistic rollups solutions may be economically motivated to behave dishonestly, especially if the cost of attempting corruption is lower than the potential gains. Fault proofs act as a deterrent by imposing penalties on malicious actors, making it economically unattractive to attempt fraudulent activities.

Fault proofs keep the security and integrity of optimistic rollups in check. They allow participants to address potential vulnerabilities and ensure that the system remains trustless and resistant to malicious actors. This is why we need them live on every optimistic rollup.

ZK x Optimistic Fault Proving

Optimistic rollups struggle with keeping fault proofs small and simple to verify, while zk rollups struggle with generating proofs in a quick and cheap way.

However, combining the two could work. Zk-proofs are succinct, which ensures the fault proofs stay small and easy to verify. On the other hand, optimistic rollups only have to provide a proof when fault is detected, which is cheaper compared to zk-proofs who provide proofs for each batch, fault or not. By merging zk-proofs with fault proofs we can have the best of both technologies: that is, succinct proofs instead of beefy ones, and proofs that are only generated when necessary, instead of all the time.

All in all

Fault proofs are the most critical component of optimistic rollups for all the reasons we went over, and so we need them on every single optimistic rollup, yesterday.

Decentralized Sequencers

First off, what’s a Sequencer?

In a rollup, a sequencer is responsible for aggregating or "sequencing" multiple transactions that occur on the rollup. The sequencer collects transactions, processes them, and creates a batch. This batch is then posted to the Ethereum L1.

Currently, most rollups operate centralized versions of sequencers, which just means there is a single entity or server responsible for ordering and processing the transactions. Centralized sequencers have several benefits, but also downsides:

Benefits

Tx Processing: Really fast transaction processing compared to decentralized systems.
Simplicity: Much more simple to implement and maintain than decentralized systems.

Downsides

Centralized: Single point of failure, not good. Much more vulnerable to security attacks like hacks or internal issues.
Censorship Risks: Centralized entitles can censor transactions.
Transparency: Centralized sequencers are less transparent than decentralized ones. MEV capture is trusted for example.
Regulatory: Centralized sequencers could be targeted by authorities, and are easier to shut down than decentralized sequencers.

To mitigate these risks, rollup communities are looking to decentralize their sequencers.

Decentralized sequencers work the same as centralized sequencers (batch, process txs, post to L1) but differ in how they are controlled. Centralized sequencers are controlled by one entity (one node), whereas decentralized sequencers have multiple nodes participating.

Ways to Decentralize Sequencers

One way to decentralize a sequencer is by rotating the leader (aka rotating the sequencer). Instead of having one centralized actor order all of the transactions themselves, “leaders'' are selected from a decentralized group of participants to sequence transactions, and rotate accordingly with each other.
Another way you could decentralize the sequencer would be using a consensus algorithm. For example, there could be a Tendermint chain running that commits to the Ethereum chain.

Shared Sequencing

Shared sequencing refers to rollups submitting transactions directly to a “shared sequencing layer” (think of it as a separate blockchain that can serve multiple rollups). Unlike decentralized sequencers who only serve one rollup, shared sequencers allow transactions from multiple rollups to be aggregated into a “shared” mempool before being sequenced. By using the same layer to sequence transactions, interoperability between the different rollups is unlocked, which is a key benefit to shared sequencers.

Benefits to Decentralized & Shared Sequencers:

Shared sequencers can provide interoperability between L2s, something that is desperately needed in the fragmented L2 landscape. Shared sequencers unlock the ability to do simple things like cross chain transfers, or more complex things like cross chain arbitrage.
There is disagreement here: James Prestwich articulated it well, noting that shared sequencers can only offer some level of atomicity:

Decentralized sequencers will improve liveness and censorship resistance.
They both improve developer UX and time to market. Instead of each rollup spending time and resources building a sequencer, they could have a sequencer on day one by plugging into an existing decentralized sequencer or a shared sequencer network.

source

Who’s Building Sequencers?

Decentralized:

Shared:

Debate: Fault Proofs vs Decentralized Sequencers

There’s been lots of discussion around what rollups should implement first: fault proofs or decentralized sequencers?

I say implement fault proofs first. In the short term, decentralized sequencers could be considered a “nice to have” (although a necessity in the long term). Fault proofs are a necessity no matter what timeline you're talking about, short or long term.

Roadmap to Decentralized Sequencers

Decentralized sequencers are pretty far away from being implemented.

Read more on decentralized sequencers here & here.

To keep up with sequencers (and preconfs) check out the Ethereum Sequencing and Preconfirmations Call.

Rollup Training Wheels: Related Research

Quantum-Safe and Trusted-Setup-Free Commitments

In an earlier section of the report, I highlighted the quantum-related vulnerabilities of Ethereum, particularly its reliance on the BLS signature scheme. Similarly, KZG commitments represent another piece of cryptography at risk to quantum computing. The goal is to eventually replace KZG commitments with commitments that don't require a trusted setup and are quantum safe.

Important to Note: Despite the risks, KZG commitments are still used in Ethereum because of 1.) how powerful and efficient they are and 2.) the lack of alternatives.

Quantum computing is a big danger to certain types of cryptography like RSA, ECC, BLS, etc, and although the risks posed are not that serious as of today, they will be at some point - which is the scary part of quantum computing - that is, the unknown timeline of when it will actually become a reality. Because of the unknown timeline, Ethereum should focus on becoming quantum-safe sooner rather than later and start replacing (or at least coming up with alternatives to) certain types of quantum vulnerable cryptography with quantum resistant cryptography. Removing vulnerable commitments like KZG is a good start, although there is much more to do. Remember, if we are not secure, we are nothing.

zk-EVMs

ZK technology can be used for several things on Ethereum like verifying the chain (zk-proofs) or scaling the chain (zk-rollups). Ethereum has goals to make better use of zk technology in the future, with one of the avenues being zkEVMs.

A zkEVM is a combination of the EVM (Ethereum Virtual Machine) and ZKPs (Zero Knowledge Proofs) that can execute smart contracts and generate validity proofs for verification. Often deemed as the holy grail of scaling solutions, the zkEVM can (& will) provide massive improvements to Ethereum's scalability (and hopefully privacy) without sacrificing the security and decentralization aspects of the chain.

Types of zk-EVMs

Let's talk about the types of zkEVMs, thanks to Justin Drake's research here:

Vitalik also put together a piece that covers five different types of zkEVMs; type-1, type-2, type-2.5, type-3, and type-4.

Projects Building a zkEVM

Type 1: Consensus Level Equivalence

Taiko: Type-1 Ethereum equivalent ZK-rollup. (Taiko)
PSE (formerly AppliedZKP): Type-1 zkEVM. (PSE)

Type 2: Bytecode Level Equivalence

Type 3: Bytecode Level Equivalence - Nearly Equivalent to EVM

Polygon: Polygons ZKevm has been live since March 2023. Polygon is focused on becoming a type 2 zkEVM, which would grant it evm-equivalent (aka bytecode-level equivalent). (Polygon)
Scroll: zkEVM similar to Polygon - focused on becoming EVM-equivalent. (Scroll)
Linea: Is a zkEVM similar to Scroll & Polygon, as it is focused on becoming EVM-equivalent. Linea is being developed by Consensys and went live on Mainnet in August 2023. (Linea)
Kakarot: Type 3 zk-EVM written in Cairo, leveraging the STARK proof system. Kakarot has implemented 8 out of 9 precompiles - and once it reaches all 9, it will be considered type 2.5. (Kakarot)

Type 4: Development Language Level Equivalence

zkSync: Type-4 zkEVM, focused on proving speed more so than EVM-equivalency. (zkSync)
StarkWare: Starkware is focused on proving speed more so than EVM-equivalency, similar to zkSync. Type 4. (Starkware)
Polygon Zero: ZK VM + Solidity Transpiler (Similar to zkSync). (Zero)

Here’s a nice diagram highlighting different zkEVMs:

h/t Alex Connolly

Benefits of zkEVMs

Scalability: Scalability is definitely the most sexy and talked about aspect of zero knowledge tech and zkEVMs. Ethereum is just too expensive for the everyday Joe, and so any type of scaling infrastructure that can reduce fees gets a lot of attention. Zk-proofs have the ability to reduce the computational and storage requirements of verifying transactions and can prove the correctness of computations without revealing all of the intermediate steps. Utilizing zk-proofs results in less data posted to the underlying chain and therefore cheaper costs. Because the scalability improvements from zkEVMs are so massive, people tend to look at them almost exclusively as a scalability solution and not for their other benefits - like better privacy and security.

Privacy: Zk-proofs are an excellent enhancement to privacy in blockchain systems. Users can use zk-proofs to prove the validity of a statement without revealing any data or sensitive information. This has huge implications for what’s possible, such as private transactions, confidential smart contracts execution, shielding data from the public (like sensitive business logic or transaction details), and more. zkEVMs should help address the privacy concerns associated with blockchain systems and welcome more privacy-sensitive people/businesses to use these systems.

Security: Zk-proofs allow users to prove the integrity and correctness of computations without needing to trust a node or validator. This property does a couple things:
1. Reduces reliance on centralized authorities (validators, nodes).
2. Makes it harder for malicious actors to manipulate the system.

Zk-proofs also limit the attack surface potential on blockchains by reducing the exposure of sensitive information. Using zk-proofs results in less sensitive information being shared to the public, which makes attacks on that information less common and harder to do.

Future of zkEVMs

Up until pretty recently zkEVMs were only considered theoretically possible, although that's definitely changed recently with several different zkEVMs going live in 2023, and with more expected throughout the rest of the 2024 year. Here’s a list of four that went live in 2023:

zkSync Era (March 24th)
Polygon zkEVM (March 27th)
Linea (July 18th)
Scroll (October 8th)

I expect many more zkEVMs to go live throughout the next couple of years.

Also, it’s important to note that zkEVMs won’t only live on L2s, as Ethereum has goals of ultimately turning the EVM into a zkEVM. This is a super ambitious goal for Ethereum and wont happen for a while, but worth mentioning nonetheless. This is talked about more in the Verge section.

Another futuristic idea is parallel zkVMs. This was recently researched by Scroll: https://eprint.iacr.org/2024/387

Learn More about zkEVMs: What's a zkEVM

Improve Cross Rollup Standards & Rollup Interoperability

Cross Rollup Standards

Standards are lacking in the L2 space - mainly interoperability standards & security standards. A lot of these problems are solved differently by different teams, and it leads to fragmentation of standards. Now, don’t get me wrong, teams taking different approaches from each other to these problems is great and definitely encouraged, but some things are best practice and should be standardized. Standardization makes users and developers lives much easier.

Common standards and basic interop between rollups is a huge area for improvement long term, especially considering the fact that Ethereum wants to direct current & future users to L2s. Plugging these holes will transform the L2 space.

Rollup Interoperability

I think rollup interoperability is the most important thing to solve for rollups going forward, so let’s dive into it.

I broke down this response from Justin Drake:

Currently, rollups on Ethereum are isolated from each other which has led to fragmented liquidity and composability. Pre-confirmations, state, sequencing, you name it, are all siloed between the different rollups. In other words, rollups are synchronously composable, and connected via asynchronous bridges.

Asynchronous bridges aren’t great, and replacing them is the ultimate goal. To achieve asynchronous composability, two things need to be present:

Shared Sequencing: Rollups who share the same sequencer can have synchronous composability. This is because the transactions on rollup #1 get sequenced at the same time as the transactions on rollup #2.
Real-Time Proving: Real time proving enables transaction execution to be proved with a SNARK. This means that deposits and withdrawals could be processed immediately, potentially multiple times/slot.

Ethereum L1 proposers could be given the rights to sequence rollups. A native Ethereum sequencer would have a few advantages over other shared sequencers:

Better Credible Neutrality: Rollups can opt in to the native Ethereum sequencer and not worry about ulterior motives of the Ethereum team. This might not be the case if Optimism had to opt in to an Abritrum built sequencer - or the other way around.
Better Security: Shared sequencers need to be able to handle all of Ethereum rollups and their economic activities at the same time. This means they need very high crypto-economic security (as attacks like the 51% attack are unacceptable), and no better place to get crypto economic security than the Ethereum L1.
L1-Compatibility: Rollups will have compatibility with the vast majority of contracts and assets that still sit on the L1.

A native Ethereum Sequencer scores a 10/10 for all 3 of these points, though it falls short on a fourth one: pre-confirmations.

Ethereum block times are way too long (12 seconds). There is no way to get pre-confirmations on transaction execution.

The solution: Based Pre-Confirmations

Based pre-confirmations means pre-confirmations offered by the L1. The best way to offer based pre-confirmations is via execution tickets, though the downside to this method is that it requires a hard fork. Another way to build based pre-confirmations is with inclusion lists (based-preconfirms) though it’s not a very elegant design relative to execution tickets.

Benefits of Improving Standards & Interoperability

Much less fragmentation. Lots of things can be fragmented across rollups, such as: liquidity, attention, talent, etc. Removing all of the friction that comes with fragmentation would be great for rollups.
Better standards means better security.

Research/Projects Related to Rollup Standards

RIP-7212: Allows for innovations like transaction signing via biometric authentication on mobile devices. Polygon has committed to implementing this standard in its upcoming Napoli upgrade, and ZkSync plans to in April. Other teams have also committed like Kakarot, Optimism, and Arbitrum.

Research/Projects Related to Interoperability Solutions:

Shared sequencing (Espresso, Astria, Radius, Ethereum L1 (based rollups)
Polygon AggLayer & CDK
Polymer Labs
Hop Protocol
Hyperlane
Lambda Storage Proof Bridge
Nebra
Based-preconfirms
Execution tickets
Omni Network
Axelar

The Scourge:

Goal: Mitigate centralization concerns in the Ethereum PoS design, particularly around MEV and liquid staking/pooling.

Status: Considering only MEV-Boost has been implemented, I’d say the Scourge section is about 10% complete. Parts of this section have had recent changes to it, which set back the timeline.

What’s Been Implemented?

Extra-protocol MEV markets (aka MEV-Boost). MEV-Boost went live in 2022.

What’s Left To Implement?

MEV-Track (Endgame Block Production Pipeline):

In-protocol PBS (ePBS)
Inclusion Lists
MEV Burn
Execution Tickets
Distributed Block Building

MEV-Track Miscellaneous:

Application Layer MEV Minimization
Transaction Pre-confirmations

Staking Economics/Experience Track:

Raise Max Effective Balance
Improve Node Operator Usability
Explore Total Stake Capping
Explore Solutions to Liquid Staking Centralization

MEV-Track (Endgame Block Production Pipeline)

Extra Protocol Markets (MEV-Boost)

MEV-Boost is an open source, free to use, out-of-protocol middleware service that was built by Flashbots for the Ethereum network.

Motivation

Prior to the Merge in September 2022, Ethereum’s block builder market was centralizing dangerously quickly. Miners were outsourcing block building duties to Flashbots on the order of 90+%. Proposer-builder separation was talked about as a solution to the builder centralization problem, but it was nowhere near ready for implementation at the time of the Merge (it still isn’t ready). So, MEV-boost was built to serve as an intermediate solution to the builder centralization problem, and has served as one since.

MEV-boost is an out-of-protocol service, while PBS will be built into-the-protocol (this is why MEV-boost was able to go to market much quicker). MEV-boost is compatible with all Ethereum clients, whether they are consensus or execution clients.

Here’s a diagram of how MEV-Boost works:

MEV-Boost separates the builder and the validator (aka proposer) roles. The builder's job is to produce blocks and send them to the relays. Relays aggregate multiple blocks from builders and take the most profitable one. The selected proposer then takes the most profitable block received from MEV-boost and propagates it to the network for attestation & inclusion.

Relays connect block builders and validators, serving as a trusted middleman between the two parties. They are used because the block builders can’t trust the proposers to not steal the MEV in the block, and the block proposers can’t trust the builders to release the block and pay them. This separation of roles has allowed the builder market to become more competitive than it previously was, resulting in greater decentralization and censorship resistance for Ethereum. Before MEV-Boost, miners were outsourcing block building to Flashbots on the order of 90%, which was not healthy for the network.

Overall, MEV-boost has been positive for the Ethereum ecosystem and a good interim solution while we wait for PBS.

Learning Resources: MEV-Boost Overview, MEV-Boost Community Calls

In-protocol PBS (ePBS)

Proposer builder separation refers to separating the builder role from the proposer role (aka the validator). ePBS means to enshrine PBS into the protocol.

Motivation

Prior to MEV-boost (aka proto-PBS), miners were outsourcing block building to Flashbots on the order of 90%, which was not healthy for the network. MEV was centralizing dangerously quickly and PBS was nowhere near implementation ready, so Flashbots built MEV-boost as an interim solution. Ethereum has increasingly shown interest in replacing the out-of-protocol MEV-boost (citing how out-of-protocol solutions can become brittle, among other things) with something enshrined in-protocol, and came up with ePBS.

H/T to Jon Charbonneau for the meme

How PBS Works:

PBS involves separating the tasks performed by validators today, block proposing and block building, into two separate entities.

As it works today, the validator performs both these tasks as they create (aka build) as well as broadcast (aka propose) blocks. In a PBS-world, these tasks are divided up - the block builder creates the block and bids it to the proposer in the current slot*. The proposer then looks through the blocks and chooses the most profitable bid with a valid header. Once chosen, they send the block to other proposers.

It is the job of the builder to generate commitments and proofs for the large blobs of data (32MB to be exact). Generating commitments and proofs for blobs is compute-heavy work that requires beefy hardware and so giving this job to block builders instead of validators is in Ethereum’s best interest.

What’s a Slot*?
Proof of Stake Ethereum contains slots and epochs. Each slot is 12 seconds and represents a fixed time period within an epoch, with each epoch containing 32 slots (an epoch is approximately 6.4 minutes). Every epoch, the entire validator set is randomized into 32 committees, with 1 committee assigned to each slot, where they propose and vote on blocks. Validators can attest to more than one block per epoch and determine which block becomes canonical. Ethereum’s finality mechanism (Casper FFG) requires at least two epochs and the consensus of a supermajority (⅔) of validators for blocks to be considered finalized. Finalized blocks are a great security feature, ensuring that blocks are immutable and can’t be reverted (under normal network conditions).
Read Chris Meisl’s piece for a deep dive

Back to PBS

PBS was first proposed as an approach to mitigate against the centralizing effects of MEV, though overtime it evolved into much more than a censorship resistance tool.

As researchers evaluated the Danksharding upgrade, they realized that validator requirements would greatly increase once danksharding was implemented. This was an unacceptable trade-off, and so research into mitigations commenced, with the researchers eventually realizing the answer was already there: PBS. Separate the roles of building and proposing, give the heavy compute work to the builders, and you can keep validator requirements low.

So, not only is PBS a great tool to combat censorship, but it also keeps validator requirements low and improves scalability.

Relays

Relays connect block builders & validators, serving as a trusted middleman between the two parties. Relays are used because block builders can’t trust the proposers to not steal the MEV in the block, and block proposers can’t trust the builders to release the block and pay them.

Here is an overview of the relay market as of September 7th, 2023:

source

Relays are one of the gears keeping the MEV-Boost engine running. The hope is that they will be shelved once PBS is enshrined, though further research is showing that its unlikely relays will be completely phased out.

Recent Research on Relays

Mike Neuder and several other researchers touched on why they think relays are here to stay.

(TLDR):

“Continued ePBS research and the evolving mev-boost landscape have made it clear that the incentive to use relays will likely remain even if we enshrine a PBS mechanism. This document describes the exact services that relays offer today and how they could change under ePBS.
Post enshrinement, the protocol would serve as a default “neutral relay” while the out-of-protocol relay market continues to develop, offering potential latency optimizations and other ancillary services (e.g., bid cancellations and more flexible payments). This greatly reduces the current dependency on public goods relays.
Although removing relays has often been cited as the raison d’être for enshrinement, we believe ePBS is still highly beneficial even if relays persist in some (reduced) form. The primary tradeoff is the added protocol complexity.
Overall, we assess that the benefits of ePBS outweigh the downside (mostly protocol complexity) even if there exists some incentive to bypass it at times. The remaining uncertainty isn’t so much if we should enshrine something, but rather what we should enshrine (which is a different discussion that I defer to Barnabé) – c’est la vie.”

Until we have ePBS, a trustless relationship between block builders and block proposers can’t be formed.

Optimistic Relay/Relay Research/Proposals:

Benefits of PBS

Keeps Validator Requirements Low: PBS is needed for danksharding to keep the validator requirements low. Danksharding without PBS is unfeasible on Ethereum because it would mean individual validators would have to process 32 MB of data in one slot, which are essentially megablocks. Requiring this would almost guarantee a drop off in the number of validators and therefore impact the decentralization of the chain.

Improves Censorship Properties: A positive side effect of having a decentralized validator set is that the censorship resistance properties also improve. On top of that, inclusion lists can be used. They make it much harder for block builders to censor transactions by allowing proposers to force include transactions and reject the blocks that don’t include those transactions making sure no censorship has taken place before the block is proposed.

Phase Out of Relays: Relays serve a role for Ethereum today but also come with problems: They can (potentially) censor transactions, are expensive to operate as a public good, are a centralizing force, and need to be trusted by both builders and proposers. It’s possible that Enshrining PBS would completely remove relays, though it’s more likely that the relay role just gets minimized substantially - which is still a valuable endeavor. The current state of the relay market is not great. As of now, only 4 major relays handle 98% of Ethereum blocks, which is down from 5 with Blocknatives recent recent departure from the relay market.

Reduced MEV (& Better Short-Term Privacy): PBS should reduce the risk of frontrunning substantially and improve privacy around transactions in the short-term. This is because pre-PBS proposers are looking at the highest paying priority fee txs in the mempool - meaning they can see the transactions and behave dishonestly. Post-PBS proposers cannot see the contents of the block and are only accepting the highest bid block from the block builders.

Improves Scalability: By proxy, PBS improves scalability because it is needed for the danksharding upgrade to go live.

Auction improvements: PBS introduces improvements in auction mechanisms by differentiating between block and slot auctions, thereby offering builders greater flexibility in their bidding strategies. Slot auctions allow builders to adapt to the latest mempool state, potentially unlocking more value by enabling bids on a broader set of future blockchain states without committing to specific block contents upfront. This flexibility facilitates more competitive and informed bidding, improving the overall efficiency of the auction process. Furthermore, the concept of hybrid auctions under PBS offers a nuanced approach, allowing builders to partially commit to block contents, marrying the predictability of block auctions with the adaptability of slot auctions.

Improved Regulatory Position for Validators: “The less discretion validators have over the blocks that they build, the less they have to be regulated as any kind of financial intermediary”- Hasu, Uncommon Core.

On one side of the extreme, a validator could be classified as a money transmitter (KYC everyone), and on the other end of the extreme a validator could be classified as an ISP (just transmits data, no KYC). The classification given to validators could largely depend on how much discretion they have over the blocks they are building, and is why PBS is so important: it keeps validators simple and affordable, giving them less discretion and therefore keeping them safer from a regulatory standpoint.

PBS Research/Proposals

Committee Driven MEV-Smoothing (Aug 23, 2021): https://ethresear.ch/t/committee-driven-mev-smoothing/10408
Two Slot Proposer Builder Separation (Oct 10, 2021): https://ethresear.ch/t/two-slot-proposer-builder-separation/10980
Single Slot PBS Using Attesters as Distributed Availability Oracles (Jan 27, 2022): https://ethresear.ch/t/single-slot-pbs-using-attesters-as-distribu
Unbundling PBS: Towards Protocol-Enforced Proposer Commitments (PEPC) (Oct 8, 2022): https://ethresear.ch/t/unbundling-pbs-towards-pepc/13879
Burning MEV Through Block Proposer Auctions (Oct 26, 2022): https://ethresear.ch/t/burning-mev-through-block-proposer-auctions
Block vs Slot Auctions PBS (Dec 14, 2022): https://mirror.xyz/0x03c29504CEcCa30B93FF5774183a1358D41f
Why Enshrine Proposer Builder Separation? A Viable Path to ePBS (May 25, 2023): https://ethresear.ch/t/why-enshrine-proposer-builder-separation
Payload-Timeliness Committee (PTC) - an ePBS Design (July 6th, 2023): https://ethresear.ch/t/payload-timeliness-committee-ptc-epbs-design
Alternate PBS: A PBS Proposal for Based Rollups (Nov 20, 2023): https://collective.flashbots.net/t/alternate-pbs
Execution Tickets (Dec 23, 2023): https://ethresear.ch/t/execution-tickets/17944
Minimal ePBS - Beacon Chain Changes (Feb 12, 2024): https://ethresear.ch/t/minimal-epbs-beacon-chain-changes/18653?u=barnabe
Paths to Hardening PBS (Feb 13, 2024): https://ethresear.ch/t/paths-to-hardening-pbs/18666
ePBS Design Constraints (Feb 19, 2024): https://ethresear.ch/t/epbs-design-constraints/18728?u=barnabe
Concurrent Block Proposers in Ethereum (Feb 23, 2024): https://ethresear.ch/t/concurrent-block-proposers-in-ethereum/18777

Roadmap to PBS:

ePBS is at least a year away from implementation.

Some important questions still need to be answered surrounding the design, with research ongoing. Once there is a complete design, a finalized specification can be made, which would then be tested rigorously, and if testing is successful, it can finally be implemented.

Learn more about PBS:

•Quintis PBS resources (The Wikipedia of PBS, has everything)

•Jon Charboneau - Censorship Wat Do

•Why Enshrine Proposer-Builder Separation? A Viable Path to ePBS

•Ethereum's Supply Chain Pt. 1 - Umbra Research

•Ethereum's Supply Chain Pt. 2 - Umbra Research

Inclusion Lists (CrLists)

Inclusion lists can be used by proposers to force include transactions and allow them to fight censorship. They essentially make a list of transactions they expect to see in the block, and if the block builder does not add them, they can reject the block.

Motivation

Post-merge, validators have relied heavily on specialized block builders to build blocks. Block builders have discretion on what transactions to include and exclude - in other words, validators can be censored by the builders. Inclusion lists address this problem by offering ways for validators to force inclusion of specific transactions.

Benefits of Inclusion Lists

Prevents block builders from censoring blocks

Inclusion Lists Research/Proposals

Vitalik has the OG post on this topic: State of Research: Increasing CR Under PBS (March 2022).

How Much Can We Constrain Builders Without Bringing Back Heavy Burdens to Proposers (Oct 1, 2022) from Vitalik gives a high level design of inclusion lists.

Forward Inclusion Lists (Nov 2022), proposed by Francesco (@fradamt). Important to note that many of the different proposed implementations of inclusion lists run into problems, with the main one being the free data availability problem. Francesco manages to avoid the free data availability problem in his work, but runs into other issues surrounding subjective enforcement.

No Free Lunch – a New Inclusion List Design - Ethereum Research (Aug 15, 2023), proposed by Vitalik and Mike Neuder, this design can remove the free data availability problem & avoid subjective enforcement of the inclusion list. TLDR: “The free data availability problem is the core limitation of many inclusion list instantiations. We outline the mechanics of a new design under which the inclusion list is split into a Summary, which the proposer signs over, and a list of Txns, which remain unsigned. By walking through the lifecycle of this new inclusion list, we show that the free data availability problem is solved, while the commitments of the inclusion list are enforceable by the state-transition function.”

Cumulative, Non-Expiring Inclusion Lists (Aug 31, 2023), from Toni Wahrstätter discusses the limitations of the current inclusion list designs and proposes cumulative non-expiring inclusion lists to align with the economic incentives of major staking providers much better.

Fun and Games With Inclusion Lists - Economics (Sept 6, 2023), from Barnabe Monnot talks about forward ILs are better at increasing censorship resistance than spot inclusion lists. He discusses block stuffing, commitment attacks, extortion attacks, and more.

Spec'ing out Forward Inclusion-List w/ Dedicated Gas Limits (Oct 17, 2023), from Terence & Potuz highlights the first spec ideas for ILs.

EIP-7547 (Oct 24, 2023), proposed by Mike Neuder. Also related: EIP-7547 End to End Workflow (Feb 27, 2024)

Bulletin Chains (Shared Inclusion Lists) (Dec 2023), by Dan Marzec.

Francesco dives deep into crLists: PBS Censorship-Resistance Alternatives - HackMD (2024).

Unconditional Inclusion Lists (Jan 30, 2024), from Mike Neuder & Toni Wahrstatter. TLDR: “Inclusion lists return agency to the proposer in a PBS world by allowing them to express preferences over the transactions included onchain, despite outsourcing their block production to the specialized builder market. This document discretizes the inclusion list design, advocates for a specific feature set, and aims to justify these decisions based on an analysis of the tradeoffs.”

Inclusion Lists: Execution, Consensus, & Engine Spec Overview (Feb 7, 2024), also from Mike Neuder, highlights a minimal view on what a potential spec for EIP-7547 could look like.

The More, The Less Censored: Introducing Committee-Enforced Inclusion Sets (COMIS) on Ethereum (Feb 29, 2024), from Soispoke, Francesco, and Barnabe.

Inclusion Lists PoC Specification (March 12, 2024), from Mike Neuder.

The Case For ILECTRA (March 15, 2024), from Mike Neuder, argues for the candidacy of EIP-7547 (inclusion lists) in the Electra/Prague hard fork!

Roadmap to Inclusion Lists

Research into inclusion lists is still ongoing, and because of that it’s hard to say exactly when we see an implementation.

Check out the inclusion list breakout room to stay up to date on inclusion lists.

MEV-Burn

MEV-burn refers to the idea of burning the MEV extracted from priority fee spikes.

Motivation

Ethereum will occasionally experience big fee spikes when the transaction demand surges. Specifically, the priority fees on Ethereum spike hard & fast, and result in some validators essentially “winning the lottery” by receiving a huge ETH payment if they are selected as the block proposer. An example of this would be the KPR NFT mint, which netted one validator 163ETH! That's a cool $611,250 at today's prices!

Source: blocknative

The goal of MEV-burn is to redistribute the MEV generated from priority fee spikes from one validator to all of the validators (by burning it). Burning priority fees will not only smooth out the yield, but will also greatly reduce the incentives to short term reorg the chain and try to steal the MEV.

Mental Models

“MEV-burn is letting the blockchain capture value that would otherwise be extracted from the on-chain economy” - (I believe this was David from bankless).

“MEV burn would enshrine ETH as the only possible currency used in the MEV market, in the same way EIP-1559 enshrined ETH as the only currency used to pay gas fees.” Domothy

“EIP-1559 & MEV-Burn are two sides of the same coin.” Justin Drake et al

“Competition for inclusion leads to congestion, and competition for ordering leads to contention.”

MEV-Burn Research/Proposals

Burning MEV Through Block Proposer Auctions: Proposed by Domothy (October 2022).
Committee Driven MEV Smoothing: Proposed by Francesco (August 2021)
MEV Burn - A Simple Design: Proposed by Justin Drake (May 2023)

Capping the validator set through economic incentives would indirectly burn MEV through negative issuance: research from Vitalik (2022)

In a post MEV-Burn world - Some simulations and stats (October 2023)

Dr. changestuff or: how i learned to stop worrying and love mev-burn (November 2023)

MEV burn: Incentivizing earlier bidding in "a simple design" (November 2023)

Rules and Strategies of a Protocol (September 2023)

How MEV-Burn Works

I'm specifically going to breakdown MEV Burn - A Simple Design.

Payload base fee: Bids specify a payload base fee no larger than the builder balance minus the payload tip.
Payload base fee burn: The payload base fee is burned, even if the payload is invalid or revealed late.
Payload base fee floor: During the bid selection attesters impose a subjective floor on the payload base fee.
- subjective floor: Honest attesters set their payload base fee floor to the top builder base fee observed D seconds (e.g. D = 2) prior to the time honest proposers propose.
- synchrony assumption: D is a protocol parameter greater than the bid gossip delay.
Payload base fee maximization: Honest proposers select winning bids that maximize the payload base fee.

Shoutout to Justin Drake et al for the breakdown here

Benefits of MEV-Burn

Smoothing the Staking Yield: The goal of Proof of Stake is to ensure that owning a certain percentage of the stake translates to receiving a proportionate amount of rewards. However, the current structure of MEV rewards doesn't align with this goal, particularly for individual stakers. Large staking pools, due to their frequent block proposals, have a higher chance of benefiting from occasional significant MEV surges, while solo stakers may only propose a few blocks annually, making it unlikely that they receive substantial MEV payouts. Moreover, staking pools can swiftly reinvest sizable MEV rewards into additional validators, further tilting the odds in their favor for future MEV gains. In contrast, when MEV is burned, the staking yield becomes more consistent and equitable. Proposing blocks more frequently results in more frequent MEV burns, ensuring a similar staking yield for everyone based on token issuance. This approach also simplifies the structure of decentralized staking pools, removing concerns about potential misappropriation of MEV rewards by node operators, as the MEV burn automatically evens out rewards for all participants.
Remove Impact of MEV Spikes in Short & Long Term, Results in Better Consensus Stability:

Short term: When MEV spikes, the next-in-line validator is incentivized to perform a short term reorg to steal the previous blocks MEV for themselves. Smoothing these spikes by burning the ETH makes short term reorgs much less likely, as well as p2p attacks.
Long term: “An extreme MEV spike can create systemic risk for Ethereum, possibly bubbling to the social layer. Consider a malicious proposer receiving millions of ETH from a rollup hack.” Burning the MEV instead of handing it off to the current proposer could prevent a malicious proposer from ever receiving it in the first place.

Achieve a More Robust Validator Set: MEV-burn can result in lower issuance of ETH and therefore less overpaying for security, as well as reducing the validator count, which makes it much easier for upgrades like SSF to be implemented.

Further Suppress Toxic MEV: Instead of stakers and staking pools receiving toxic MEV, it can be burned. This will do away any disputes that might occur in staking pool governance forums over how to handle the MEV, along other things like tax or legal liabilities. Burning toxic MEV is a great way to deal with it as it does not place it in the hands of a pool or validator and cause any unwanted liabilities for them.

Better Economics: MEV burn enshrines ETH as the unit of account in the MEV market. Burning more ETH will also serve as a nice schelling point (good memes) for ETH as an SoV as it increases scarcity, and when combined with the unit of account aspect, makes ETH look like a fantastic money. MEV-burn could also improve tax liabilities in certain places by reclassifying MEV rewards from income to capital gains.

Roadmap to MEV-Burn

Before MEV-Burn can be implemented two things are required: ePBS & inclusion lists. Because of these requirements, MEV-Burn is expected to be 4-5 years away.

Execution Tickets

Execution Tickets are a new concept in Ethereum land. They provide an in-protocol market for buying & selling “tickets”, as well as a lottery for both 1.) the beacon block proposer & attesters, and 2.) the execution block & attesters. Buying a ticket effectively buys you the right to propose blocks.

Motivation

Because of the traditional block proposer process and MEV, validators are incentivized to outsource payload construction to an external market of builders for more rewards. Execution tickets look to address issues related to MEV & centralization pressures by separating block proposal rights from validators.

Execution tickets were first presented by Justin Drake as Attester-Proposer Separation (APS), but have since been rebranded to execution tickets. Mike Neuder, with help from Justin, Francesco, and Barnabe put out the latest research on them, which specifically focused on Proof-of-Stake (PoS) consensus mechanisms, MEV (Miner Extractable Value), and economics surrounding block proposal rights.

I'm going to break-down their research below. You can read the full post here.

Execution Tickets: Key Points

1.) High-level Overview: The high-level overview describes the execution ticket mechanism as an in-protocol market for buying and selling tickets that grant block proposal rights for future slots. It introduces lotteries for both 1.) the beacon block proposer & attesters, and 2.) the execution block & attesters.

2. Design: The design goes as follows (describing 1 slot): The process involves a beacon proposer, chosen randomly, proposing a beacon block (that contains the inclusion lists) during the beacon round, followed by beacon attesters voting on its validity. Similarly, in the execution round, a randomly selected execution ticket holder proposes an execution block, with execution attesters voting on its validity and timeliness.

3. Analysis: The analysis section talks about the potential impacts of this design on various aspects of the Ethereum network, such as:

Simplification of Validator Tasks: Deciding the execution block is removed from the validator.
The Removal of MEV from Validator Rewards: This restores the original incentives of the consensus mechanism, lessens volatility in rewards, increases the risk of playing timing games, among other things.
Enables Safer Delegation (trusted or trustless): Staking pools cannot rugpool, aka steal MEV, as the Beacon proposer isn’t actually getting the rewards and so they can’t take it. (there could still be “ticket purchasing pools”, though they are outside the core validator set and can be handled out of protocol).

4. Roadmap Compatibility: The roadmap compatibility section discusses how this proposal aligns or diverges from Ethereum's envisioned endgame.

Mike talks about the potential implications on MEV-burn mechanisms, compatibility with pre-confirmations, and how execution tickets improve protocol simplicity.

5. Secondary Market: The primary market is defined as the tickets for sale by the Beacon chain. They are unused, and therefore fungible. Once the tickets are assigned to specific slots, they are considered on the secondary market.

6. Multi-Slot MEV Considerations: Multi-slot MEV refers to someone who controls more than one slot in a row, giving them the block proposal rights to however many blocks they control, all of which are full of MEV. Controlling consecutive slots has huge benefits relative to controlling one slot.

Mike talks about potential mitigations to multi-slot MEV, such as:

Randomness
Honest inclusion list usage
Block or inclusion list maximization
Encrypted mempools
Upfront charge of missed slot fee

Open Questions

What are the exact mechanics of the ticket pricing mechanism?
What are the fork-choice implications of execution ticketing?
How do execution tickets alter the designs of pre-confirmations?
How do we construct the “second” staking mechanism for execution ticket holders?
Are inclusion lists sufficient for preserving censorship resistance?
What is the market structure of the execution tickets?

Related Research

Roadmap to Execution Tickets

Execution tickets fully embrace the endgame roadmap for Ethereum (centralized block production, decentralized and trustless block validation, still avoids censorship).

Because the research is so new, it’s hard to say exactly when execution tickets will be implemented.

Distributed Block Building

A goal of Ethereum’s is to distribute the block building process, or in other words, decentralize it.

Motivation

Ethereum’s endgame consists of decentralized block validation & centralized block building, which is an active choice the network makes. Ethereum has always prioritized decentralized validation, though the problem is that prioritizing decentralized validation creates a tradeoff where block building becomes centralized.

(I think) Ethereum makes the right choice in rather having centralized block building than having centralized block validation - although that doesn't mean the block building situation should just get left as it is. Inclusion lists are a tool that can be used, as well as distributing the actual process of block building.

Both inclusion lists & block building distribution can help combat builder centralization, though the difference between them is that distributing block building can actually decentralize the winning builder itself. Inclusion lists just allow transactions to be force included.

Benefits of Distributing Builders

Improved Censorship Resistance: The main benefit of distributing builders is censorship resistance. It is harder to censor a distributed network of builders over one single builder.
Better Trust: Searchers can trust a distributed network of builders more than they can trust one single builder.

Ideas for Distributed Block Building

Here are two different ideas to decentralize block building, one from Vitalik & one from Flashbots:

Vitalik’s Idea: Decentralize different parts of the builder (Vitalik's Presentation: Decentralizing the Builder Role).

Vitalik talked about different part of the builder we could decentralize, such as:

The Algorithms for Choosing Transactions: The block builders are essentially algorithms who choose the order of transactions, so we could decentralize this algorithm.
Resources for Block Construction (Particularly in Danksharding): Meaning split up the resource requirements of creating and distributing a big block so it doesn't fall on one node.
Extra Builder Services (like Pre-Confirmations): Block builders could offer pre-confirmation services to users. Pre-confirmations refers to the builder offering a service that “pre-confirms” transactions before they are actually included onchain. This provides a much better UX. (rollups already offer this without users realizing).

Jon Charbonneau wrote a report built around Vitalik’s talk, going deep into the details if you want to dive deeper.

Flashbots Idea: SUAVE (Single Unifying Auction for Value Expression).

Flashbots successfully isolated the centralizing effects of MEV to block builders via MEV-boost, and now SUAVE is Flashbots attempt at decentralizing the block builder role.

“From a high level, SUAVE is an independent network that can act as a plug-and-play mempool and decentralized block builder for any blockchain.” - SUAVE - Flashbots

Suave combines a sequencing layer (the builder) and a mempool to surface transactions.

as a common sequencing layer, SUAVE brings a few benefits: it can enable block builders to benefit from cross-domain MEV, it can help validators increase their earnings, and also allow users to execute transactions more efficiently.

Quintus from Flashbots made a block building proposal for Suave, called M.O.S.S. The post delves into an idea of how a block could actually be built on SUAVE.

Transaction Pre-Confirmations

Pre-confirmations refers to the builder (or potentially proposer) offering a service that “pre-confirms” transactions before they are actually included onchain.

Builder pre-confirmations are only as good as their ability to actually build the winning block, & centralized builders generally have an easier time building winning blocks than a distrusted builder set. If distributed builders want to be successful, they have to offer on-par or better services than their centralized builder counterparts.

“You could actually get a stronger pre-confirmation with a distributed builder in something like the EigenLayer construct at times.” - Jon Charb

Outside of pre-confirmations, here are some other services builders could offer.

Shoutout to Alex Stokes for the slide

Research/Proposals

Roadmap to Distributed Builders

Flashbots wants to have a testnet for SUAVE that is ready to use by Q1 2024. Otherwise, Phil was pretty vague when talking about the SUAVE roadmap with Bankless. Unsure on the roadmap for Vitalik’s proposal.

Resources to Learn More:

Application Layer MEV Minimization

Application layer MEV minimization refers to the effort made by crypto applications to combat (what they deem as) toxic and harmful MEV.

Motivation

There are 2 main approaches to combating MEV currently, with smart people and teams on both sides of the debate.

Offence: MEV is here to stay and is critical for network security, so let’s extract it and then democratize it.
Defence: MEV is not good so let’s try to minimize it.

On the offence side of the debate, we have solutions like MEV auctions (MEVA) and frontrunning-as-a-service (FAAS). On the defence side of the debate we have several different minimization/prevention techniques like fair ordering or VDFs (verifiable delay functions).

I’m specifically going to focus only on the defensive side of the equation and what designs different applications look to implement to minimize MEV. I’m not going to talk about searching for MEV, or MEV that is L1 related. We are just focused on minimization of MEV at the application layer (also, I'm not going to go over whether MEV is good or bad and the whys of either side, it would make an article that's too long much much longer).

Most of the minimization techniques target frontrunning and sandwich attacks, and not arbitrage. This is because arbitrage is generally viewed as helpful for both parties (searchers make money and users get better prices). The other two are viewed as harmful to the user.

source

Examples of the Defensive Side of MEV

FSS by Chainlink (Chainlink)
Cowswap (CoWSwap)
Shutter Network (Shutter)
Veedo - StarkWare (Veedo)
Osmosis (Osmosis)
Juno (Juno)
Fairblock (Fairblock)

Chainlink

Chainlink offers something called the Fair Sequencing Service (FSS)

The goal of Chainlink’s FSS is to reduce harmful MEV by making transaction ordering more fair. Some people think fair ordering is fatally flawed, while others like Chainlink think it’s a valid approach.

To summarize, FSS orders transactions based on what order they came in according to their consensus derived receive order. If a majority of nodes receive Tx1 before they receive Tx2, Tx1 should be ‘ordered’ before Tx2.

The structure of Chainlink’s FSS aims to have an oracle network do the ordering of transactions (user transactions & oracle reports) that are sent to a particular smart contract. Transactions are threshold encrypted before the ordering process, which means that sequencers cannot see the contents of the transactions until the block is executed and included on-chain. After execution & inclusion, transactions are decrypted.

Read More: FSS

Protected Order-Flow (PROF): PROF is Chainlinks more recent public research on Protected Order-Flow (PROF), which prevents the arbitrary reordering of transactions while relying on existing MEV infrastructure. PROF Presentation

CoWSwap

CoWSwap is a novel DEX with a focus on protecting users from MEV. CoWSwap can eliminate sandwich, frontrunning & back running attacks by utilizing some unique design principles:

Batch Auctions: In CoWSwap’s batch auction, orders are placed off chain and collected periodically into batches to then be settled on chain. Batch auctions provide all the transactions in a batch with a uniform clearing price, which means there’s no benefit to the miner for reordering transactions.

Read More: Batch Auctions - Docs

Coincidence of Wants (CoW): Because CoWSwap uses batch auctions, it is well positioned to find a CoW (coincidence of wants) within a batch of trades. Coincidence of Wants means two parties hold an item that the other party wants - for example, I have 1 ETH and you have 1 ETH worth of USDC. I want to sell my 1 ETH for USDC, and you want to buy 1 ETH via USDC. Because we want the exact same thing, we can swap directly instead of using a market maker or LP. When a perfect coincidence of wants cannot be found, ring trades are used, another feature that batch auctions enable. Ring trades tap into liquidity across all orders instead of a single pairing (in other words, you can split trades into particular pieces and mix and match them to optimize for the best pricing).

Read more: Coincidence of Wants - Docs

Shutter Network

Shutters main focus is frontrunning and how to mitigate it. Their approach is also to use threshold cryptography, with their website homepage reading: “Prevent frontrunning on Ethereum by using a threshold cryptography based distributed key generation (DKG) protocol.”

The DKG protocol is used by actors known as “keypers”, who produce encryption and decryption keys to then be used by the protocol for encrypting and decrypting transactions.

Read More: Shutter Network

VeeDo (StarkWare)

StarkWare have publicly leaned to the defensive side of MEV via VeeDo, which is a STARK-based Verifiable Delay Function (VDF) service developed by StarkWare, and is live on mainnet. VeeDo combines VDFs with the STARK protocol to create a delay function that is slow to compute but fast to invert. A verifiable proof of the computations integrity is provided, without the need to replay the slow computation.

StarkWare will use VDFs (Verifiable Delay Functions) and time-locked encryption to encrypt information during the sequencing phase, which is then made public afterward. It’s the same approach as Chainlink: if MEV is unknown then it is harder to extract.

Potential Applications:

Generate trustless randomness for Ethereum.
Generate timelocks using VeeDo’s VDF.
NextGen PoW

Read More: VeeDo

Osmosis

Osmosis is another protocol that is using threshold encryption to combat MEV. Along with threshold decryption, Osmosis is looking at things like joint block proposals and batching.

A cool thing about Osmosis is that it uses Tendermint, and because finality is near instant with Tendermint, certain harmful attacks like reorgs are not possible.

Read More: Osmosis

Juno

Juno had proposals (not sure if live) that covered a few ideas:

Make sandwich and frontrunning attacks a slashable offense.
Encode in the protocol that a minimum of 10% and a maximum of 75% of MEV rewards accrue to validators.
Encode that all JUNO stakers will receive a minimum of 25% and a maximum of 90% of MEV rewards.

Read More: Juno Proposal

Skip Protocol

Skip is a “sovereign MEV solution for sovereign blockchains,” which can do things like eliminate bad forms of MEV such as sandwiching or spam, or recapture MEV as protocol revenue. Here are a few products Skip offers:

Block SDK
Skip API
ProtoRev
Skipper

Read More: Skip

To Sum Up

So these have been some of the defensive approaches to MEV, showcasing how different applications are trying to minimize MEV. There is a lot of overlap between the different teams and their strategies and so I expect more standardization to take place between the applications around strategies. The MEV space is constantly evolving and so new defensive strategies will continue to be released that were not covered here.

Staking Economics/Experiences Track

Raise Max Effective Balance

Currently on Ethereum, the MAX_EFFECTIVE_BALANCE caps the balance of Ethereum validators at 32ETH. This means that the maximum you can stake is 32ETH, even if you have more. I’ll give two examples here:

Example #1: Let's say you are Coinbase, and because of the 32 ETH cap, you have to run 10,000 different validators (320,000ETH worth) to support the cbETH staking product. Maintaining this many validators results in lots of unnecessary overhead for Coinbase, and is essentially pointless at the end of the day as the validators are controlled by 1 entity anyway (Coinbase). Raising the MAX_EFFECTIVE_BALANCE would (in theory, depending on what the cap was raised to) allow Coinbase to consolidate these 10,000 validators into 1, and massively simplify their operational processes.

Example #2: A whale has 800ETH, and is looking to stake all of it. To do so today, they would have to set up 25 different validators, instead of just 1. To stake the ETH post MaxEB, this whale would only have to set up 1 validator instead of 25 different ones.

The 32 ETH maximum has resulted in a very large validator set (925,000 as of Feb 2024), and means a very heavy load for the p2p and consensus layer to handle. Increasing the MAX_EFFECTIVE_BALANCE would alleviate this heavy load by consolidating validators. Instead of running 10,000 different validators, Coinbase (in theory) would be able to consolidate everything into 1 validator, 1 signature.

Increase MaxEB Benefits

Unlocks future upgrades like SSF & ePBS. Currently, there are too many validators on Ethereum for SSF to be possible. Consolidating validators and reducing the amount of signatures that need to be broadcasted p2p would make SSF possible. Implementing SSF would lead to stronger security properties, which leads to a stronger consensus layer, which means ePBS can be implemented sooner.
Improves performance of the current consensus mechanism and the p2p layer (there are much less messages to relay).
Makes operations much easier for larger stakers and staking operations (don’t have to set up N number of different validators).
Staking becomes more granular. Imagine you have 100 ETH and you want to stake it all. Currently, you would have to set up three different validators, each with 32 ETH. Then there would still be 4 ETH you have leftover. This is very annoying. However, post max balance increase, you could stake all 100 ETH, without the 4 ETH stuck in limbo. Compounding your ETH also becomes easier, as you won’t ever have 4 ETH in limbo like the example above, and the rewards accrue to only 1 validator.
Importantly, the “increase MAX_EFFECTIVE_BALANCE proposal” does not raise the 32 ETH minimum to become a staker.

Research/Proposals

EIP-7251 has been confirmed for inclusion in the Pectra, which is Ethereum’s next upgrade.

Improve Node Operator Usability

Improving node operator usability refers to making nodes cheaper via things like verkle trees and SNARKs, and improving the UX around running a node.

Cheaper Nodes

Making nodes cheaper to operate is key to getting more nodes online and improving their usability. Here’s a few things that make nodes cheaper to operate:

Verkle Trees: Verkle trees make Statelessness possible. Statelessness will drastically lower the SSD requirements for nodes, eliminating a key bottleneck to scaling Ethereum. Statelessness will also allow nodes to sync much much quicker.
SNARKs: SNARKs are also possible because of Verkle trees. SNARKs can be applied to different areas of Ethereum and make it easier to trustlessly verify blocks. Recall that the gas limit can be raised/decreased whenever, but only in small amounts - SNARKifying the EVM however would mean the gas limit could be raised substantially.

UX Improvements

Create a very simple solution to running a node. Ideally, this would be a program or an app that non-technical users can just plug and play. For example:

Coinbase Product: Coinbase (or anyone for that matter) could create a product allowing anyone to run a node: “Go to the run your own node section on the Coinbase app, select run Ethereum node (full, light, archival) and boom - your up and running.” This is obviously easier said than done, just spitballing here.

See other items like Verkle trees and SNARKs that make validator clients much more light weight,

Research/Proposals

Spin Up Your Own Ethereum Node - Ethereum.org

Explore Total Stake Capping

Ethereum should continue exploring ways to cap the total amount of stake. Too many stakers on the network can result in efficiency problems, as eventually the communication overhead between the validators will be too much for Ethereum to handle.

In Paths to SSF, Vitalik talked about two ways to cap ETH staking:

Capping the validator set
Capping the ETH staked

Suggestion #1: Capping the Validator Set: To address excessive validator participation, put a cap proportional to the number of validators itself.

A second approach would be to target a floating minimum balance: if the validator count exceeds the cap, kick the lowest balance validator out. However, this could result in the griefing attack, where wealthy validators split up their stake to push out small validators and increase their rewards (less validators = higher staking yield).

Suggestion #2: Capping the ETH Deposited: To address excessive validator participation, put a cap on staking rewards, with rewards decreasing as the active validator set increases. This will discourage new validators from staking and may encourage some existing ones to stop all together. You might be thinking, isn’t that already the case - the more ETH staked the lower the rewards? Yes, that’s correct. But the current reward curve will be modified even more to decrease faster as the total ETH deposited grows, eventually dropping below 0% at 25 million ETH. Around 33.5 million ETH is the reward curves limit, preventing the validator set from growing beyond that. However, despite rewards dropping to or below zero, validators may still be incentivized to participate in scenarios with high MEV.

Research/Proposals

Paths to SSF

Explore Solutions to Liquid Staking Centralization

Ethereum needs to explore solutions to combat centralization in the LST market. The current LST market structure looks as follows: Lido is the #1 LST provider at 31.25% market share, the #2 is Coinbase at 14.2%, and the #3 is Binance at 4.2%.

LSTs that control large amounts of ETH stake are very dangerous to Ethereum. These LSTs can impact Ethereum depending on the size of stake they control:

33% Market Share: LST can disrupt the finality of the chain.
50% Market Share: LST can start censoring blocks.
66% Market Share: The network is seriously compromised.

Ethereum needs to be proactive about LST centralization if it wants to avoid these risks before they present themselves. Lido is only a few % away from the 33% threshold, and because it’s already so close (31.25%), it could hit that overnight with some big deposits. It’s important that Ethereum is ahead of the ball in regards to LST centralization.

Potential Solutions

Social Pressures: Ethereum can put social pressure on the community to not stake with dominant LST providers, like Lido for example. This is a decent short term solution (see the consensus client situation where social pressures got put on people to diversify consensus client providers, and it worked), but a bad long term solution. Incentives run the world.
Two-Tiered Staking (Mike’s proposal): This framework splits staked ETH into two tiers: one that involves slashable node operator bonds (C1) and another for delegated stake (C2). The node operator bond is slashable, while the delegated stake is not.
Rainbow Staking: Rainbow staking looks to support a wide range of participants from individual stakers to large operators by categorizing services into “heavy” and “light”, with distinct roles for delegators and operators. The name rainbow signifies the goal of the rainbow framework: diversity in service providers and flexibility in the staking process.
Enshrined LST (Arixon’s research): Arixon suggests a system where users deposit ETH into a staking contract in exchange for a rebasing token, eETH. The deposited ETH then gets allocated to node operators based on commission rates (the protocol selects the node operator with the lowest commission), with rewards split between the staking contract and the node operators. Arixon’s framework outlines a fair stake allocation to node operators, handles the issue of non-compliant validators, and sets competitive fees to encourage operational efficiency.

Research/Proposals

Enshrining Liquid Staking/Decentralized Liquid Staking discussion from Vitalik.
Enshrined LST from Arixon.
Unbundling staking: towards rainbow staking from Barnabe.
Liquid Staking Maximalism design by Dankrad.
Two-tiered staking from Mike Neuder (builds off of Dankrad’s original idea).

The Verge: Statelessness Through Verkle Trees And Related Features

Goal: Verifying blocks should be super easy - download N bytes of data, perform a few basic computations, verify a SNARK and you're done.

Status: Verkle trees should be implemented some time in 2025. Other stuff from this section will take longer, like fully snarking Ethereum.

What’s Been Implemented?

Most serious EVM DoS issues solved – These issues were mainly gas pricing issues that got resolved in the Berlin upgrade.
Basic light client support (sync committees) - Sync committees make it easy to build light clients that follow the consensus layer. Example: Helios
Verkle Tree Specification Complete - Big progress is being made on Verkle stuff!

What’s Left To Implement?

Gas Cost Changes
Verkle Trees
Fully SNARKed Ethereum
Move to Quantum-Safe SNARKs (e.g. STARKs)

Gas Cost Changes

If Ethereum wants to implement Verkle trees, and therefore statelessness, gas costs need to be adjusted so that they are consistent with the witness size required for a specific operation. A few operations that need changes:

Account Reads
SLOAD & SSTORE
Contract Code Execution

Related EIPs

EIP-4762 (Stateless Gas Cost Changes): is a proposal that makes changes to the gas schedule to reflect the costs of creating a witness, particularly in the context of Verkle trees being integrated into Ethereum. The goal is to incentivize Dapp developers and client developers to update their database layout ahead of the Verkle tree fork to avoid potential DoS attacks and ensure smooth transition.

Diving Deeper: EIP-4762

Gas costs for reading storage and code are reformed to more closely reflect the gas costs under the new Verkle tree design. WITNESS_CHUNK_COST is set to charge 6.25 gas per byte for chunks, and WITNESS_BRANCH_COST is set to charge ~13,2 gas per byte for branches on average (assuming 144 byte branch length) and ~2.5 gas per byte in the worst case if an attacker fills the tree with keys deliberately computed to maximize proof length.

Witness Gas Costs

Remove the following gas costs:

Increased gas cost of CALL if it is nonzero-value-sending
EIP-2200 SSTORE gas costs except for the SLOAD_GAS
200 per byte contract code cost

Reduce gas cost:

CREATE to 1000

Replacement for Access Lists

Replace EIP-2930 access lists with an SSZ structure.

Gas Reform

Gas costs are reformed to more accurately reflect gas costs under the new Verkle tree design. The main differences from gas costs in Berlin are:

200 gas charged per 31 byte chunk of code. This has been estimated to increase average gas usage by ~6-12% suggesting 10-20% gas usage increases at a 350 gas per chunk level.

Cost for accessing adjacent storage slots key1 // 256 == key2 // 256 decreases from 2100 to 200 for all slots after the first in the group,

Cost for accessing storage slots 0…63 decreases from 2100 to 200, including the first storage slot. This is likely to significantly improve performance of many existing contracts, which use those storage slots for single persistent variables.

Future Gas Cost Changes

If Ethereum can fully SNARK itself (we’ll get into that later) the gas limit could be significantly increased, or even potentially removed, without burdening validator requirements.

Higher gas limit = bigger blocks = more transactions = more scale

Increase L1 Gas Limit - Important to Note

The “Increase L1 gas limit” section was removed from the roadmap to showcase that the limit can be raised whenever. There is no need to wait for SNARKs, especially for small increases.

Ethereum’s gas limit has been raised several times throughout its history, and it can happen again at any time. It has been 2+ years since the most previous gas limit increase, which is by far the longest period Ethereum has gone without an increase.

source

Vitalik actually just talked about raising the gas limit on a recent AMA (Jan 10), citing how he thinks it’s reasonable to increase the gas limit from 30M to 40M.

AMA:

“Honestly, I think doing a modest gas limit increase even today is reasonable. The gas limit has not been increased for nearly three years, which is the longest time ever in the protocol's history (that 2x bump in the chart in late 2021 is "fake", in that it reflects the EIP-1559 transition, which increased the "limit" by 2x but only increased actual average usage by ~9%). And so splitting the post-2021 gains from Moore's law 50/50 between increased capacity and increased ease of syncing/verification would imply an increase to around 40M or so.”

Relevant Research/Proposals

EIP-7623: Increase Calldata Cost: this proposal aims to reduce the maximum block size to make room for adding more blobs.
On Increasing the Block Gas Limit: This piece breaks down EIP-7623 in detail.
Pump The Gas: Pump the gas is a community led effort to raise the gas limit on Ethereum to 40m. As Dankrad notes, raising the gas limit could be coupled with other changes such as raising the blob count from 3->8, and implementing EIP-7623.

Verkle Trees

A Verkle tree is a type of data structure similar to a Merkle tree that can be used to store large amounts of data, and to make proofs based on that data. The name Verkle tree is a portmanteau of vector commitment and Merkle tree.

Motivation

Merkle trees are great and have served Ethereum well, but the proof sizes they generate are just too large and threaten to get in the way of future upgrades like stateless clients. The Verge upgrade will replace Merkle-Patricia trees with Verkle trees.

Verkle trees serve the same functions as Merkle trees (store data and generate proofs), although Verkle trees are much more efficient when it comes to proof generation. This is because Verkle trees are constructed using vector commitments whereas Merkle trees are constructed using cryptographic hash functions. To make the numbers more concrete, here’s a quote from Vitalik's post on verkle trees:

“If a tree contains a billion pieces of data, making a proof in a traditional binary Merkle tree would require about 1 kilobyte, but in a Verkle tree the proof would be less than 150 bytes.”

Replacing Merkle trees with Verkle trees will greatly reduce the amount of state data nodes need to store and finally make statelessness possible on Ethereum.

Benefits of Verkle Trees

Efficient Proof Generation Making Statelessness Possible: Verkle trees make it possible for Ethereum to implement statelessness, which is a huge deal. Statelessness means that nodes won’t need to store the entire state (addresses, contracts, etc), instead relying on “witness” who accompanies the block to do so. Statelessness will drastically lower the SSD requirements for nodes and eliminate a key bottleneck to scaling Ethereum. Statelessness will also allow nodes to sync to the chain much much quicker, and unlock other things like the gas limit being raised.
Snarkifying Ethereum: Verkle trees also make it possible for Ethereum to fully snark itself, and eventually move to a quantum safe solution like starks.

Related Research/EIPs to Verkle Trees

Transition Types

There are a few different ways we can transition Ethereum from using Merkle trees to using Verkle trees:

Overlay Method: here
Conversion Node: here
Local Bulk: here
State Expiry: here

This is a great write up that covers the different Verkle transitions listed above.

Roadmap to Implementation

Although there isn’t an official timeline, the implementation of Verkle trees is targeted for sometime in 2025.

Check out https://verkle.info/ to see what is done/what needs to be done.

It has a dashboard going over the current & upcoming tasks that need to be completed. It consists of things such as relaunching the Kaustinen testnet, and including the overlay tree migration in the spec. The list goes into much better detail and highlights 10+ things that need to be done. Aside from completing these tasks, tons and tons more testing needs to be done, and some open questions need to be answered.

The Verkle implementers call is another good resource to keep up with the progress of the upgrade.

Fully SNARKed Ethereum

Ethereum is looking to “SNARKify” itself, both at the execution and consensus layers. Here are some things that can benefit from being SNARKed:

SNARKing the L1
SNARKs for Verkle Trees
SNARKs for Consensus State Transitions
SNARKs for Light Clients
SNARK/STARK ASICS

Snarkifying all these different parts of Ethereum can achieve the goal of The Verge: making block verification extremely easy and trustless.

The EVM (Execution)

SNARKs for the EVM: Ethereum can leverage all of the work on zk-EVMs done by L2 teams and implement it directly into the L1.

The Beacon Chain (Consensus)

SNARKs for Verkle Trees: Ethereum can reduce the entire Verkle Tree into a single proof, a SNARK, further improving efficiency.
SNARKs for Consensus State Transition: Ethereum can replace sync committees with SNARKs. This would allow for trustless verification of everything happening on the consensus layer. (Sync Committees: A Sync Committees is a group of 512 randomly selected validators that rotate every 256 epochs. Sync committees sign blocks of the canonical chain, and make it easy to build light clients that follow the consensus layer (Helios for example).
SNARKs for Light Clients: Eventually we can replace the sync committee light clients with SNARK-based light clients.

Miscellaneous

SNARK/STARK ASICS: Build hardware (ASICs) that is designed specifically to build SNARK or STARK proofs.

This is the first ever SNARK proving ASIC!! “Real time proving, real time settlement, universal synchronous composability.” (H/T Justin Drake)

Benefits

Easier Block Verification: SNARKifying Ethereum will make block verification much easier, which is the M.O of the Verge upgrade. Block verification could become so easy that it could be done on a phone or a smartwatch.
Increasing the Gas Limit. Recall that the gas limit can be increased or decreased at any time, but only in small amounts. However, once the EVM is snarkified, the gas limit can be increased substantially (or potentially even removed)!

Related Research/Proposals

What Might an “Enshrined ZK-EVM” Look Like? - HackMD - Vitalik

Roadmap to a Fully SNARKed Ethereum

Once all of the different parts of Ethereum use SNARKs, Ethereum can be considered “fully SNARKed.” Because of the complexity of SNARKing things, the timeline is unknown, though if I had to put a number on it, I would say this stuff will take a few years, at minimum.

Move to Quantum-Safe SNARKs (e.g. STARKs)

Ethereum needs to future-proof itself from quantum computers before they become a serious problem. This means transitioning from SNARKs, which can be broken by quantum computing, to STARKs, which can’t.

SNARKs & STARKs are both used on Ethereum for various things, though SNARKs are more common as they are more efficient. SNARKs were conceived 6 years before STARKs (2012 vs 2018), and so SNARKs have been able to garner much more development and better documentation. Aside from the 6 year head start, SNARKs are also cheaper, which could be a factor for their increased commonality.

Although currently behind, I think STARKs will catch up to SNARKs in the next five years in terms of development and usage. We are already seeing this happen, albeit slowly.

Roadmap to Quantum Protection

It's tough to give a definitive timeline for when Ethereum plans to complete the transition to being quantum resistant. This is because quantum computers are a known risk, but the timeline of them is unknown, and so transitioning to defend against them hasn’t been prioritized by Ethereum yet.

Similar to how AI exploded in popularity over the past year (after being talked about for 15 years), I think quantum computing will have a similar path and come out of nowhere, which can be a scary thought. I’m hopeful that Ethereum will stay ahead of the ball on quantum computing and implement the proper technology to defend itself in time.

The Purge: Eliminating Historical Data & Technical Debt

Goal: Simplify the protocol, eliminate technical debt and limit costs of participating in the network by clearing old history.

Status: There are three major upgrades part of the purge: history expiry, state expiry & statelessness. All three of the upgrades are in the research phase (though implementing history expiry is more of a social issue than a technical one).

What’s Been Implemented?

Eliminate Most Gas Refunds - These include gas repricing done in the Berlin upgrade (EIP-2565, EIP-2718, EIP-2929, EIP-2930). EIP-2938 could be relevant here.
Beacon Chain Fast Sync – In the past, clients had to sync from the genesis block, verifying each block until the head of the chain. Nowadays, clients use "weak subjectivity checkpoints" to start syncing from a trusted point closer to the present, allowing them to discard data before that checkpoint without losing their ability to sync to the head of the chain. This is known as checkpoint sync in most consensus clients.
EIP-4444 Specification - The EIP-4444 specification is complete! Here is the official doc.

What’s Left To Implement?

History Expiry (EIP-4444)
State Expiry
Statelessness

History Expiry

A blockchains history refers to everything that has ever happened onchain. Nodes are currently required to store all of this history, which is already a large amount of data that is only growing. History expiry will allow nodes to prune away older data they are unlikely to need and therefore reduce storage requirements.

Motivation

One of Ethereum's bottlenecks is hard disc storage, and we are only a few years away from the chain being too large to store on the average hard drive. Once the chain is too large for the average hard drive, running nodes will become less common, because beefy hard drives are expensive. Ethereum’s ethos is the opposite of expensive hardware and believes that allowing anyone to run a node on modest hardware is critical for decentralization. Nodes are vital to everyone in the system, and so Ethereum must maintain the ability for everyday people to run a node - no matter where they are in the world or how fat the chain history becomes.

Benefits to Running a Node

Running a node allows you to cryptographically verify the data yourself, instead of relying on third parties to provide the data. Don't trust, verify.
Running a node guarantees your ability to submit transactions directly to the p2p network at any time. If you dont run your own node you run the risk of getting your transaction refused by a third party node (for whatever reason).
Running a node can improve your privacy as you don't leak information such as your IP address or Ethereum address(es) to third party nodes.
Running a node improves the resilience of the underlying network.
Running a node gives you control in the event of a fork, allowing you to pick which set of rules you support (either stick with the old rules or upgrade to new ones).

To maintain access for anyone to run a node, Ethereum will have to reduce the storage requirements for nodes, and one of the areas of storage Ethereum can target is historical data.

EIP-4444 (History Expiry)

History expiry refers to pruning away older (historical) data. Nodes will be able to remove older data that they are unlikely to need and only keep a small amount of data relevant to them. They can continue to get rid of less relevant older data as new data arrives.

The history of Ethereum consists of a large amount of data that will only keep growing and growing, and so history expiry is a necessary upgrade if Ethereum wants to keep node hardware costs at a modest level. EIP-4444 would reduce the disc storage requirements on historical data and would make running nodes more viable, especially in the long term.

Why Do We Need Historical Data?

Historical data is needed for two reasons:

Syncing data requests
Serving data requests

And because certain applications and users need historical data, Ethereum can't just expect us to prune it all away beyond a specified date, as doing so would lead to big problems for these groups. So, to ensure these users and applications have continued access to the data they need, the Ethereum community needs to make sure the data is still being stored somewhere by someone. Here are some ideas of who could step up and store the data:

Individuals and/or Institutions: (think of the Anthony Sassano’s of the world for individuals, institutional-wise think Consensys, Infura, etc).
Block Explorers: Companies like Etherscan will almost definitely step up here as an important part of their business relies on providing the history of the chain.
API Providers: Think Figment, maybe they expand to providing historical data APIs outside of the ones they currently offer.
Data Services: It seems intuitive that companies who offer data storage services like Arweave & Filecoin would begin to offer historical data services for Ethereum if/when the market demands it.
Indexing Protocols: Indexing protocols like The Graph also seem like an intuitive fit here.
p2p File Sharing Protocols: Why not? Examples include BitTorrent, Gnutella, etc.
Rollups: Rollups directly or indirectly rely on historical data for their business and so they are a good fit to store historical data. If not the rollups themselves, they could set up a public goods funding round and pay someone to do it for them.
DAOs: There could be a DAO that is created to specifically store and manage historical data.

Controversy & Future of EIP-4444

Controversy of EIP-4444: Ethereum has always provided access to historical data, and because history expiry removes the responsibility of providing historical data from in-protocol to out-of-protocol, it’s not surprising there is controversy surrounding EIP-4444. Relying on entities outside of the core protocol to provide historical data introduces potential censorship risks as they have control over the data. If EIP-4444 were to get shelved it would be due to the community rejecting the potential censorship of historical data, and not because of technical reasons. We will have to wait and see how the discussion continues to play out regarding EIP-4444.

Read More: here

Future of EIP-4444: EIP-4444 is not ready for implementation although it is currently under active discussion here. The problems surrounding implementation are not really centered around technical difficulties but rather on if robust solutions can be found to the controversy listed above; who will store the data if not Ethereum? And, if solutions are found, will the community accept them?

Until these questions are answered, we will not see an implementation of EIP-4444.

State Expiry

What is Ethereum’s State?

The Ethereum state refers to all of the addresses, contracts, and data associated within the contracts at the current block. Your balance, other users balances, NFTs, pools, etc are all things that fall under the definition of state.

Mental Models

State is the RAM of Ethereum - Tim Beiko

Motivation

State storage is a notoriously weak spot in Ethereum’s economics. Writing new state to Ethereum will only cost you once, although consensus nodes will have to store your data forever, which is completely unsustainable. State growth must be bounded somehow, which is where state expiry comes in.

What is State Expiry?

State expiry means to remove inactive state (state that hasn’t been accessed recently) from nodes after a specific period of time. Unused portions of state would automatically expire and only a verkle tree root would be kept so that users can revive expired state should they need to. Storing old state data will not be the responsibility of nodes anymore and will become other solutions responsibilities such as a dedicated DAO or volunteer individuals/institutions.

Instead of state and data storage services being offered in-protocol via consensus nodes, these services will be offered out-of-protocol by third parties. In other words, state expiry and history expiry are similar in that they both create new storage assumptions.

Read more about State Expiry here, and here

This diagram is displaying the mechanism used in this specific state expiry proposal:

This diagram is showing a “state tree period”, where 1 period = 1 year. Each period is associated with a state tree, meaning that when a new period begins, a new state tree is initialized. Nodes can read objects themselves in the two most recent periods without a witness, however anything older than 2 periods requires a witness.

Shoutout to Trent Van Epps for his description of a witness:

“Witnesses are like a proof that you attach to transactions that tells a block producer (miner or validator) that your transaction is legitimate, and includes all of the information necessary to execute that state change.”

Simple Mental Model: Think of it like a receipt that you need to return something to the store.

Benefits to State Expiry

Lower Storage Requirements: Lowering the storage requirements for nodes has several implications:

Improved Scalability: By removing inactive, older, or seldom-used smart contract data, state expiry helps reduce the overall size of the blockchain (the state). Because nodes will be focused on more relevant portions of the state, they will be able to synchronize to the tip of the chain faster, process transactions faster, and ultimately, reduce the storage requirements for themselves. Essentially, it makes nodes cheaper and faster. Paradigm has talked about how state expiry could solve state growth (long term).

Improved Decentralization: By lowering storage requirements, state expiry will reduce the barriers to entry to run a node, with the hope that more people will then run a node and improve the decentralization properties of the network.

More Responsible & Efficient Usage of State: The state deployed by users will expire at some point in the future, and so they will be encouraged to clean up any unused data before it expires. Also, an implementation of storage rent could incentivize users to be more efficient and responsible when managing their smart contract data.

Roadmap to State Expiry

State expiry is still in the research phase and is expected to be implemented in a few years - that is if state expiry is needed, as verkle trees could be enough. This mindset has been reflected in the most recent release of the Ethereum roadmap, as the focus on state expiry was shrunk:

Before:

After:

A proposal from Vitalik highlights three different proposed paths to achieving state expiry here.

Statelessness

Statelessness looks to reduce the storage requirements to run an Ethereum node by changing how they handle data. Currently, there are two approaches to this, weak statelessness and strong statelessness.

Motivation

Centralized block production is inevitable, so we must keep the validation of the blocks being produced decentralized.

Dankrad had a great piece on why we should go stateless.

There are two types of statelessness to break down: weak statelessness & strong statelessness.

Weak Statelessness: Weak statelessness will have block proposers handling state storage, allowing all other nodes to verify blocks statelessly. “State isn't required to validate a block, but it is required to build a block.” Block builders will have to include a witness in each block, which is just a proof that they accessed the correct state. I recommend reading Jon's article to dive deep into how weak statelessness works and the why behind the upgrade.
Strong Statelessness: Strong statelessness removes the need for any node to store the entire state. Transactions are sent with witnesses that can be aggregated by block producers.

Weak statelessness is currently a part of Ethereum’s roadmap while strong statelessness is not. This is because weak statelessness is expected to meet Ethereum’s scaling needs.

Prerequisites to Weak Statelessness

Verkle Trees: Witnesses need to be very small so they can be broadcasted over the network and processed by nodes in time. Verkle trees make it so witnesses are viable to operate as they are much more efficient at storing state than their predecessor merkle trees.

PBS: PBS separates the proposer role and the builder role. This enables block builders to become beefier and have the resources required to handle all the state data in lieu of the validators.

Benefits of Statelessness

Raising the Gas Limit: With less state bloat, the gas limit could be raised allowing Ethereum to process more transactions.
Improved Sync Times: Nodes would be able to sync basically instantly, instead of taking a few days-weeks. This has its obvious benefits.
Lower Hardware Requirements: Statelessness will drastically reduce the hardware requirements to run a node and usher in an era where we can validate blocks on our phones.
Lower SSD Requirements: Reducing the state data storage requirements on nodes (statelessness) is directly linked to lowering the SSD requirements, which is the key bottleneck to scaling Ethereum today. Also, because the SSDs are now being used much more efficiently than before, they could have a prolonged lifespan.

Justin Drake: Statelessness is an intermediary step towards Ethereum being a full zk-EVM:

“Right now, you need a raspberry pie for computation, but also a pretty large harddrive (1tb). Statelessness is a way to remove the harddrive, and you can think of statelessness as an intermediary step toward a full zk-EVM. It's kind of halfway through, where you remove the raspberry pie itself and replace it with a smart watch.”

Roadmap to Statelessness

Weak statelessness is still in the research phase, with an implementation expected to be a few years out. Don't forget, weak statelessness isn't possible without verkle trees and PBS, so watch the timeline on those upgrades.

The Splurge: Miscellaneous But Important Extras

Goal: Fix everything else.

Status: Account abstraction has made serious strides in the ecosystem over the past year as focus has really shifted to improving the UX on Ethereum, with AA at the center of it. I expect this focus on AA to continue until every part of Ethereum UX has been improved drastically. The other tools to implement are less urgent and focused on, but nonetheless important.

What’s Been Implemented?

EIP-1559 — One of the more popular EIPs, EIP-1559 has been implemented and has been successful.
ERC-4337 Specification is complete.

What’s Left To Implement?

Account Abstraction
EIP-1559 Endgame
EVM Endgame
Explore Deep Cryptography
Explore Delay-Encrypted Mempools
VDFs
Explore Solutions for Dust Accounts

EIP-1559

EIP-1559 was a change to Ethereum’s fee market mechanism implemented in August 2021 via the London hardfork.

For years prior to EIP-1559, Ethereum’s transaction fee mechanism was a first price-auction. In other words, the fee mechanism was additive - meaning you had to compete for consumption. Everyone submitting a transaction had to specify a gas price for their transaction to be processed with the highest bidder (highest gas price) winning. These bidding wars resulted in lots of failed transactions for users as they would set their bid too low resulting in transaction failure, or overpay for transaction inclusion by setting their bid too high. The bidding wars caused lots of problems for regular users who just wanted to transact with the chain and not worry about setting the gas price properly, and thanks to EIP-1559 they are gone.

EIP-1559 was able to reduce the inefficiencies experienced by users transacting on Ethereum with the introduction of a base fee and a tip. The base fee is like the universal gas price for transacting on Ethereum, and everyone must pay that fee to be included in a block. However, instead of the fee going to the validator, the base fee is burnt. The tip is used by users who need fast inclusion in the next block or need their transaction to have a specific position inside of the next block. Users who need fast inclusion can pay a high tip, which gives them a better chance to be included into the block. Tips are transferred directly to the validator who included the transaction in the block. These two features (the base fee and the tip) have been able to stabilize the gas price and drastically improve the UX when transacting on Ethereum.

Here is a good diagram showing the before and after of EIP-1559:

Benefits of EIP-1559

Drastically improved the UX (way less failed transactions).
Stabilized the gas price.
Made it much harder to overpay for transaction inclusion (pre-1559, users would unknowingly overpay for inclusion because of PGAs driving up gas prices). This was eliminated with EIP-1559, although individuals can still “overpay” for inclusion by tipping however much they want to validators (on top of the base fee) if they need priority in that block.
Greatly improved the economics of ETH (the effects of the burn have been especially noticeable since the merge).

Ultimately, EIP-1559 was a fantastic upgrade that improved the UX massively, reduced over-payment for transaction inclusion, and greatly improved the outlook on ETH the asset.

Account Abstraction

Account abstraction refers to removing (abstracting away) the complexities of the two Ethereum accounts, known as contract accounts and external accounts. Contract accounts, aka smart contracts, are controlled by code. External accounts, aka EOAs, are controlled by a private key. A Uniswap contract would be considered a contract account (smart contract), whereas your Metamask wallet would be considered an external account (EOA).

Motivation

Your EOA is controlled by you via your private key, which allows you to sign transactions. This allows you to self custody your own assets, meaning you can do whatever you like with your assets, whenever you want. Self custody is amazing, but really it is a double edged sword - if you lose your key, you lose your account. There is no “forgot my password” backdoor, which is a problem for all users, especially ‘normies’, and is how we arrive at account abstraction.

Remember, AA reduces Ethereum from 2 account types (contract & external) down to 1 - a contract account. Contract accounts are a big deal because they are much more customizable than EOAs, allowing them to offer many new features that are not possible with EOAs, such as: sponsored transactions, social recovery, better key management, auto-payments, transaction bundling, sessions keys, and more.

Combine all these features with a great end facing website/UI for users and we can take Ethereum’s UX from zero-to-one.

Stay Updated on AA: Check out Etherspot, they publish a weekly report called “Weekly Digest: Everything About Account Abstraction.”

ERC-4337

The leading implementation of AA is EIP-4337, which was introduced to the Ethereum ecosystem earlier this year at ETHDenver.

EIP-4337 introduced a separate mempool specifically for transactions conforming to the AA standard, known as UserOperations. UserOps are sent to the “UserOperation mempool” and are handled by the Bundler, who bundles the UserOps into a bundle transaction and sends them off to be included in a new Ethereum block.

Diagram of the AA supply chain:

source

Number of User Ops (as of March 21, 2024)

source

Relevant EIPs

EIP-86: Abstraction of transaction origin and signature (In-active)
EIP-2938: Account Abstraction (In-active)
EIP-3074: AUTH and AUTHCALL opcodes (In-review)
ERC-4337: Github (Live)
EIP-5003: Insert Code into EOAs with AUTHUSURP)
EIP-7377: Migration Transaction
EIP-5792: Wallet Function Call API - Ethereum Improvement Proposals
ERC-6492: Signature Validation for Predeploy Contracts
ERC-6900: Modular Smart Contract Accounts and Plugins
RIP-7560: Native Account Abstraction combining EIP-2938 with ERC-4337
RIP-7212: Precompile for secp256r1 Curve Support (allows for transaction signing via biometric authentication on mobile devices).

Clave, a project building a smart wallet, has a great article that covers the evolution of AA and the different EIPs that got us here.

Other Relevant Research

Benefits of AA

Social Recovery: Support for social recovery. An account can be recovered even if the key is lost.
Multisig: Support for multisig transactions.
Sponsored Transactions: This could be anything from allowing third parties like applications to cover tx fees, or it could be allowing users to pay fees with ERC-20 tokens instead of ETH (a contract could serve as an intermediary and convert the ERC-20 tokens into ETH).
New Signature Schemes: Potential to support more efficient & simpler signature schemes (Schnorr, BLS) as well as quantum safe ones (Lamport, Winternitz). Problems arise when you look at Ethereum’s signature scheme, ECDSA - specifically its weakness to quantum computing. It is not quantum resistant, and although this is not a problem yet with the tech being years and years away, quantum computers could break ECDSA encryption and render Ethereum transactions unsafe (true for Bitcoin as well).
Wallet Upgradability: Wallets can change public keys or upgrade their code entirely.
Multi-call AKA Tx Bundling: Multicall allows you to execute multiple contract calls in one transaction. For example: approve token 1, approve token 2, and add liquidity could all happen in one transaction to an AMM.
Multi-factor Authentication: Like in classic web2, users can define that 2 (or more) signatures are required in order to execute a transaction.
Session Keys: Session keys allow you to pre-approve certain transaction criteria. For example, when using a DApp (let’s say a game), session keys would allow you to pre-approve criteria related to your transactions, meaning you could do things like playing the game as much as you want without having to sign a transaction for every in-game action you want to do.

Projects Utilizing AA (a-z)

Alchemy Modular Account: A smart account implementation that is fully compatible with ERC-4337 & ERC-6900. Modular Account - Alchemy
Ambire Wallet: AA wallet available on Ethereum, L2s, and other EVM chains. Ambire Wallet
Argent Wallet: Was the first major smart contract wallet, and has social recovery implemented. Argent
Based App: Based app is a non custodial visa debit card and an account abstraction wallet. Based App
Beam: Beam is a decentralized payments solution built by Eco Inc., backed by a16z. Beam is non custodial, and aims to be venmo of crypto. Beam
Biconomy: The ultimate toolkit to leverage smart contract wallets & build custom transaction journeys. Biconomy
Blocto: Offers both a smart wallet and an SDK. Blocto
Braavos Starknet Wallet: A smart contract based wallet for managing your funds & NFTs and connecting to Dapps on top of Starknet. This is a great article covering signing transactions: Signing Txs - Braavos
Candide Wallet: Is an Ethereum wallet built as a public good, deploying on Optimism. Candide Wallet
Cartridge: Cartridge is building a gaming console (a wallet you could say) on Starkware that utilizes AA. Cartridge
Clave Wallet: Clave is a non custodial wallet powered by AA. Clave Wallet
Coinbase: Coinbase has its foot in the game and is developing a smart wallet. They will now offer smart wallets powered by the Coinbase Wallet SDK, and Embedded wallets (app specific wallets) powered by their Wallet-as-a-Service solution. Coinbase Blog
Creso Wallet: A smart wallet built on ERC-4337.
Den: Den provides a self-custodial multi-signature wallet, and is built on top of the safe contracts (formerly Gnosis safe). Den can enable paying for gas from your safe wallet instead of your personal signing wallet, or other things like allowing third parties to create “payment requests” with you (good for payroll, invoices, etc). Den
Ether Deck Mk2: A minimalist Gnosis safe but for individuals. Mk2 - jtriley
Etherspot: Etherspot is an account abstraction SDK. Leverage the best features of ethereum along with EVM-compatible chains easily and for cheap. Etherspot
Fiat Paymaster: An AA paymaster that allows you to pay for gas fees with PayPal. Fiat Paymaster | ETHGlobal
Fluvi Wallet: Fluvi is a non custodial smart contract wallet. Fluvi Wallet
Fuelet Wallet: The leading AA wallet on Fuel. FuelVM has native support for AA. Fuelet Wallet
Fun: Fun is building FunKit, an SDK designed to create and manage smart wallets, built on Base. Fun
Gelato: Gelato’s SDK combines the gelato relay with Safe’s smart contract wallet to enable AA. Gelato x Safe
Gani Wallet: An interchain AA wallet. Uses streamlined gas payments via hyperlane. Gani Wallet
Instadapp’s Avocado: Avocado is a cross chain aggregator with built in account abstraction. Avocado network allows users to transfer any token from any supported chain to their address on Avocado with all gas fees paid in USDC. Instadapp Avocado
Ledger Fresh: Ledger Fresh (built by the ledger team) is building a security oriented web wallet interface that interacts with an account smart contract on Starknet.
Linen Wallet: Easy to use multi-key wallet with account abstraction built on Gnosis Safe. Deployed to ETH/Polygon. Sadly, Linen recently announced they will be shutting down the project :( still going to leave it in. Linen Wallet
Loopring Wallet: Built by the Loopring team, the Loopring wallet is a ZK rollup for payments and decentralized exchange - and it has social recovery implemented. Loopring Wallet
Obvious Wallet: Smart contract wallet for Ethereum & EVM chains that is built for mobile. Obvious Wallet
OPclave: Uses the OP stack to turn iPhones into a hardware wallet with full AA support. OPclave
Openfort: Openfort is a wallet as a service solution that is tailored for gaming. Allows you to create and manage smart wallets via AA. Openfort
Peaze: Peaze offers a wallet SDK powered by AA. Peaze
Pier Wallet: Pier is a multichain non custodial smart wallet. Pier Wallet
Pillar: Pillar is a self custodial smart wallet, powered by Etherspot. Pillar
Pimlico: Pimlico provides things like bundlers and paymasters allowing your dApp or wallet to integrate sponsored transactions. Pimlico Docs
Plena Wallet: Self custodial AA wallet. Plena Wallet
Safe (prev Gnosis Safe): Safe is a smart contract wallet running on multiple blockchains that requires a minimum number of people to approve a tx before it can occur (m-of-n). Safe recently launched Core, an open source stack that uses account abstraction to simplify smart contract development on Ethereum. Safe
Sequence: Sequence offers an EVM smart contract wallet, as well as a wallet SDK, targeting the Ethereum & EVM ecosystem. Sequence
Solon: A blockchain agnostic platform for dApps and other web applications. Solon
Soul Wallet: Soul is a smart wallet. Soul Wallet
Stackup: Allow you to instantly create wallets for your users using social logins on any EVM blockchain. Stackup
Starknet & zkSync will both launch will native account abstraction. Starknet & zkSync
Swype: a non-custodial wallet & bank account. Swype
UniPass: Unipass is a non custodial ERC-4337 wallet SDK. Unipass
Visa: Wrote a technical paper on “Auto Payments for Self-Custodial Wallets”, utilizing account abstraction to see how smart contracts enable automated programmable payments. They built the application using Starknet & the Argent Wallet - Visa Paper. Visa also recently released an experimental solution where users can pay for gas fees with their credit card. You can just swipe your card and let Visa handle the necessary blockchain interaction in the background. Visa Paymaster
ZeroDev: ZeroDev provides smart wallets as a service. They offer embeddable and programmable smart wallets, powered by AA. ZeroDev

Socials:

Core Contributors to AA: Vitalik, Sam Wilson, Kristof Gazso , Yoav Weiss
@erc4337: Official Twitter account for ERC-4337 account abstraction. @ERC4337
Twitter Accounts: @4337Mafia: Group of devs/companies pushing for the universal adoption of account abstraction @4337mafia.

Wallet Fragmentation Issues

Fragmentation currently seems like an issue in the wallet space. There are sooo many different wallets, which makes it hard to know what is best to use (and why). Just imagine all the talent and money that’s being fragmented across all of the different wallet teams and what would happen if that talent and money consolidated. More experts should be working together (IMO).

Roadmap to Implementation

EntryPoint was introduced to the Ethereum ecosystem on March 1st, 2023 at ETHDenver. EntryPoint is a smart contract that conforms to the ERC-4337 standard and allows for the associated benefits that come with ERC-4337. The smart contract has undergone a security audit from OpenZeppelin and it is accessible to any EVM-compatible chain (Optimism, Polygon, Avalanche, etc). Because no protocol level changes needed (EntryPoint is simply just a smart contract) deployment was very straightforward. EntryPoint is a big step forward for Ethereum as it brings us closer to a fantastic UX. The goal is to enshrine AA into the Ethereum protocol eventually.

Endgame of AA: The Account Abstraction Improvement Track

The endgame of Account Abstraction includes 3 things:

Short-Term: ERC-4337 Rollout
Medium-Term: Voluntary EOA Conversion
Long-Term: In-Protocol Enshrining

Let’s dive into them:

ERC-4337 Rollout (Short-Term): This includes getting ERC-4337 to full production, and then developing smart contract wallets that are easy to use. Bootstrapping the ERC-4337 ecosystem into layer 2 protocols where gas costs are less of a problem is a good start.
Voluntary EOA Conversion (Medium-Term): With an EIP, allow a normal account to irreversibly add code to convert it into a contract, namely to become a 4337-compliant smart wallet. EIP-5003 & EIP-7377 are two proposals that effectively allow EOAs to migrate to a smart contract permanently. With EIP-5003, you can bundle migrations, whereas with EIP-7377 you can only do 1 EOA migration per transaction. Voluntary migration is already happening on L2s. For example, both ZkSync and StarkWare have introduced a modified version of ERC-4337 Account Abstraction to their protocols.
In-Protocol Enshrining (Long-Term): Consider making the above conversion mandatory for all existing accounts. This would make contract accounts the only account type, and would remove ECDSA from the protocol (ECDSA = PubKey/PrivateKey).

Alternative Options

Completing these steps would bring us to the endgame of AA, although there have been some alternatives proposed from Vitalik:

“Consider writing an EIP that enshrines ERC-4337 equivalent accounts and txs at protocol level, and push for its adoption in L2s.”
“Use a censorship resistant solution that works through auxiliary blocks, removing the need for user operations to be legible to the Ethereum protocol.”

Native Account Abstraction (RIP-7560)

RIP-7560 is a proposal to make a native version of account abstraction.

First, some important context:

ERC: Ethereum Request for Comment

EIP: Ethereum Improvement Proposal

RIP: Rollup Improvement Proposal

RIP-7560 combines ERC-4337 & EIP-2938 into a native version of account abstraction. If implemented, RIP-7560 would require consensus layer changes to the protocol. Research has highlighted that it’s a top priority to make ERC-4337 cross compatible with EIP-7560. It’s very important that we don’t create two competing systems and that they instead coexist.

For a further understanding, check out this post by Alexander Forshtat which covers RIP-7560 in good detail.

EIP-1559 Endgame

The endgame of EIP-1559 is to make the fee markets multidimensional. This means that some resources (compute) will be priced differently than other resources (storage), instead of all tethering to one pricing unit (gas).

Research/Proposals

Ansgar Dietrichs had a great presentation modeling the resource relationships within Ethereum, talking about additive models, independent models, burst sustained models, and others.

Ansgar’s Presentation (Summarized):

Original Ethereum Fee Mechanism - Additive: Meaning that you compete for consumption.
EIP-1559 - Additive Burst-Sustained: The EIP-1559 upgrade introduced variable-sized blocks in exchange for fixed-sized blocks. The upgrade doubled the gas limit from 15 million to 30 million, while the gas target figure stayed at 15 million. The target is set at 15 million to limit the sustained resources and handle the sustained capacity, and the hard limit is set at 30 million to handle the burst capacity.
Multidimensional EIP-1559 - Independent Burst-Sustained: A multidimensional implementation would still have a burst sustained model as a way of monitoring demand in the system. The dimensions don’t have to be additive and could instead be independent.

Problems With Changing The Fee Mechanism

Choice of Model: What resource types and what type of relationships (additive, independent) are most optimal?
Backwards Compatibility: Ethereum is a live system up and running and so changing its assumptions from a one-dimensional fee system to a multidimensional fee system can be difficult to do without breaking anything. (This could break things onchain (smart contracts), but also offchain (tooling, UX).
Getting the Work Done: Ethereum’s innovation process (getting upgrades into the roadmap and worked on) is bottlenecked by its governance process (coordinating everyone to agree on the future upgrades). Ethereum is limited in how many upgrades it can prioritize at once, and so that’s the question for multidimensional EIP-1559: do we want to prioritize it? Is it a feasible upgrade?

EIP-4844: Shard Blob Transactions

This EIP would bring the first multidimensional (in this case two-dimensional) market for Ethereum resources, specifically data storage and execution. Data gas will be introduced as a new type of gas, independent of normal gas, and will be used exclusively to price blobs. By adding a second dimension (data gas) to the existing fee market, we get much more efficient pricing. This is effectively known as resource pricing, where you price different resources separately, instead of with a universal unit like gas.

Resource pricing is an important topic in regards to blockchains and their futures: read more here.

Roadmap to EIP-1559 Endgame

Open questions still need to be answered surrounding multidimensional EIP-1559:

Does Ethereum want to prioritize the upgrade? When we see multidimensional EIP-1559 implemented depends on how much the community wants to prioritize it.
Is it a feasible upgrade?

EVM Endgame

The endgame of the EVM involves simplifying but also improving the EVM. The goal is to get rid of technical debt (e.g. self destruct), while also adding new features. The upgrade is split into the EVM simplification track (simplifying the EVM) and the EVM improvement track (improving the EVM).

EVM Simplification Track:

Remove SELF-DESTRUCT

SELF-DESTRUCT is the root of many problems in Ethereum:

It’s the only opcode that breaks important invariants.
It can cause the code of a contract to change.
It can change other accounts balances without their consent.

On top of these issues, SELF-DESTRUCT makes changes to different state data structures very difficult, and so verkle trees can’t be implemented until SELF-DESTRUCT is removed. Overall, SELF-DESTRUCT causes more harm than good in the Ethereum ecosystem and we’d be better off without it.

Read More: Destruction of SELF DESTRUCT

Related EIPs:

EIP-6780 (EIP-6780 was included into the Dencun upgrade, which went live on March 13th, 2024).
EIP-4758
EIP-4760
EIP-6049

Simplify Gas Mechanics

This involves removing outdated gas-related EVM features, such as: the 2300 gas stipend, gas visibility, gas refunds (gas tokens). Outside of these high priority features, there are some less urgent ones to be addressed: RIPEMD160 precompile, dynamic jumps, and the MODEXP precompile.

Read More: Removing EVM Features - Vitalik

Precompiles ->EVM Implementations

Get rid of precompiled contracts in favor of direct EVM implementations (big modular arithmetic for example).

EVM Improvement Track:

EVM Object Format (EOF)

EOF is a set of EIPs that will introduce significant changes to the EVM if/when it is implemented. It is the biggest upgrade in the EVMs history. By adding structure and versioning around the bytecode, we can make the system cheaper, faster, and safer.

Diagram: legacy EVM vs an EOF version

EOF EIPs (list of all EIPs going into EOF)

TBA: Contract creation, restrict code and gas introspection

The EIPs:

EIP-3540 (EOF v1): EIP-3540 introduces the EOF container for packing and distributing EVM bytecode and associated metadata. The container is composed of a header and a body, each containing different information. The header would contain information about the format version and compatibility. By including versioning information, this EIP enables developers to manage different versions of smart contracts packaged in the EVM object format (EOF). Features could now be easily introduced or deprecated, something that is desperately needed in the EVM. Versioning is crucial in software development as it ensures compatibility with existing deployments. With versioning support in EIP-3540, developers can effectively manage and deploy multiple versions of smart contracts while maintaining compatibility with the relevant runtime environments and tools.

EIP-3670 (Code Validation): Introduce code validation for EOF formatted contracts (EIP-3540) at contract creation time. Reject contracts with truncated PUSH-data or undefined instructions. Legacy bytecode remains unchanged. The goal is to ensure code validity in consensus and simplify bytecode analysis for EVM implementations. This could also potentially reduce complexities in EVM implementations.

EIP-4200 (Static Relative Jumps): The proposal introduces three new EVM jump instructions (RJUMP, RJUMPI, and RJUMPV) that encode destinations using signed immediate values. These instructions aim to offer a cost reduction and simplify code analysis for cases where static control flow is sufficient, while dynamic jumps can still be used for specific scenarios.
EIP-4750 (Functions): The motivation behind this change is to eliminate the need for dynamic jumps in the EVM, which will simplify validation, enable optimizations, and potentially reduce the cost of jumps. The proposal allows for breaking down EOF-formatted bytecode (EIP-3540) into multiple code sections, each functioning as an independent subroutine or function. To enable this, two new opcodes, CALLF and RETF, are introduced, providing the means to call and return from these separate code sections as needed.

EIP-5450 (Stack Validation): The proposal seeks to strengthen the validation process for EOF code sections in contracts, ensuring that no stack underflow or overflow can happen during execution. By implementing this extended validation, the goal is to eliminate exceptional conditions and ensure that only valid and safe code can be executed and deployed without the need for frequent checks during runtime.

EIP-6206 (Introduce JUMPF): This EIP introduces a new instruction, JUMPF. JUMPF allows for things like tail call optimizations in EOF functions (EIP-4750), or declaring sections as non-returning.

EIP-7480 (Data section access instructions): This EIP introduces four new instructions, allowing reading of the EOF containers data section. The instructions are: DATALOAD, DATALOADN, DATASIZE, and DATACOPY.

EIP-663 (Unlimited SWAP & DUP instructions, Introduce SWAPN & DUPN): SWAP & DUP instructions are limited to a stack depth of 16 items. EIP-663 will Introduce SWAPN & DUPN, raising this limit to 256 items.

EIP-7069 (Revamped Call Instructions): EIP-7069 introduces three new call instructions: CALL2, DELEGATECALL2, and STATICCALL2. The new call instructions remove specifying gas limits, instead relying on the 63rd/64th rule (EIP-150). The stipend rules are simplified, making it easier for callers, and the obsolete output buffer addressing is replaced with RETURNDATACOPY. Instead of returning a boolean (true or false), 3 status codes are returned: 0 for success, 1 for revert, 2 for failure. New contracts are expected to use the new instructions as they are more efficient, though some contracts (ERC-4337) will use the old instructions as gas limiting is required.

This diagram goes over the various changes to opcodes:

source

Roadmap To Implementation

The EOF upgrade has been proposed to be included in the Prague/Electra hardfork, which follows the Cancun/Deneb hardfork.

Stay updated & learn more: Here, here

Big Modular Arithmetic

A lot of the Ethereum roadmap’s cryptographic upgrades rely on modular arithmetic (modular math) over very large numbers. This modular arithmetic could be done directly in the EVM, which would really help the efficiency of Ethereum.

EVMMAX (EVM Modular Arithmetic Extensions)

“EVMMAX aims to bring greater flexibility to arithmetic operations and signature schemes on Ethereum.” - https://etherworld.co

Related Research/Proposals

EVMMAX:

EIP 5843: EVM Modular Arithmetic Extensions (Dependent on EOF, specifically EIP-4750 and EIP-3670).
EIP-6601: EVM Modular Arithmetic Extensions (Also dependent on EOF, specifically EIP-4750 and EIP-3670).
EIP-6690 - EVM Modular Arithmetic Extensions (No dependency on EOF).

BLS:

Further EVM Improvements

Further EVM improvements could mean implementing new EVM upgrades, as well as removing unwanted features. The two of the main goals of making further EVM improvements are:

Make the EVM more efficient
Make the EVM less complex

Another goal outside of efficiency and complexity would be improving privacy. The EVM completely lacks privacy protections, which is a problem for lots of users. This will need to change at some point.

Vitalik has a good post where he covers a list of EVM features potentially worth removing: https://hackmd.io/@vbuterin

Explore Deep Cryptography (e.g. Obfuscation)

Ethereum will continue to explore deeper into cryptography and how it can be tied back to improve our systems. More specifically, things like:

Obfuscation: Obfuscation can augment privacy within cryptographic systems. By transforming a program into a "black box," obfuscation ensures that while the program's functionality remains intact, its internal workings are concealed. This technique not only enhances privacy but also secures intellectual property by making the logic of proprietary algorithms indiscernible.

FHE (Fully Homomorphic Encryption): FHE can also improve upon privacy. It allows for computations on encrypted data, producing encrypted results that, when decrypted, match the outcome of operations performed on the plaintext. For example, this means FHE can do things like encrypt transactions within a blockchains mempool (an encrypted mempool). Another example would be encrypting MPC data - encrypt individual pieces of data from various parties and enable secure computations without revealing the underlying data.

One-Shot Signatures: One-shot signatures are special cryptographic signatures where a private key can only sign one message. The private key cannot be copied and must be destroyed to produce a signature. Despite their quantum basis, the signatures themselves are just bits and bytes, which do not require quantum communication. To quote Justin Drake “In the long term, thanks to one-shot signatures, the importance of operators (and the importance of distributing the control of operators) will dramatically go down. The reason is that operators won't be able to slash stakers and trustless delegation will be possible.” This was Justin’s response when he was asked if DVT is necessary for Ethereum, where he argues that it’s not needed in the long run thanks to one-shot signatures. The problem with one shot signatures is that they won't be ready for decades, and so DVT will be used in the short-medium term.

Roadmap to Deep Cryptography

Lots of this stuff is futuristic sci-fi and will take a loooong time to be implemented. Take one-shot signatures for example, which aren’t expected to be live for another decade or two!

Explore Delay-Encrypted Mempools

What a Mempool?

The mempool is where transactions are waiting so they can be confirmed and included in a block.

What’s an Encrypted Mempool?

Encrypted mempools take transactions from the mempool and encrypt them. This prevents (potentially) malicious actors from seeing the sender, receiver, the amount, etc, of a transaction before it is processed. This can reduce exploitative strategies such as frontrunning, as transactions cannot be selectively targeted based on their contents while pending in the mempool.

Ethereum has realized the potential benefits of encrypted mempools and wants to explore them. The ultimate goal is to actually use encrypted mempools to address MEV & censorship issues.

Types of Encryption

In-flight Encryption: Trust a third party with the private decryption key, promising not to reveal data until it’s committed on-chain. Used in Flashbots Protect for example.
Trusted Hardware Encryption: Use secure hardware to operate on plaintext within the hardware, keeping it private until after commitment.
Threshold Encryption/Decryption (TED): Requires a committee’s consensus to decrypt, enhancing security but with notable downsides, including lack of accountability and a strong honest majority assumption.
Delay Encryption/Decryption (DED): Encrypts information to automatically decrypt after a set period, relying on specialized hardware for implementation.
Witness Encryption/Decryption (WED): Allows decryption when a specific condition is met, an advanced concept that is many years away.

Benefits of Encrypted Mempools

Better mempool privacy
Better censorship properties
Reduced toxic MEV (frontrunning isn’t possible)

Related Research

Roadmap to Encrypted Mempools

Encrypted mempools are still in the research phase. There is lots of work to do surrounding encrypted mempools, and so I'd say we won't see these live for a few more years.

Manifold markets has a prediction market where you can bet on when you think encrypted mempools will be live on Ethereum - Manifold Markets.

36% of voters say encrypted mempools will be live by Jan 1st, 2026. 10% of voters say it will be by Jan 1st 2025.

VDFs

Verifiable Delay Functions (VDFs) can be used in Proof of Stake (PoS) networks to create randomness for selecting validators and committees. A VDF is a function that takes some time to compute but can be verified quickly.

Recent Problems

The cryptography research team of Ethereum recently announced that they found some weaknesses in existing constructions of VDFs. (ethresear.ch)

From the post:

“The team agrees that a better understanding of VDFs is essential if we are to continue down this design avenue. At present, the team does not recommend using VDFs within Ethereum. Ongoing research and substantial improvements are important factors in potentially revising our perspective on this topic in the future.”

Because of these discoveries the focus on VDFs has shrunk, which has been reflected in the Ethereum roadmap:

Current:

If you’re interested, you can find my previous writing on VDFs below (written before the emphasis on VDFs was shrunk).

VDFs

Verifiable Delay Functions (VDFs) are used in Proof of Stake (PoS) networks to create randomness for selecting validators and committees. A VDF is a function that takes some time to compute but can be verified quickly.

Ethereum’s idea is to use the best "proto-VDF" called the "iterated modular square root." It involves applying a function 'g' multiple times to a value 'x.' The computation cannot be parallelized since each step depends on the result of the previous one. The function 'g' has an inverse 'h,’ which can be computed much faster than 'g' itself. This property allows the VDF to be computed quickly in the backward direction but takes longer in the forward direction, making it easy to verify.

VDFs have several advantages in PoS networks:

They cannot be easily manipulated, relative to other random generation schemes like RANDAO.
They don't rely on a specific fraction of nodes being online or have a complicated setup procedure, unlike other schemes like BLS threshold signatures and similar VRFs.

However, there is a concern that a powerful actor might create specialized hardware (ASICs) to compute the VDF much faster than regular CPUs/GPUs. If this happens, there are two possible attacks:

Attack #1: The attacker can compute the VDF so quickly that they can predict its output before committing to a value, allowing them to choose a favorable outcome.
Attack #2: The attacker can suddenly go offline after the difficulty adjustment process has adapted to their presence, significantly slowing down the system.

To mitigate these attacks, the difficulty adjustment algorithm must be carefully designed. The timing parameters, such as 'N,' 'D,' and 'W,' play a crucial role. The attacker's advantage ('A') over the rest of the network determines which attack they can execute. To secure against the highest possible 'A,' the values of 'N,' 'D,' and 'W' need to be set such that 'N' is the geometric mean of 'D' and 'W.' This ensures resistance to an attacker's advantage up to the square root of 'W/D.'

Using a backstop mechanism where a committee can approve an easier VDF solution if it's not calculated by a certain time is problematic because the fastest VDF producer could manipulate the result by checking both fast and slow solutions and choosing the favorable one by going offline.

Overall, achieving full safety against attacker advantages higher than the square root of 'W/D' remains an open problem.

Read More: VDFs & Attacks

Explore Solutions for Dust Accounts

Ethereum’s gas fees are too high for any accounts with less than $10. These accounts may be able to interact with the Ethereum mainnet a few times at most before they run out of money to pay for gas fees. The alternative to mainnet for these accounts is to move their funds to a rollup, though this is impractical for an account with $10 or less. It is crucial for Ethereum's future, which is centered around rollups, to find a way onboard accounts of all sizes, no matter how small.

High Level Ideas From Vitalik:

Special-purpose multi-extraction with SNARKs.
Multi-extraction with Schnorr.
Force transfer into a minimal withdraw-only rollup.

Read More: Dust Solutions

Bonus Sections

Deneb/Cancun Hardfork
Prague/Electra Hardfork
Rollup Centric Roadmap (2024 Version)
ETH Economics

Deneb/Cancun (Dencun) Hardfork

Dencun went live on March 13th, 2024 and was the most recent Ethereum upgrade. There were 9 different EIPs included in the upgrade, here’s a list of them:

EIP-1153: Transient storage opcodes
EIP-4788: Beacon block root in the EVM
EIP-4844: Shard Blob Transactions
EIP-5656: MCOPY - Memory copying instruction
EIP-6780: SELFDESTRUCT only in same transaction
EIP-7044: Perpetually Valid Signed Voluntary Exits
EIP-7045: Increase Max Attestation Inclusion Slot
EIP-7514: Add Max Epoch Churn Limit
EIP-7516: BLOBBASEFEE opcode

If you want to dive deeper into Dencun, check out this awesome report put together by Tim Beiko. He goes over Dencun and each planned EIP in detail.

Prague Electra (Pectra) Hardfork

The Prague/Electra upgrade is the next scheduled hardfork in Ethereum, following the Deneb/Cancun hardfork. Pectra is planned to be a smaller fork that follows a bigger fork (EIP-4844), similar to how withdrawals (a smaller fork) followed the Merge (a big fork).

The Pectra upgrade is in the early stages, and so only a few EIPs have been formally committed to, including:

BLS12-381 precompile: Makes it so the Beacon chain and the Execution layer use the same elliptic curve, which will allow validators signatures to be verified by the execution layer. BLS can also be used for signature aggregation as it is very efficient. “Digital signatures in the blockchain world are usually based on elliptic curve groups. For signing users transactions, Ethereum uses ECDSA signatures with the secp256k1 elliptic curve. However, the beacon chain protocol uses BLS signatures with the BLS12-381 elliptic curve” - Eth2Book, Ben Edgington
EIP-7002: Adding EL Triggered Exits: This effectively allows a smart contract to initiate a withdrawal on the Beacon chain, which can be very valuable for LSTs. “We are further strengthening the links between the consensus layer and the DeFi layer” - David Hoffman.
EIP-6110: Supply Validator Deposits on Chain: Allows for an in-protocol mechanism of deposit processing on the Consensus Layer and eliminates the proposer voting mechanism utilized currently.
EIP-7549: Move Committee Index Outside Attestation: Aims to make Casper FFG clients more efficient by reducing the average number of pairings needed to verify consensus rules.
EIP-7251: Increase the MAX_EFFECTIVE_BALANCE, which allows validators to have larger balances.

This is a great visual from Tim Beiko covering the different Pectra proposals.

Recently, there has been a major uptick in discussion surrounding Pectra, with Lodestar, Prysm, Reth, Mike & Alex, & Lighthouse all putting out research pieces on what upgrades they think are best fit for inclusion.

Lots of the research overlaps in terms of what upgrades the different teams want to see included in the Prague/Electra. Here are some of the common upgrade recommendations:

EIP-7002: Adding EL triggered exits
EIP-7547: Inclusion Lists
EIP-4844: Increase the max blob count
EIP-7594: PeerDAS
EIP-6110: Supply validator deposits onchain.
EIP-7251: Increase the MAX_EFFECTIVE_BALANCE
EIP-7549: Move committee index outside attestation
Verkle Trees: Begin working on Verkle trees throughout 2024, and commit to implementing Verkle in Osaka, which is the hardfork following Prague/Electra.

Roadmap to Prague/Electra

Tough to say when exactly Pectra will go live. There seems to be a target of finishing it before the end of 2024. Keep your eye on Devcon (November 12th) as it could be ready for then.

Rollup Centric Roadmap (2024 Version)

Here's a digestible summary of the "Rollup-Centric Roadmap (2024 version)" by Mike Neuder and Alex Stokes:

Introduction and Background:

It’s been over three years since Vitalik proposed a rollup-centric roadmap for Ethereum.
Significant progress has happened since: this includes the beacon chain launch, the merge, withdrawals, and the upcoming proto-danksharding fork.
The article aims to update the roadmap, considering modern challenges and solutions.

Section 1: Ethereum's Recent History

Section 1 highlights major upgrades from December 2020 to 2024, including the Beacon chain genesis, Altair, Bellatrix/Paris (the merge), Capella/Shanghai (withdrawals), and the upcoming Deneb/Cancun (proto-danksharding).
These upgrades are steps towards the rollup-centric vision, focusing on Proof-of-Stake and scaling.

Section 2: Ethereum in 2024 (The Current State)

Section 2 discusses the ecosystem's growth and the noise surrounding it, focusing on three key areas: scaling, MEV (Miner Extractable Value), and staking.
They present pivotal questions in each area, highlighting the need for critical reflection on Ethereum's direction.

Section 3: Ethereum's Strengths

Section 3 emphasizes Ethereum's core values such as decentralization, censorship resistance, credible neutrality, permissionlessness, trustlessness, and the importance of the community and ether as an asset.
They assert that these values make Ethereum exceptional and unique.

Section 4: What Ethereum is Not Aiming For

Section 4 clarifies non-goals, including not aiming to be the most hospitable L1 for execution, not striving to provide the cheapest data availability (DA) layer, and not operating like a startup.
They suggest focusing on Ethereum's core strengths rather than diluting its vision.

Section 5: The Future Roadmap

Short-Term (Prague/Electra Fork, end of 2024): Section 5 proposes adjustments for scaling, addressing MEV centralization, and improving staking UX.

Medium-Term (Next 3-4 Years): Outlines ambitious scaling goals, R&D to address MEV, and measures to protect solo stakers and tackle stake centralization.

Conclusion:

They conclude by stressing the importance of the Ethereum community in driving forward the project's vision.
They encourage focusing on openness, inclusivity, and alignment to ensure Ethereum's continued success.

Economics of ETH

Ansgar Dietrichs & Casparschwa have written extensively about Ethereum’s issuance policy, the drawbacks to it, and their endgame vision for Ethereum’s staking economics.

Endgame Staking Economics Research

Counter-Arguments:

Artem's Counter

Security Budget

Ethereum’s security budget is the sum of all the rewards allocated to validators for securing the network. This includes new ETH issuance and transaction/MEV fees. A network with a large security budget like Ethereum’s means a lot of resources go towards network security, which deters attacks as they cost too much.

Following the merge, the security budget (new issuance) of ETH was reduced by 90% overnight, which is just insane.

Numbers Today (March 5 ‘24) vs Numbers Since Merge (Sept 15 ‘22):

PoS Issuance: -402,940 ETH
PoW Issuance: +5,509,526 ETH
ETH Difference: 5,912,466 ETH
Dollar Difference: $21,533,201,172

source

21 billion dollars is serious money! Makes you think…

What would the price of ETH be if it was still under a PoW system? What would ETHBTC look like?
How does Ethereum’s $21 billion issuance reduction compare to traditional financial metrics/events, such as QE or currency devaluation? What lessons/parallels can be drawn?
How does Ethereum’s economic setup compare to the Bitcoin halving event? Are there parallels in terms of price action/investor interest/media coverage?
How important is this issuance reduction in the eyes of institutional investors and big financial institutions? How important is it for retail investors? Is there evidence that the supply reduction has altered investment strategies or attracted new types of investors?
How much bigger will this issuance gap get in a bull market? What factors could affect the issuance gap and do they increase or decrease the gap?

Imagine an asset losing 50%+ of its users, 50%+ of its activity, dropping 80%+ in price, and then turning profitable after the fact (this was what Ethereum did in Sept 2022 following the Merge). Now imagine on top of that, the asset deflates at .3%/year and pays you 5%/year to own it. Oh yeah, this asset is also in the fastest growing industry in the world outside of AI (crypto), and is in the largest TAM sector of its industry (L1s).

And you're bearish anon?

Acronym Glossary (A-Z)

A

AA: Account Abstraction
API: Application Programming Interface
APS: Attester Proposer Separation
ASIC: Application Specific Integrated Circuit

B

BFT: Byzantine Fault Tolerance

C

Casper FFG: Friendly Finality Gadget
CDK: Chain Development Kit
CPU: Central Processing Unit
crList: Censorship Resistance List

D

DA: Data Availability
DAO: Decentralized Autonomous Organization
DApp: Decentralized Application
DAS: Data Availability Sampling
DED: Delay Encryption/Decryption
DeFi: Decentralized Finance
DKG: Distributed Key Generation
DoS: Denial of Service
DVT: Distributed Validator Technology

E

ECC: Elliptic-Curve Cryptography
ECDSA: Elliptic Curve Digital Signature Algorithm
EF: Ethereum Foundation
EIP: Ethereum Improvement Proposal
EL: Execution Layer (or EigenLayer, depends on context)
EOA: Externally Owned Account
EOF: EVM Object Format
ePBS: Enshrined proposer-builder separation
ERC: Ethereum Request for Comment
ESG: Environmental-Social-Governance
EVM: Ethereum Virtual Machine
EVMMAX: Ethereum Virtual Machine Modular Arithmetic Extensions

F

FaaS: Front-Running as a Service
FHE: Fully Homomorphic Encryption
FSS: Fair Sequencing Service

G

GPU: Graphical Processing Unit

H

H/T: Hat Tip

I

IL: Inclusion List
IP: Internet Protocol
IPFS: Interplanetary File System
ISP: Internet Service Provider

K

KB: Kilobyte
KYC: Know Your Customer
KZG commitment: Kate-Zaverucha-Groth commitment

L

LMD-GHOST: Last Message Driven Greediest Heaviest-Observed Sub-Tree
L1: Layer 1
L2: Layer 2
LST: Liquid Staking Token

M

MaxEB: Maximum Effective Balance
MB: Megabyte
MEV: Miner Extractable Value
MEVA: MEV Auction
MPC: Multi Party Computation

N

NFT: Non-Fungible Token

P

PBS: Proposer-Builder Separation
PEPC: Protocol-Enforced Proposer Commitments
PoC: Proof of Custody
PoS: Proof of Stake
PoW: Proof of Work
PROF: Protected Order-Flow
PTC: Payload-Timeliness Committee
p2p: Peer to Peer

Q

QE: Quantitative Easing

R

RaaS: Rollup-as-a-Service
R&D: Research & Development
RIP: Rollup Improvement Proposal
RLMD-GHOST: Recent Latest Message Driven Greediest Heaviest-Observed Sub-Tree

S

SDK: Software Development Kit
SNARK: Succinct Non-Interactive Argument of Knowledge
SnSLE: Secret non-Single Leader Election
SoV: Store of Value
SSD: Solid State Drives
SSF: Single Slot Finality
SSLE: Secret Single Leader Election
SSZ: Simple Serialize
STARK: Scalable Transparent Argument of Knowledge
SUAVE: Single Unifying Auction for Value Expression

T

TAM: Total Addressable Market
TBA: To Be Announced
TED: Threshold Encryption/Decryption
TSS: Threshold Signature Scheme
TVL: Total Value Locked
Tx: Transaction

U

UX: User Experience
UI: User Interface

V

VDF: Verifiable Delay Function
ZK: Zero Knowledge
VM: Virtual Machine

W

WED: Witness Encryption/Decryption

Z

zkEVM: Zero Knowledge Ethereum Virtual Machine
ZKP: Zero Knowledge Proof

Herc’s Newsletter

Discussion about this post

Herc’s Newsletter

The Ethereum Roadmap

The Merge, the Surge, the Scourge, the Verge, the Purge, and the Splurge

Table Of Contents:

Section 1: The Merge

Section 2: The Surge

Section 3: The Scourge

MEV Track (Endgame Block Production Pipeline):

MEV-track Miscellaneous:

Staking Economics/Experience Track:

Section 4: The Verge

Section 5: The Purge

Section 6: The Splurge

Bonus

Introduction

Getting Back on Track; Ethereum

Roadmap Overview

The former roadmap, presented by Vitalik in 2022:

And the current roadmap:

The Merge: Full Transition to Proof of Stake

What’s Been Implemented?

What’s Left To Implement?

The Merge

What is Proof of Stake?

Carrots & Sticks

Benefits of Proof of Stake?

Diving Deeper:

Benefit #1 - Security: “Proof of Stake offers more security for the same cost.”

Benefit #2 - Attacks: “Attacks are much easier to recover from in Proof of Stake.”

Why is That?

The Same Attack on Ethereum (PoS):

Benefit #3 - Decentralization: “Proof of Stake is more decentralized than ASICs.”

Enter: Staking Providers

Here’s a view of Ethereum’s staking services and their market shares:

And a view of Bitcoins mining pools & their market shares:

What are the Problems with Large LSTs?

Benefit #4 - Energy Expenditure: “The Merge has had huge implications on Ethereum’s energy expenditure and its carbon footprint.”

Look at the drop off in this chart!

& here are the consumption numbers over the past 3 months:

Ethereum’s energy consumption went from averaging above 75 TWh/year to below .01 TWh/year!

Drawbacks to Proof of Stake

Drawback #1 - Less Established History: “Proof of Stake is less battle tested compared to Proof of Work.”

Counter-Argument

Now, is PoW more battle tested because:

Yeah, point taken.

No, not even close.

Drawback #2 - Harder to Implement: “Proof of Stake will never actually be implemented on Ethereum successfully.”

Drawback #3 - More Complex: “PoS is more complex to run than PoW.”

Drawback #4 - Higher Setup Cost: “It’s cheaper to become a miner on PoW than to become a staker on PoS.”

Withdrawals

What is the Shanghai/Capella Upgrade?

Distributed Validators (DVT)

Motivation

Mental Models

Risks to Staking

How Does DVT Work?

Benefits of DVT

Projects Implementing DVT

Future of DVT

One-Shot Signatures

Benefits of One-Shot Signatures

Justin also talked about what one shot signatures can unlock:

Closing Thoughts

Single Slot Finality (SSF)

Motivation

What’s a Slot?

What’s a Reorg?

Benefits of SSF

Relevant Research/Proposals

1.) Developing the Exact Consensus Algorithm

2.) Determining the Optimal Aggregation Strategy

Signature Aggregation Proposals

3.) Determining the Validator Economics

Some Positives

Suggestion #1: Super Committees

Drawbacks to Super Committees

Suggestion #2(a): Capping the Validator Set

Suggestion #2(b): Capping the ETH Deposited

Strengths

Drawbacks