The Road to a More Simplified and Efficient Ethereum

One of the major challenges facing Ethereum is how to reduce complexity and storage requirements in the long term while maintaining the durability and decentralization characteristics of the blockchain. This requires us to take action in several key areas:

History Record Expired

Currently, a fully synchronized Ethereum node requires approximately 1.1TB of storage space, most of which is used to store historical data. Even if the gas limit remains unchanged, the size of the node will still increase by hundreds of GB each year.

The solution is to establish a peer-to-peer network composed of Ethereum nodes to store old data in a distributed manner. Each node only needs to store data from the last 18 days or so, while older data can be retrieved through the network. This can significantly reduce the storage burden on individual nodes.

The main tasks for implementing history record expiration include:

1. Build and integrate specific distributed storage solutions, such as introducing existing torrent libraries or Ethereum's native Portal network.

2. Enable EIP-4444 to limit the time nodes store historical data.

3. Deciding how to handle the "ancient" historical data, whether to rely entirely on existing archive nodes or to build a more robust distributed storage network.

Status Expired

Even if the need to store historical records is eliminated, the storage requirements for clients will still grow by about 50GB each year, as the status ( account balances, contract codes, and other ) continue to increase.

There are two main types of solutions:

1. Partial state expiration: Partition the state and only store the most recently accessed data blocks, while other data is only kept as a 32-byte commitment.

2. Address cycle-based state expiration: periodically adding new empty state trees, while old trees are frozen. Full nodes only store the most recent two trees.

Both of these solutions have their pros and cons, and a balance must be struck between complexity, user-friendliness, and developer-friendliness. Regardless of which solution is adopted, the issue of address space expansion or contraction needs to be addressed, which is itself a significant challenge.

Function Cleanup

To reduce the complexity of the protocol, we need to eliminate some unnecessary or rarely used features:

1. Replace RLP encoding completely with SSZ
2. Delete old transaction types
3. Simplified logging mechanism
4. Remove the Beacon Chain Synchronization Committee Mechanism
5. Unified Data Format
6. Simplify the gas mechanism
7. Remove some precompiled
8. Cancel gas observability
9. Improve static analysis capabilities

When making these simplifications, it is necessary to weigh the degree of simplification/speed against backward compatibility. A standardized process should be established to handle non-urgent backward incompatible changes.

A more radical simplification method is to convert most of the protocol's content into contract code. For example, simplifying Ethereum L1 to only include the beacon chain, introducing a minimal virtual machine, and then rebuilding the EVM on top of it as the first aggregation. This approach can significantly simplify the protocol, but the implementation is quite challenging.

In general, through these measures, we can significantly reduce the complexity and storage requirements of Ethereum while maintaining its core values, laying the groundwork for long-term sustainable development. This requires the community to work together to find a balance between technological innovation and backward compatibility.