Understanding the Ethereum Development Roadmap

Ethereum developers successfully shipped The Merge on September 15, 2022. Outside observers may consider The Merge a sort of “final destination” for the network. However, members of the Ethereum community understand The Merge as more of an “end to the beginning”.

Future web3 users will likely reflect on this time as Ethereum’s most active development period. The development team, fully committed to achieving a highly scalable, highly decentralized, Ethereum of the future, must harmoniously execute a set of interdependent paths.

In recent years, Ethereum co-founder Vitalik Buterin has made a concerted effort to educate the broader web3 community about the roadmap by publishing transparent visuals outlining the protocol’s development path. Vitalik posted the first visual roadmap to Twitter in March 2020. Ethereum foundation researcher Domothy maintains an annotated guide with links to the most updated research (this can be found here). This was a major resource in the development of this guide.

This most recent visual roadmap was shared on November 4, 2022:

The key difference between the newest version and the version shared the year before (December of 2021) is the addition of “The Scourge”, focusing on solving MEV.

The visual Ethereum roadmap brought increased attention to development progress and the opportunity for Vitalik to address questions regarding milestones. During EthCC 5 in July 2022, Buterin said that The Merge would mark a 55% completion in Ethereum's slated development work. In January of 2022, he underscored the rapid pace of roadmap progress on Bankless saying, “I’d say we’re around 50[%]. I’d be willing to go past 60 once The Merge is fully complete. And I’d be willing to go past 80 once we have a full sharding implementation.”

Analyzing the roadmap allows web3 users to understand how and why the community prioritizes upgrades.

The stages of the roadmap are not consecutive (as Vitalik has humorously clarified in the past). They are development paths that are happening in parallel. 

In this post, we will examine each stage of the Ethereum roadmap, the major features, and how you can track progress toward completion.

The Merge

Goal: Have an ideal, simple, robust and decentralized proof-of-stake consensus.

Why it Matters: Much of the technical infrastructure within other sections of the Ethereum roadmap hinges on the change to PoS (Proof-of-Stake) consensus. Additionally, The Merge significantly reduced the network’s energy consumption.

Timeline: Underway. The Merge to PoS occurred last September. All other Merge roadmap items await official completion dates. (Next, Ethereum’s Shanghai upgrade, will enable PoS withdrawals). 

Overview

If you’re asking, “isn’t the Merge complete”? you aren’t alone. A point of clarification about The Merge: This phase of the roadmap is still very much in motion. 

The Merge event on September 15, 2022, marked the integration of Ethereum's mainnet and Beacon Chain under a new consensus mechanism, decommissioning Proof-of-Work and enabling Proof-of-Stake. With that successfully completed, developers moved to tackling the remaining upgrades for The Merge such as enabling withdrawal functionality for Ethereum stakers.

The Merge itself did not make Ethereum faster in terms of transactions per second (TPS) – although a TPS of 100,000 is the ultimate goal for the network (Ethereum’s current TPS tends to vary between 10-25 TPS). Instead, it rendered Ethereum mining obsolete and helped retain value within the network. A happy side effect of the change to PoS: a ~99.95% reduction in  the network's energy consumption.

The Merge also laid the foundation for future improvements to the network. PoS enables scaling efforts because it is necessary for the proposer/builder separation that facilitates danksharding, and other mechanisms critical to network speed, in subsequent upgrades. 

Continuing Development of The Merge

• Withdrawals: An upgrade known as Shanghai, scheduled for March/April 2023, will facilitate Ethereum withdrawals for stakers via EIP-4895. For further insight into the technical progression of this upgrade, we recommend the Shanghai Network Specification GitHub page and our guide to staked ETH withdrawals.
• Distributed validators: “Multisig for staking” would increase validator diversity by allowing users with less than 32 ETH to pool their funds and trustlessly operate a shared validator. This would mean multiple, independent individuals can operate as a validator.
• View merge: This would represent a tweak to the way that validators vote thereby protecting specific classes of voting attacks from potentially malicious validators. More information can be found via this ethresear.ch post.
• Improved aggregation: The network currently necessitates all validators to vote on every block (and verify every other validator’s vote), a bandwidth-intensive requirement. Aggregation of the BLS signatures (Boneh–Lynn–Shacham cryptographic signature schemes) used for voting improves efficiency and lowers the requirements for operating a validator, allowing the network to support even more validators. 
• Single slot finality (SSF): Currently, Ethereum’s Beacon Chain finalizes every two epochs (every 12.8 minutes). Waiting over 10 minutes for true finality leaves the door open for certain types of chain reorgs and attack opportunities. Ideally, the Ethereum development team  wants the chain to finalize after every slot (every 12 seconds). Read more about research on the paths to single slot finality, including the questions of SSF consensus algorithms and SSF validator economics (there may be a need to limit the number of overall validators on the network), here.
• Secret leader election: At the start of every epoch, the network identifies specific, block-proposing validators for each slot creating attack vectors for malicious actors to target upcoming proposers. Eliminating public visibility into block proposers strengthens Ethereum consensus. 
• Quantum-safe aggregation-friendly signatures: Currently Ethereum utilizes BLS signature scheme cryptography to allow validators to sign messages. If left unchanged, quantum computers will break this cryptography. The network must therefore plan for an alternative,quantum-proof cryptographic signature scheme. 

The Surge

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

Why it Matters: The inability to scale to a large number of transactions contains the UX of current blockchains. Transaction fee spikes plague the network when increased users execute transactions. Enabling 100k TPS would ensure that Ethereum can grow to serve a broad, worldwide user base. 

Timeline: Vitalik stated his 2023 goal is to roll out EIP-4844 (Proto-Danksharding) and begin removing the “training wheels” needed for rollups. No official dates regarding the implementation of other development paths within The Surge currently exist. 

Overview

“The Surge” contains development paths that will unlock higher transaction throughput throughout the network. This will be done via the implementation of new scaling technology that is commonly used across high-tech industries. NASA uses data sharding techniques, for example, to transmit information over long distances with limited bandwidth. 

Sharding and data availability sampling (DAS) are the most important features of The Surge. They allow rollups to seamlessly integrate with the main Ethereum chain, expanding transaction throughput on the network overall while failing to compromise the security of robust Ethereum validator decentralization. Developers currently look to danksharding (DS) for tackling these improvements in practice.

Dankrad Feist, an Ethereum researcher, software developer, and core contributor conceived the “danksharding” concept, a combined fee market in which one proposer decides all transactions and data for each individual slot rather than a set number of shards with separate blocks and proposers. 

The proposer will be a committee of validators chosen randomly to perform data availability sampling on blockchain data. Such a system maintains data availability in a decentralized manner, currently impossible with single validation. Consensus nodes will likewise perform data availability sampling, thereby unifying the network's consensus, settlement, and data availability layers.

Each shard chain on the network will have its own state and validator set. However, instituting full Danksharding is complex, so the developmental process will follow the incremental steps outlined below.

Continuing Development of The Surge

• EIP-4844 implementation: EIP-4844 implements “proto-danksharding,” which will allow “blobs” of data to be persisted in the beacon node for a short period of time. This stepping stone to full danksharding initiates the process of lowering fees for rollups by orders of magnitude. The following Twitter thread outlines the EIP-4844 implementation timeline.
• Basic rollup scaling: EIP-4844 will allow rollups to make significant progress on  scaling efforts. It significantly improves data availability, a main cost for rollups at the moment. Rollup scaling also entails moving to more decentralized controls of rollup smart contracts. Currently, the risk of hacks and bugs requires centralized control of rollups. Finding a balance between security and the progressive decentralization of L2s is crucial. Vitalik outlines “basic rollup scaling” as his most important 2023 milestone.
• P2P design for DAS: Required research into the networking for data sharding.
• DA sampling clients: Developing clients that can determine data availability based on a sampling of only a few kilobytes.
• Efficient DA self-healing: Currently Ethereum uses BLS signature scheme cryptography to allow validators to sign messages. The development of quantum computers will break this cryptography necessitating an alternative, quantum-proof method for the protocol. 
• Full rollup scaling: This entails fully removing the “training wheels” in place for rollups. In this post, Vitalik outlines the criteria for determining what this will look like.
• Quantum-safe and trusted-setup-free commitments: Ethereum is planning to utilize the polynomial commitment scheme KZG in the implementation of proto-dranksharding. To reach the long-term goal of a fully quantum-proof Ethereum, researchers will need to find a solution to replace KZG, which does not guard the network against quantum attacks.
• Optimistic rollup fraud provers & ZK-EVMs: This achieves the goal of enshrined rollups. As Justin Drake explains in this post, an enshrined rollup enjoys some sort of consensus integration with the L1. 

The Scourge

Goal: Ensure reliable and credibly neutral transaction inclusion and avoid centralization and other protocol risks from MEV.

Why it Matters: Capturing MEV (Maximal Extractable Value) creates a centralizing force for block construction and validation due to the sophisticated nature of the task. The Merge’s introduction of proto-PBS, separating the builder role from the proposer role, addressed this risk but also introduced the ability for network actors to censor or filter transactions during the block construction and proposal process. Tackling these interrelated problems will ensure that Ethereum maintains its decentralization and censorship resistance principles. 

Timeline: Pending.

Overview

The Scourge, the newest addition to the Ethereum roadmap, aims to ensure reliable, fair, and credibly neutral transaction inclusion, and mitigate risks from MEV.

MEV, one of the most misunderstood concepts in web3, has layers of complexity, involves a variety of actors, and presents in different defined and yet-to-be-defined ways. Read our complete guide to MEV for a comprehensive breakdown of the topic.

Technically, MEV extraction arises from the sequential manner in which Ethereum and most blockchains operate. Network actors extract MEV by controlling inclusion and ordering of a blockchain’s transactions. 

Anyone monitoring the Ethereum network can preview pending transactions by watching the mempool. They with means and ability can capitalize on this information by executing sophisticated transaction methodologies that allow them to “extract” value dependent on these transactions. 

Users that look for and execute MEV opportunities are referred to as searchers. When they find lucrative transactions, they send custom transaction bundles to “block builders,” who structure bundles alongside standard transactions and relay them to Ethereum validators for inclusion via MEV-Boost, a protocol sidecar.

Proto-PBS (proposer/builder separation) currently facilitates MEV processing on Ethereum. Proposer/builder separation, achieved by The Merge, separates the act of proposing blocks for inclusion on the chain (done by validators) from the job of constructing blocks for inclusion (done by block builders). Separating these two roles helps mitigate the centralizing effects of MEV. Vitalik explains the logic of abstracting the prosper role as follows:

In the current transaction market, the block proposer (today: a miner, post-merge: a validator) directly chooses which transactions to include in the next block by looking at which transactions in the mempool pay the highest priority fee. This puts the block proposer in a position to use sophisticated strategies to choose which transactions to include, or even include their own, to take advantage of opportunities such as DEX arbitrage and liquidations (hereinafter just called “MEV” for simplicity) to maximize their profits. The complexity of these strategies creates a high fixed cost in running an effective miner or validator, and advantages centralized pools that take on this task on behalf of their participants.

Proposer/builder separation (PBS) fixes this by splitting the block construction role from the block proposal role. A separate class of actors called builders build exec block bodies (essentially an ordered list of transactions that becomes the main “payload” of the block), and submit bids.

Successful PBS implementation need not only consider the centralizing impact of MEV but also the impact of censorship on the network— and how to mitigate it. Sanctions against Tornado Cash in the summer of 2022 caused many Ethereum block builders and relays to filter transactions out of caution. Currently, certain MEV relay providers (Blocknative included) do not include blocks containing OFAC-sanctioned transactions. 

With this in mind, The Scourge’s development path is all about finding the most optimal way to implement PBS on the Ethereum network in a way that encourages economically fair and censorship-resistant transactions.

Continuing Development of The Scourge

• Inclusion lists or alternative: Inclusion lists would allow validators to check the blocks that builders deliver to them against an expected list of transactions. If the blocks fail to include those transactions, the validator could then reject the block. Inclusion lists promise to combat any block builders’ failure to include specific transactions. Further reading can be found on ethereum.org and ethresear.ch. 
• In-protocol PBS spec: The maintenance and availability of inclusion lists needs addressing following the identification and availability of a solution.  This will enable Ethereum to move beyond proto-PBS (dependent on validator’s utilizing the optional MEV-Boost sidecar) to in-protocol PBS. 
• Application layer MEV minimization: Ordered systems naturally create an opportunity for arbitrage; in the case of Ethereum, MEV. Abuse of MEV harms network users. Several projects, such as CowSwap and Arbitrum, actively try to reduce harmful MEV at the application layer. Innovations made possible by this live experimentation will ideally lead to industry standards amongst dapp developers seeking to protect users from malicious MEV.
• MEV burn: The Ethereum development community is reviewing options regarding the “burning” or “smoothing” of MEV. This would involve novel protocol-level rules that eliminate the variability in block rewards caused by the inclusion of MEV. Doing so would lead to more equitable block rewards, reducing the potential for validator centralization.
• Distributed builder track: The Ethereum Merge introduced “block builders” and proto-PBS to minimize the compute overhead for validators. However, while this system architecture minimizes the centralization of validators, it centralizes the role of block building. Finding a way to incentivize the decentralization of builders at the protocol level would significantly strengthen Ethereum. Vitalik presented the potential for decentralized block builders. The MEV research collective Flashbots proposed an alternative solution: creating an independent network known as SUAVE (Single Unifying Auction for Value Expression) to tackle the problem. Several development threads fall under the umbrella of distributed building including:
• Blob construction: Data size continues to plague blockchain decentralization efforts. Innovations in data blob construction can alleviate the high bandwidth and processing requirements that currently inflate the hardware needed to compete as a block builder.
• Pre-confirmation services: Innovations in the role of block building could open the door for distributed block builders offering pre-confirmation services to network users. This could greatly increase the adoption of Ethereum,as transaction confirmation times bottleneck user experience. While this would be a major innovation, developers have yet to confirm the possibility of in-protocol pre-confirmations.
• Frontrunning protection: Ensuring the protection of users from front-running, a particularly harmful MEV variant, would bolster credible neutrality of distributed block building. Researchers will need to work to prove the feasibility of in-protocol frontrunning protection.

The Verge

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

Why it Matters: Network validators verify blocks. Complexity and resource intensity limit the number of entities willing to perform validation duties. On the other hand, making the process super easy opens the door to a wider variety of network participants to operate validators, increasing network decentralization and health.

Timeline: Pending.

Overview

The Verge promises to eliminate the need for network validating nodes to have a copy of Ethereum's entire history of transactions. Currently, network validators must maintain a full node, a cumbersome requirement from time and storage perspectives. New full nodes take roughly 24 - 48 hours to sync; and you need roughly 2 TB of dedicated storage for a full node.

As Ethereum grows, so do storage and data processing requirements. Ethereum’s database includes all smart contract deployments, externally-owned accounts (and their balances), and associated storage. The network grows exponentially as more users join the network and more developers deploy new contracts. The Verge will make “light clients” more viable, helping account for growth and encouraging new network participants. These light clients will use zero-knowledge technology such as zkSNARKs and zkSTARKs to deliver the same security as full nodes.

SNARKs and STARKs deserve dedicated attention and study but, for the sake of this roadmap discussion, you simply need to know: These cutting-edge cryptographic techniques will allow Ethereum to deliver the same robust level of security it currently has while using a fraction of the current computational power.

Currently, the network uses a Merkle-Patricia Tree to hash and compress Ethereum state data. Nodes must store this state to validate blocks and ensure the network correctly transitions between states.  Merkle trees, a staple of blockchains (they are used by Bitcoin as well), have become inefficient at scale. Verkle trees, invented in 2018 , offer a  far more efficient method of data storage—due to the proof size— thanks to the use of vector commitments. 

In addition to fully adopting SNARKs and STARKs, The Verge will upgrade the current Merkle tree structure to Verkle trees. By deploying the latest cryptographic technology, The Verge will provide a more efficient structure for storing the Ethereum state, strengthening the network’s decentralization by opening the door for new participants. 

Continuing Development of The Verge

• Verkle tree spec + impl: Finalizing design decisions for Verkle trees operation and implementation within the protocol. Read more here about the incorporation of this development into the Ethereum upgrade process.
• Code chunking + gas cost updates:Verkle trees would cause backward compatibility issues because the new (lower) gas costs for a code chunk—in Ethereum, a contiguous 31-byte code segment— would impact the economic viability of some applications. Adjusting gas limits can mitigate this.
• Transition spec + impl: Core devs will need to determine the exact process for safely completing the transition from the current Merkle tree process to fully functional Verkle trees.
• Verkle trees: Once Verkle trees replace Merkle trees, their smaller proof size  will potentially facilitate the proliferation of stateless clients. Validators will be able to rely on block builders to provide Verkle proofs regarding the state of certain blocks and verify these lightweight proofs instead of maintaining Ethereum’s state directly.
• SNARK / STARK ASICs: ASIC stands for “application-specific integrated circuit,” a piece of hardware suitable for a single computational task (to be) engineered expressly for calculating ZK-proofs. Vitalik explains here that the computational intensiveness of many parts of the Ethereum protocol will require this designated hardware. 
• SNARK-based light clients: The sync committee structure used by Ethereum’s PoS Beacon Chain supports basic light clients. Sync committees, groups of 512 validators randomly assigned and chosen every 256 epochs, continually sign block headers, which represent accurate and validated blocks, for each new slot in the Beacon Chain. Ethereum will need to SNARK-ify the sync committee transition process so that there is no delay in clients being able to confirm which validators form the current Beacon Chain sync committee.
• SNARK for L1 EVM: SNARKs should integrate within ETH’s L1 directly by leveraging The Surge’s ZK-EVMs development. Upgrading the settlement layer to an enshrined zkEVM rollup would enable a single succinct ZKP to verify the entire Ethereum ecosystem—potentially thousands of rollups/volitions and millions of TPS. Hallelujah. You can learn more about this technical process here.
• SNARK for Verkle proofs: Reducing Verkle proofs to a single SNARK deepens efficiencies captured by the use of Verkle trees.
• SNARK for consensus state transition: This replaces sync committees with SNARKs for trustless verification of all consensus layer activities.
• Fully SNARKed Ethereum: The endgame of The Verge entails completing all the SNARK-related development paths above. A fully SNARKed Ethereum paves the way to the Ethereum endgame of extremely efficient and trustless block verification.
• Increase L1 gas limits: A fully SNARKed Ethereum L1 will facilitate increased gas limits without burdening validators with consequently larger block sizes. Bigger blocks at the L1 level will in turn benefit further L2 scaling.
• Move to quantum-safe SNARKs (eg. STARKs): Quantum computers can break SNARK cryptography so, in alignment with the goal quantum-proofing, Ethereum developers need a plan to accomplish this. This development step seeks to achieve quantum-safe SNARKs; learn more about the differences between these two zero-knowledge proofs via this Consensys article.

The Purge

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

Why it Matters: The Purge seeks to future-proof the protocol with streamlined data storage, while simultaneously addressing early design decisions made due to technology limitations at the time. 

Timeline: Pending.

Overview

The Purge aims to reduce historical data storage by introducing history expiration (EIP-4444). This will require nodes to stop serving historical blocks older than a year, giving nodes the option to locally prune historical blocks.

Historical data will only be necessary when explicitly requested or when a peer requires synchronization with the head of the chain. A fully synchronized node will no longer need historical data older than 365 days to confirm new blocks 

This enables new syncing mechanisms that the community can implement after EIP-4444. Checkpoint sync, for example, lets the chain sync only from a recently finalized checkpoint block rather than from the genesis block. 

This upgrade promises remarkable efficiency gains. That said, without putting in place certain provisions to index historical data, data purging could impact the functionality of some Ethereum-based applications. Developers will likely look to network actors, such as indexing providers or block explorers, to build decentralized sources of this data outside the main protocol. 

The Purge will also contain development threads related to simplifying the Ethereum Virtual Machine (EVM) and state expiry. History expiry entails pruning the long-term transaction data of Ethereum. State expiry reduces or eliminates the need for Ethereum clients to store the latest state of all current Ethereum data.

Continuing Development of The Purge

• Alternative history access (eg. Portal): Create an alternative access point for historical headers, bodies, and receipts older than one year to accommodate the EIP-4444 requirement for clients to stop serving this data.
• EIP-4444 implementation: The Ethereum Foundations outlined specifications for EIP-4444 but continue to research implementation methodologies.  This lightclients Twitter thread offers critical insight into the questions that need answering. 
• History expiry (EIP-4444): History expiry will go live following implementation research, allowing lightweight Ethereum nodes to flourish. The core protocol would only need to manage up to one year’s worth of historical blocks rather than having to download and serve the full chain from genesis. For further reading, we recommend Vitalik’s AMA on history expiration.  
• EVM simplification track: Three technical threads tying the Purge’s upgrades into The Verge’s implementation of Verkle trees to streamline the execution of Ethereum’s transactions. These threads entail:
• Ban SELFDESTRUCT: SELFDESTRUCT is an opcode introduced early in Ethereum’s history. Vitalik conceived of this function, allowing the destruction of any created object, to help prevent bloating the long-term chain state. Changes to the protocol have since rendered this feature, well-intentioned at conception, obsolete (at best). SELFDESTRUCT now presents a problem to the ecosystem as it conflicts with and renders impossible certain upgrade implementations. Explore EIP-4758 and EIP-4760 which offer two potential paths toward the replacement of SELFDESTRUCT. 
• Simplify gas mechanics: Vitalik’s“EVM features potentially worth removing” post outlines proposed gas-related changes, including the 2300 gas stipend, gas visibility, and gas refunds. The development team has yet to solidify any specific changes.
• Precompiles -> EVM impls: This promises to replace precompiled contracts with direct EVM implementations. 
• Base state expiry spec: The Ethereum community will need to settle on exactly how to complete state expiry in order to accomplish this goal. Vitalik published a potential roadmap as well as options that include weak statelessness instead of pure state expiry. Once a decision is reached, the development team will need to complete state expiry implementation. 
• Address space extension: Certain state expiry schemes argue in favor of increasing the standard size for Ethereum addresses from 20 bytes to 32 bytes, in part to address overall security. Developers will need to find a way to make older 20-byte addresses backward compatible.
• Application analysis: State expiry will inevitably break certain existing applications on the network. Research into what will break and how will enable the community to rally around upgrading infrastructure for a stateless Ethereum.
• State expiry: After the development threads related to state expiry are completed, validators and nodes will be able to operate without storing any state (or at least storing an amount of state that stays constant instead of growing over time). To learn more, read Vitalik’s AMA on state expiry.
• LOG reform: Network developers need to simplify event logs to allow the efficient retrieval of historical events. 
• Remove old tx types: Certain old transaction types increase code complexity for Ethereum clients. Removing support for these transactions increases efficiency but could cause backwards compatibility issues, necessitating further research.
• Serialization harmonization: Currently serializing objects on Ethereum uses two different types of encoding methods. The execution layer uses recursive-length prefix (RLP) serialization, while the Beacon Chain uses simple serialize (SSZ). The Purge aims to end the usage of RLP in favor of SSZ on all aspects of the protocol. 

The Splurge

Goal: Fix everything else.

Why it Matters: The other five roadmap categories cannot neatly encompass many planned development threads. The Splurge serves as a catchall for these remaining activities.

Timeline: Ethereum’s Cancun update is on track to implement five EOF-related EIPs. All other Splurge roadmap items are pending official completion dates.

Overview

The Ethereum protocol’s complexity as well as unknown unknowns necessitate the need for The Splurge. 

This path on the road to Ethereum’s Endgame serves as a reminder that the visual roadmap is simply a guide to important questions, research, and development requirements. The Splurge’s tongue-in-cheek goal of “fix everything else” makes light of the need to create categorization logic around roadmap developments rather than the work around the development itself. 

The Splurge contains some “nice to have” developments as well as some of the most interesting advancements in the ecosystem, such as account abstraction (ERC-4337).  

Continuing Development of The Splurge

• EVM improvements track: The improvements below, when combined with The Purge’s EVM simplification track, lead to the Endgame EVM:
• EOF: EVM Object Format (EOF) represents the first upgrade in the EVM’s history. This suite of 5 EIPs combines to make EVM execution more efficient, consistent, and easily upgradeable. You can keep track of technical details and progress via Ethereum.org.
• Big modular arithmetic: Bringing the modular arithmetic of cryptographic upgrades directly in the EVM will improve the efficiency of the protocol.
• Further EVM improvements: This could include new EVM upgrade proposals or the removal of unneeded features as proposed by Vitalik here.
• Account abstraction track: This upgrade will have huge ripple effects for Ethereum UX, making features like social recovery and advanced hardware integration possible by simplifying Ethereum accounts. ​​Currently, accounts can be either Externally Owned Accounts (EOAs), controlled by a non-EVM entity (usually a person), or Contract Accounts (CAs), controlled by its smart contract code. Account abstraction  makes accounts CAs, which can define their own valid transactions. According to Vitalik’s account abstraction roadmap this “allows many important security benefits, such as multisig and smart recovery wallets, being able to change keys without changing wallets, and quantum-safety.”
• ERC-4337 rollout: To make ERC-4337 a success, resources will need to devoted to the development of smart contract wallets capable of achieving broad adoption. Currently, Ethereum’s wallet infrastructure uses the EOA standard. Wallet developers will need to pivot. 
• Voluntary EOA conversion: This involves allowing a normal account to irreversibly add code converting it to a contract, namely a 4337-compliant smart wallet. Vitalik outlines here how this relates to EIPs 3074 and 5003. 
• In-protocol enshrining: After facilitating the conversion of EOA accounts, Endgame account abstraction must require that these conversions take place.
• Endgame EIP-1559: EIP-1559 made Ethereum’s fee market more dynamic. The endgame of this development thread is to make EIP-1559 “multidimensional”, with a time-aware fee calculation, similar to an AMM curve. 
• Verifiable delay function spec: VDFs enable the necessary entropy for validator and committee selection under PoS. Core devs need to research the exact specifications for Ethereum as well as specific VDF hardware requirements.

Build Ethereum With Blocknative

In the past, Blocknative helped the community adapt to upgrades such as EIP-1559 and the proto-PBS ecosystem put in place by The Merge. We look forward to continuing to support the Ethereum development process.

Moving forward, we plan to directly support account abstraction initiatives and Ethereum gas-related development threads such as Endgame EIP-1559. We also plan on contributing to The Scourge by sharing our experiences as a block builder and MEV relay provider. If you are interested in working with our team to help continue to move Ethereum forward, please reach out via our site contact form or by joining our Discord.