Vitalik Buterin’s New ‘Purge’ Guidelines To Simplify Ethereum Protocol And Reduce Node Resource Load
In Brief
Vitalik Buterin released “Purge” guidelines outlining steps to streamline the Ethereum protocol and alleviate the load on node resources.
Co-founder of the Ethereum blockchain, Vitalik Buterin, has released “Purge” guidelines outlining steps to streamline the Ethereum protocol and alleviate the load on node resources.
According to the blog article, during the Ethereum Dencun hard fork, EIP-6780 eliminated a significant portion of the functionality associated with the SELFDESTRUCT opcode. This action aimed to streamline the protocol by reducing complexity and introducing additional security guarantees. Vitalik Buterin identified it as a pivotal aspect of the “Purge.”
Regarding other ongoing “Purges,” Vitalik Buterin provided three examples. These include Geth, which recently halted support for the pre-merger (PoW) network, removing thousands of lines of code. Additionally, EIP-161 formalizes the elimination of concerns regarding “empty accounts,” introduced as part of addressing the Shanghai DoS attack. Furthermore, implementing an 18-day storage window for blobs in Dencun ensures that Ethereum nodes will need approximately 50GB to store blob data, with no anticipated increase in this requirement over time.
The initial two points represent substantial enhancements for client developers, whereas the last point signifies a notable improvement for node operators.
Four Key Areas for Improvement: Precompiles, EIP-4444, LOG Reform, and SSZ
Focusing on other aspects that may require “purging,” Vitalik Buterin listed Precompiles, history logging (EIP-4444), LOG reform, and transitioning to Simple Serialize (SSZ).
According to Vitalik Buterin, the demand for partial precompilation is lower than anticipated, and precompiled functions represent a significant source of consensus errors and challenges for new Ethereum Virtual Machine (EVM) implementations. However, there are two approaches to address this issue: solely removing precompilation, as seen with EIP-7266, which eliminates BLAKE2, and substituting precompilation with an EVM code segment that executes the same operation.
Regarding the history (EIP-4444), Vitalik Buterin highlighted a key issue: if old history isn’t stored by every node, what entities will store it? He noted that large-scale entities like block explorers are likely candidates. However, it’s also feasible and not overly complex to develop peer-to-peer (P2P) protocols to store and distribute this information, which can be more tailored to the task. He further suggested that P2P’s old history torrent network and protocols explicitly optimized for Ethereum usage are viable options.
Another protocol explicitly optimized for Ethereum‘s use is also being considered–EIP-4444 has the potential to significantly enhance the decentralization of Ethereum nodes.
Regarding the LOG reform, Vitalik Buterin suggested eliminating bloom filters and simplifying the LOG opcode to solely generate a value hashed into the state. The next step would involve developing separate protocols utilizing ZK-SNARKs and incrementally-verifiable computation (IVC) to create provably-correct ‘log trees.’ “These log trees would function as a searchable table containing all logs for a given topic, providing decentralized applications requiring logs with the ability to utilize these separate protocols,” he said in the article.
He also noted that Ethereum’s transition to SSZ is ongoing, and the execution layer needs to be migrated to the same structure. Currently, three encrypted data structures are in use, including SHA256 binary trees, SHA3 RLP hashed lists, and hexary Patricia trees. Once the transition to SSZ is complete, only two will remain SHA256 binary trees and Verkle trees.
Once the transition to SSZ is finalized, the system will be left with only two structures: SHA256 binary trees and Verkle trees. As advancements are made in “SNARKing hashes,” there is a possibility of replacing both SHA256 binary trees and Verkle trees with binary Merkle trees that utilize a hash algorithm compatible with SNARKs.
Disclaimer
In line with the Trust Project guidelines, please note that the information provided on this page is not intended to be and should not be interpreted as legal, tax, investment, financial, or any other form of advice. It is important to only invest what you can afford to lose and to seek independent financial advice if you have any doubts. For further information, we suggest referring to the terms and conditions as well as the help and support pages provided by the issuer or advertiser. MetaversePost is committed to accurate, unbiased reporting, but market conditions are subject to change without notice.
About The Author
Alisa, a dedicated journalist at the MPost, specializes in cryptocurrency, zero-knowledge proofs, investments, and the expansive realm of Web3. With a keen eye for emerging trends and technologies, she delivers comprehensive coverage to inform and engage readers in the ever-evolving landscape of digital finance.
More articles
Alisa, a dedicated journalist at the MPost, specializes in cryptocurrency, zero-knowledge proofs, investments, and the expansive realm of Web3. With a keen eye for emerging trends and technologies, she delivers comprehensive coverage to inform and engage readers in the ever-evolving landscape of digital finance.
