One of the problems with Ethereum and other blockchains is that they grow in size over time. This means increased code complexity and storage requirements.
The blockchain must retain all data throughout history that must be saved by all clients and downloaded by new clients. This continually increases client load and synchronization time.
Additionally, as Vitalik Buterin notes, “It's easier to add new functionality than remove old functionality,” which increases the complexity of your code over time.
Therefore, Buterin believes that developers need to be proactive in stemming these growth trends while preserving Ethereum's permanence. So Buterin presented The Purge, a three-part plan aimed at simplifying blockchain and reducing its data load.
Part 1: History expiration date
A fully synchronized Ethereum node currently requires approximately 1.1 TB of storage space for running clients. Consensus clients require several hundred gigabytes more. According to Buterin, most of this data is several years old, including data about past blocks, transactions, and receipts. The disk space required to store all this history continues to grow by hundreds of gigabytes each year.
Buterin believes this problem can be solved by something called the History Expiry.
Each block on the blockchain points to the previous block via a hash link. This means that the consensus about the current block indicates the consensus about the history.
According to Buterin, as long as the network has consensus on the current block, the relevant historical data will be provided by a single attacker through Merkle proofs, allowing anyone to verify its integrity. This means that instead of having all nodes store all data, each node can store a small portion of the data, reducing storage requirements.
Buterin essentially proposes adopting the operating model of torrent networks, where each participant stores and distributes only a small portion of the data stored and distributed by the network.
Ethereum has already taken steps towards reducing storage requirements, and certain information has an expiration date. For example, consensus blocks are stored for 6 months and blobs are stored for 18 days.
EIP-4444 is another step in that direction and aims to limit the retention period of history blocks and receipts to one year. However, the long-term goal is to have one fixed period, such as 18 days, during which all nodes save everything, and old data is stored distributed across the peer-to-peer network. .
Part 2: Status expiration
According to Buterin, even if clients no longer need to store their entire history, the problem of bloated storage requirements won't be completely solved. This is because clients will need to increase their storage capacity by approximately 50GB each year due to “continuous growth in national account balances and nonces, contract codes and contract storage.”
New state objects can be created in three ways. How to create a new account, how to send ETH to a new account, and how to set up a previously dormant storage slot. Once a state object is created, its state persists forever.
Buterin believes that a solution that automatically expires state objects over time needs to be efficient, user-friendly, and developer-friendly. This means that the solution does not require a lot of computation, that users do not lose access to their tokens even if they leave them for years, and that developers do not suffer significant inconvenience in the process. Masu.
Buterin proposes two types of “worst known solutions”:
Partial State Expiration Solution Address Period-based State Expiration Proposal.
Partial state expiration
The partial state revocation proposal works on the principle of dividing the state into “chunks.” This requires everyone to save a “top-level map” with chunks that are either empty or never empty. Data within a chunk is only saved if it has been accessed recently. A “resurrection” mechanism allows anyone to put data back into a chunk if it is unsaved by providing evidence of what it was.
Address period-based state expiration
Address duration-based state expiration suggests growing the list of state trees instead of storing the entire state in just one. Any state read or written is updated to the latest state tree. A new empty state tree is added once per period (for example, one year).
In this scenario, the old state tree is frozen and the full node only needs to save the two most recent trees. If a state object becomes part of an expired tree, it can be read or written, but transactions require a Merkle proof. After the transaction, it will be added back to the latest tree.
Feature cleanup
No matter how simple they are at first, all protocols become complex over time.
Buterin writes:
“For Ethereum to avoid falling into an increasingly complex black hole, it needs to do one of two things: (i) stop changing and ossify the protocol, or (ii) actually You can remove features and reduce functionality” complex. “
According to Buterin, several small fixes are needed to eliminate Ethereum's complexity, including removing the SELFDESTRUCT opcode, removing old transaction types and beacon chain committees, and reforming the LOG. Buterin also proposed simplifying gas dynamics, removing gas observability, and improving static analysis.
mentioned in this article
