Risk Warning: Beware of illegal fundraising in the name of 'virtual currency' and 'blockchain'. — Five departments including the Banking and Insurance Regulatory Commission
Information
Discover
Search
Login
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt
BTC
ETH
HTX
SOL
BNB
View Market
Vitalik published an article discussing the future development of the Ethereum protocol, The Purge, with the goal of reducing storage requirements and the complexity of the Ethereum protocol
2024-10-26 08:46
Odaily News Vitalik released the future development of the Ethereum protocol (Part V: The Purge), with the following key goals: Reduce client storage requirements by reducing or eliminating the need for each node to permanently store all history or even state; Reduce the complexity of the protocol by eliminating unnecessary features. The article mentioned that Ethereum has begun to get rid of the mode where all nodes permanently store all history. Consensus blocks (that is, the part related to the proof-of-stake consensus) are only stored for about 6 months. Blobs are only stored for about 18 days. EIP-4444 aims to introduce a one-year storage period for historical blocks and receipts. The long-term goal is to have a coordinated period (probably about 18 days) during which each node is responsible for storing everything, and then the peer-to-peer network composed of Ethereum nodes stores old data in a distributed manner. In addition to the need for clients to store history, client storage requirements will continue to grow, about 50 GB per year, because the state continues to grow: account balances and random numbers, contract code, and contract storage. Users can pay a one-time fee to burden current and future Ethereum clients forever. Two things need to be done to reduce the complexity of the protocol: Stop changes and make the protocol rigid; Be able to actually remove features and reduce complexity. In addition, Vitalik mentioned that a more radical way to reduce complexity is to keep the protocol as it is, but transfer most of it from protocol functions to contract code; a more moderate way is to keep the relationship between the beacon chain and the current Ethereum execution environment unchanged, and choose RISC-V, Cairo or other VM as the new "Ethereum official VM", and then force all EVM contracts to be converted to new VM code (by compilation or interpretation) that interprets the logic of the original code. In theory, this can even be done with the "target VM" as the EOF version.