The Purge
The Purge
.
gas refunds
specification
implementation
fast sync
(eg. Portal)
DESTRUCT
mechanics
EVM impls
expiry
(EIP-4444)
extension
types
harmonization
Eliminate Gas Refunds
August 5, 2021
Eliminate Gas Refunds refers to EIP-3529, introduced in the London hard fork, which reduced gas refunds to address an exploit caused by large refund amounts. This EIP specifically targeted reducing the gas refund from the SELFDESTRUCT operation and eliminating the refund for SSTORE operations that reset contract storage. The primary goal was to prevent bloating the blockchain state with temporary data just to benefit from gas refunds, enhancing the network’s efficiency and security.
By curbing these refunds, the EIP aimed to disincentivize practices that artificially manipulated gas usage, contributing to a more stable and predictable gas market. This change also helped in mitigating certain types of denial-of-service attacks that exploited high refund amounts to consume excessive block resources.
Resources
EIP-4444 Specification
Done
The purpose of EIP-4444 is to prune historical block headers, bodies, and receipts older than one year from Ethereum clients. This initiative addresses the increasing disk space requirements for storing Ethereum’s full transaction history, particularly as SSD storage remains a significant cost for running a node.
EIP-4444 will reduce the storage burden on nodes, making it more feasible for individuals to operate their own nodes without needing extensive and costly storage solutions. Additionally, this pruning enhances the synchronization speed for new nodes joining the network, as they need to download and process less historical data.
Resources
EIP-4444 Inclusion
Awaiting Inclusion
EIP-4444 Inclusion refers to the process of incorporating EIP-4444, which was written in November 2021, into the Ethereum network through a future hard fork.
EIP-4444 has been fully drafted and reviewed, and now it only requires inclusion in an upcoming hard fork to become active.
Resources
Beacon chain fast sync
Extra-Protocol
An upgrade implemented by Ethereum client teams to significantly speed up a node’s initial synchronization with the Beacon chain. Unlike other improvements that follow a formal EIP process, this upgrade was developed and deployed ad-hoc by the client teams.
The ‘checkpoint’ sync functionality allows new nodes to quickly catch up with the current state of the Beacon chain by starting from a recent checkpoint, rather than processing the entire chain history from the genesis block. This enhancement reduces the time and resources needed for a node to become fully operational.
Resources
- -
P2P History | Portal Network
Extra-Protocol
P2P History | Portal Network offers a new method for accessing Ethereum data in a decentralized manner with minimal hardware and bandwidth requirements. Traditionally, users either needed to run a resource-intensive Ethereum node or rely on centralized third-party RPC providers. The Portal Network distributes Ethereum data across multiple peer-to-peer networks, enabling almost instant syncing and access with minimal resources.
This network consists of several P2P networks (state, beacon, and history networks), each storing specific subsets of Ethereum data. Individual Portal clients hold only small portions of this data, while the entire network collectively maintains all historical data. Data requests are broadcast across the network until they reach the node storing the required information, eliminating centralized intermediaries and promoting greater decentralization and participation in the Ethereum network.
Resources
History Expiry Complete
Awaiting Inclusion
The State in Ethereum refers to the current status of all accounts and smart contracts, representing the cumulative outcomes of all transactions and contract executions up to the present block. It is dynamic and changes with each new block. The History, on the other hand, includes the entire record of all transactions and blocks processed since the genesis block, detailing transaction data, block headers, receipts, and more. This historical record is crucial for understanding how the current state has been reached but is not necessary for processing new transactions.
History Expiry will allow the Ethereum network to prune historical data that is no longer needed for the current state, reducing storage requirements for nodes. This enables nodes to operate more efficiently and lowers the barrier to entry for running a node, thereby enhancing decentralization.
Resources
Ban SELF-DESTRUCT
March 13, 2024
EIP-6780 went live in the Cancun Deneb hard fork. It revised the SELFDESTRUCT opcode in Ethereum, limiting its execution to only within the transaction it is invoked.
This adjustment, partially driven by the transition towards Verkle trees, ensures that SELFDESTRUCT no longer has the capability to delete the contract’s code, storage, or reset the nonce after the contract's creation unless it is used during that initial transaction.
This change was aimed at reducing the opcode's potential for misuse, which had historically led to unintended consequences and security vulnerabilities,
while ensuring minimal disruption to existing contracts that utilize SELFDESTRUCT.
Resources
Simplify Gas Mechanics
Ongoing Research
Simplify Gas Mechanics involves removing or revising certain features in the EVM that add unnecessary complexity and cost. Over time, Ethereum has accumulated features that, if redesigned today, might not be included due to our improved understanding of smart contract and blockchain protocol design. Simplifying gas mechanics aims to streamline the protocol by addressing these "vestigial features" which cause ongoing harm due to their complexity.
This step would involve removing features like the 2300 gas stipend, which complicates gas repricing and does not effectively serve its original purpose. It also includes revising how gas visibility and refunds are handled to prevent inefficiencies and security risks. By removing these complex and often redundant features, Ethereum can reduce the cost of implementing new protocol changes and minimize the risk of bugs caused by interactions with these features.
Resources
Remove Precompiles
Ongoing Research
Transition away from specialized operations (precompiles) that are subsidized by the network to direct EVM implementations. Precompiles are specific functions implemented at the protocol level, offering lower gas costs compared to if they were written from scratch in Solidity. These functions include operations like cryptographic hashing and signature verification, but can vary in functionality. See the linked list of precompiles below.
As we improve the EVM this becomes more palatable, and the network can stop favoring certain operations.
Resources
Address Space Extension
Ongoing Research
Increase the size of Ethereum addresses from 20 bytes to 32 bytes. The current 20-byte (160-bit) addresses offer 80 bits of collision resistance, which may become insufficient against sophisticated attacks. Expanding to 32-byte addresses provides enhanced security by increasing collision resistance and allows for additional features such as shard IDs and epoch data, supporting future state expiry schemes and sharding.
This change requires transitioning existing contracts and systems to accommodate the new address size. Proposed methods include new opcodes like CREATE3 for generating 32-byte addresses and BIGCALLER for handling calls from both old and new address formats. This transition would ensure backward compatibility, allowing new-style addresses to interact with pre-existing contracts and maintain persistent identities.
Resources
State Expiry
Ongoing Research
State Expiry refers to the routine removal of old state data from the Ethereum network to manage it's growing size. The state includes the current information representing the cumulative outcomes of all transactions and contract executions up to the present block. Unlike history, which is a comprehensive record of all past transactions, the state is dynamic and constantly changing.
Implementing state expiry would mean that data not accessed or modified within a certain period would be pruned from the active state, reducing the burden on nodes to store and maintain this information. This approach helps in managing the ever-growing state size, making it easier for nodes to operate efficiently. The challenge lies in ensuring that expired state data can be retrieved or recreated if needed, potentially via a verkle root.
Resources
LOG Reform
Ongoing Research
LOG Reform aims to simplify the way event logs are managed in Ethereum to enable more efficient searching of historical events. Currently, Ethereum uses Bloom filters to index logs, which help applications quickly identify relevant blocks and transactions that contain specific log entries. However, this approach has been criticized for being inefficient and slow.
The proposed LOG reform suggests removing Bloom filters and instead using decentralized protocols that employ zero-knowledge proofs (ZK-SNARKs) for log indexing. These protocols, such as those implemented in ZK-rollups, provide a way to generate provably correct log trees that ensure privacy and efficiency. By adopting this approach, Ethereum can streamline data handling and improve the performance of querying historical logs.
Resources
Remove Old TXN Types
Ongoing Research
Stop supporting older transaction types to reduce code complexity in clients.
However, this proposal comes with a trade-off regarding backward compatibility. Removing support for old transaction types means that certain legacy transactions and applications that rely on them may no longer function without updates. This necessitates careful planning and communication with the Ethereum community to ensure a smooth transition, possibly involving migration tools or support periods to minimize disruption for users relying on older transaction types.
Resources
- -
Serialization Harmonization
Ongoing Research
Serialization Harmonization involves standardizing the data serialization method across Ethereum’s execution and consensus layers. Currently, the execution layer uses Recursive Length Prefix (RLP) for serialization, while the consensus layer employs Simple Serialize (SSZ). The proposal aims to replace RLP with SSZ across all layers of Ethereum, enhancing uniformity and efficiency in data handling.
Simple Serialize (SSZ) is designed for deterministic serialization with efficient Merkleization. It separates data into basic types (like unsigned integers and booleans), which are directly converted into little-endian byte strings, and composite types, which may include a mix of fixed and variable-length elements. Variable-length elements are placed at the end of the serialization, indexed by offsets in the main structure.