Vitalik Buterin has laid out his vision for streamlining Ethereum, a plan he’s calling “The Purge.” Central to this initiative is the implementation of EIP-6780 during the Dencun hard fork, which significantly dials back the capabilities of the SELFDESTRUCT opcode. This move is part of a broader effort to declutter Ethereum‘s protocol, aiming to make it less complex and more secure.
The heart of EIP-6780 lies in its drastic reduction of the SELFDESTRUCT opcode’s function, limiting its ability to annihilate a contract and erase its code and storage, except when the contract originates from the same transaction. Though it might not seem like a leap towards simplicity in the protocol’s specs, it notably eases the burden on implementations by enforcing two new rules: a cap on the number of storage slots changeable within a single block and the assurance that if a contract begins a transaction or block with code, it will end it the same way.
Before this change, the Ethereum landscape was wilder. A contract could utilize SELFDESTRUCT to wipe clean an unlimited number of storage slots within a block, complicating the potential implementation of Verkle trees and bogging down client implementations with the need for extra, efficient handling code. Contracts could also self-destruct and then be immediately reborn with different code, posing a security headache for transaction verification in account abstraction wallets. With EIP-6780’s introduction, these challenges are addressed, simplifying the construction of Ethereum clients and other infrastructure.
Ethereum’s Ongoing Cleanup Effort
Ethereum’s quest for simplification doesn’t stop at EIP-6780. Geth, for instance, has recently slashed thousands of lines of code by ceasing support for pre-merge (Proof of Work) networks. Another improvement includes the formal acknowledgment that “empty accounts” are no longer a concern, thanks to a past fix introduced by EIP-161. Additionally, the Dencun upgrade has introduced an 18-day storage window for blobs, greatly reducing the storage demands on Ethereum nodes.
The focus also shifts to precompiles—special contracts designed for complex cryptography that standard EVM code can’t handle efficiently. Despite their success, especially in enabling ZK-SNARK applications, certain precompiles like RIPEMD-160, Identity, BLAKE2, and MODEXP are seldom used today. Their limited application, coupled with the consensus bugs they introduce, has marked them for potential removal or replacement with EVM code, albeit at a greater gas expense.
Another significant stride towards simplification is EIP-4444, addressing the unsustainable practice of nodes storing all historical blocks indefinitely. By introducing blobs and setting a timeframe for storage, EIP-4444 aims to alleviate the storage burden on nodes, making it feasible for more users to operate nodes and, by extension, enhancing Ethereum’s decentralization.
Revolutionizing Logs and Transitioning to SSZ
The reform of Ethereum’s logging mechanism is under consideration as well. Traditional logs, integral for decentralized applications to track on-chain events, suffer from inefficiencies, leading most applications to rely on centralized services instead. The proposed solution involves scrapping bloom filters and simplifying the LOG opcode to foster the development of more efficient, decentralized log retrieval methods utilizing ZK-SNARKs and incrementally-verifiable computation.
Lastly, Ethereum’s data storage and access methodology is poised for a major overhaul through the adoption of SimpleSerialize (SSZ). This transition aims to replace the outdated RLP and Merkle Patricia trees, promising a slew of advantages like a cleaner specification, shorter and bounded Merkle proofs, and the elimination of complex bit-twiddling code. The move towards SSZ represents a critical step in unifying Ethereum’s cryptographic data structures, setting us up for a future where a single, SNARK-friendly hash function could serve all of Ethereum.
From Zero to Web3 Pro: Your 90-Day Career Launch Plan
