Next Steps in the Purge: A Journey Towards a Simpler, More Secure Ethereum

Next Steps in the Purge: A Journey Towards a Simpler, More Secure Ethereum IntroductionEthereum, the blockchain platform known for its smart contract capabilities, has been undergoing a series of protocol upgrades known as "the Purge." These upgrades aim to simplify the protocol, enhance security, and remove technical debt

Next Steps in the Purge: A Journey Towards a Simpler, More Secure Ethereum

Introduction

Ethereum, the blockchain platform known for its smart contract capabilities, has been undergoing a series of protocol upgrades known as "the Purge." These upgrades aim to simplify the protocol, enhance security, and remove technical debt. In this article, we will delve into the latest developments in the Purge and explore the potential implications for the future of Ethereum.

Understanding EIP-6780: Simplifying the SELFDESTRUCT Operation

One of the lesser-known EIPs introduced in the recent Dencun hard fork was EIP-6780, which significantly reduces the functionality of the SELFDESTRUCT opcode. This opcode, when invoked, destroys the contract that called it and empties its code and storage. However, EIP-6780 limits its effectiveness to cases where the contract is created during the same transaction.

While this change doesn't directly reduce the complexity of the specification, it introduces two new invariants that enhance the implementation:

- Limited Storage Slot Editing: After EIP-6780, there is a maximum number of storage slots that can be modified within a single block (approximately gas limit / 5000).

- Code Persistence: If a contract has non-empty code at the start of a transaction or block, it will have the same code at the end of that transaction or block.

These invariants eliminate two potential issues:

1. Previously, SELFDESTRUCT could be used to clear an arbitrary number of storage slots within a single block, complicating the implementation of Verkle trees and making Ethereum clients more complex.

2. Contract code could change from non-empty to empty after a SELFDESTRUCT call, and the contract could even be recreated with different code immediately after. This made it difficult for account abstraction wallets to use code caches without being vulnerable to DoS attacks.

By enforcing these invariants, EIP-6780 simplifies the development of Ethereum clients and other types of infrastructure. In the future, additional EIPs are expected to address remaining SELFDESTRUCT use cases and potentially eliminate it entirely.

Other Notable Purges in Progress

Beyond EIP-6780, there are several other ongoing efforts to simplify and enhance Ethereum:

- Removal of Legacy Code: Geth, a popular Ethereum client, recently removed thousands of lines of code related to supporting the pre-merge Proof-of-Work (PoW) network.

- Expiration of Pre-Merge Data: Dencun introduced a 18-day storage window for transaction blobs, reducing the amount of storage required for Ethereum nodes from terabytes to approximately 50 GB.

- Elimination of Empty Account Concept: EIP-161, implemented in Dencun, removed the need for specific code to handle "empty accounts," further simplifying client code.

These changes improve the experience for client developers and reduce the storage requirements for node operators.

Potential Future Purges

Precompiles

Precompiles are Ethereum contracts that do not have EVM code but instead have logic that must be implemented directly by clients. They were intended to enable complex cryptography that was inefficient to implement in EVM.

While some precompiles, such as the elliptic curve precompile, have seen significant use, others have minimal usage:

- RIPEMD-160: Introduced to improve compatibility with Bitcoin

- Identity: Returns the same output as its input

- BLAKE2: Introduced to improve compatibility with Zcash

- MODEXP: Introduces support for very large modular exponentiation, primarily for RSA-based cryptography

These precompiles have proven to be less in demand than expected. The Identity precompile, often used for data duplication, has been replaced by the MCOPY opcode introduced in Dencun. However, removing precompiles poses challenges as they are a potential source of consensus errors and implementation difficulties for new EVM implementations.

There are two primary approaches to removing precompiles:

1. Direct Removal: EIP-7266 proposed removing BLAKE2, which is straightforward but can break applications that still rely on it.

2. EVM Replacement: Precompiles can be replaced with EVM code that performs the same operation, albeit at a higher gas cost. This approach is more complex but has a lower risk of breaking applications.

Historical Blocks (EIP-4444)

Currently, Ethereum nodes are expected to store all historical blocks indefinitely. This approach is inefficient and increases the storage requirements for node operators. Dencun introduced blobs, reducing storage requirements to approximately 18 days. EIP-4444 proposes removing historical blocks from default Ethereum nodes after a certain period.

A key question is how to preserve historical data if it is not stored by every node. Large entities like block explorers can archive the data, but decentralized protocols for storing and distributing it are possible.

Maintaining the blockchain's immutability while reducing the storage requirements for node operators is a complex challenge. Potential solutions include point-to-point torrent networks or optimized protocols tailored for Ethereum's specific needs.

Log Reform

Logs were introduced to allow applications to record information about on-chain events for easy retrieval by decentralized applications (dApps). However, the current mechanism is slow and often requires centralized services to efficiently search through historical records.

A potential solution is to remove bloom filters and simplify the LOG opcode to create a value that stores a hash in the state. Separate protocols can be developed to generate verifiable "log trees" using ZK-SNARKs and Incremental Verifiable Computation (IVC). These protocols can provide efficient and decentralized access to logs.

Transition to SSZ

Much of Ethereum's block structure, including transactions and receipts, is still stored using outdated formats based on RLP and Merkle Patricia trees. This complicates the development of applications that use this data.

The Ethereum consensus layer has transitioned to the more efficient SimpleSerialize (SSZ) format:

[Image of SSZ Merkleization]

Source: https://eth2book.info/altair/part2/building_blocks/merkleization/

However, the execution layer needs to complete its transition to SSZ. This change offers several benefits:

- Simplified and clearer specification

- Reduced Merkle proof sizes (by a factor of 4 in most cases) compared to the current Patricia trees

- Bounded Merkle proof sizes, avoiding extremely long worst-case proofs

- Elimination of complex bit manipulation code

- Reusable implementations for ZK-SNARK use cases

Ethereum currently uses three types of cryptographic data structures: SHA256 binary trees, SHA3 RLP hash lists, and hex Patricia trees. Once the transition to SSZ is complete, only two will remain: SHA256 binary trees and Verkle trees. In the future, these may be replaced by binary Merkle trees using SNARK-friendly hashes.

Conclusion

The Purge is an ongoing effort to simplify, secure, and enhance the Ethereum protocol. EIP-6780 is a key example of this process, demonstrating how the protocol can be improved by removing complexity and adding new security guarantees. Other initiatives, such as the removal of precompiles, historical block purging, log reform, and the transition to SSZ, are expected to further streamline Ethereum and address technical debt. These changes will contribute to a more robust, user-friendly, and energy-efficient Ethereum ecosystem.