Research Summary
The report discusses the evolution of Ethereum’s philosophy, the debate between Layer 1 and Layer 2 functionalities, and the potential enshrinement of more features into the core Ethereum protocol. It explores the concept of account abstraction, the challenges it presents, and the potential benefits of incorporating ERC-4337 features into the protocol. The report also delves into potential features for enshrinement, including ZK-EVMs, proposer-builder separation, private mempools, liquid staking, and new precompiles. It concludes with a discussion on the tradeoffs between enshrining features and leaving them to other layers of the ecosystem.
Key Takeaways
Ethereum’s Evolution and the Layer 1 vs Layer 2 Debate
- Ethereum’s original philosophy: The report highlights that Ethereum was designed to keep the core protocol simple, with most functionalities built on top. The ongoing debate between focusing on Layer 1 (L1) versus Layer 2 (L2) functionalities is not just about scaling, but also about serving various Ethereum users’ needs.
- Account abstraction: The concept of account abstraction was explored but abandoned due to other priorities. It aimed to allow users to replace basic validation logic with their own, enabling features like social recovery and multisig wallets.
- ERC-4337 and its potential enshrinement: ERC-4337 was created as an extra-protocol solution for account abstraction. There are ongoing discussions about incorporating its features into the core Ethereum protocol for reasons including gas efficiency, code bug risk mitigation, and censorship resistance.
Potential Features for Enshrinement
- ZK-EVMs: Enshrining ZK-EVMs into the Ethereum protocol could eliminate the need for independent implementations and provide a standardized framework for dealing with bugs in the ZK-code.
- Proposer-builder separation and private mempools: These features are being considered for enshrinement to address the rise of Miner Extractable Value (MEV) and block production centralization. However, enshrining private mempools to prevent frontrunning presents challenges due to encryption requirements and weaknesses in existing solutions.
- Liquid staking: There is demand for liquid staking, which allows for using ETH for staking and collateral simultaneously. However, centralizing mechanics and risks exist in different approaches, necessitating safeguards to prevent attacks and concentration of power in staking token governance.
The Tradeoff Between Enshrining Features and Leaving Them to Other Layers
- Minimal viable enshrinement: A middle road approach of minimal viable enshrinement can be taken, enshrining specific pieces that solve key challenges without being too opinionated or narrowly focused.
- Potential risks of enshrining features: Enshrining too much can over-extend the trust and governance load of the protocol and over-complicate the protocol itself. It can also backfire if users’ needs turn out to be different than anticipated.
- De-enshrinement: Sometimes, it may be necessary to de-enshrine certain features, such as little-used precompiles or account abstraction.
Actionable Insights
- Exploring the potential of ERC-4337: Given the potential benefits of incorporating ERC-4337 features into the core Ethereum protocol, further exploration and testing of this feature could be beneficial.
- Investigating the feasibility of enshrining ZK-EVMs: The potential of ZK-EVMs to eliminate the need for independent implementations and provide a standardized framework for dealing with bugs in the ZK-code makes it a promising feature for enshrinement.
- Assessing the risks and benefits of liquid staking: While liquid staking presents potential benefits, it also carries risks. A thorough assessment of these risks and benefits can help in making informed decisions about its implementation.
