Vitalik Buterin’s new ‘purge’ instructions to simplify the Ethereum protocol and reduce node resource load
Posted: April 1, 2024 7:44 AM Updated: April 1, 2024 7:48 AM
Correction and fact check date: April 1, 2024, 7:44 a.m.
briefly
Vitalik Buterin has published “Purge” instructions outlining steps to streamline the Ethereum protocol and ease the load on node resources.
Vitalik Buterin, co-founder of the Ethereum blockchain, has released “purge” instructions outlining steps to streamline the Ethereum protocol and ease the load on node resources.
According to a blog article, during the Ethereum Dencun hard fork, EIP-6780 removed a significant portion of functionality related to the SELFDESTRUCT opcode. This measure aimed to simplify the protocol by reducing complexity and introducing additional security guarantees. Vitalik Buterin identified this as a pivotal aspect of the “Purge.”
Regarding other ongoing ‘purges’, Vitalik Buterin gave three examples. This includes Geth, which recently dropped support for pre-merger (PoW) networks and removed thousands of lines of code. EIP-161 also formalizes the elimination of concerns about “empty accounts” introduced as part of the Shanghai DoS attack resolution. Additionally, with Dencun implementing an 18-day storage window for blobs, Ethereum nodes will need approximately 50 GB to store blob data, and this requirement is not expected to increase over time.
The first two points represent significant improvements for client developers, while the last point represents notable improvements for node operators.
Four key areas for improvement: precompilation, EIP-4444, LOG reform, and SSZ.
Vitalik Buterin focused on other aspects that may require “fuzzing”, listing precompilation, historical logging (EIP-4444), LOG reform, and the transition to Simple Serialize (SSZ).
According to Vitalik Buterin, the demand for partial precompilation is lower than expected, 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 solve this problem. As seen in EIP-7266, which removes BLAKE2, replacing precompilation with an EVM code segment does the same thing as removing just precompilation.
Regarding the record (EIP-4444), Vitalik Buterin highlighted the key issues: That is, if old records are not stored on all nodes, which entity will store them? He pointed out that large organizations such as Block Explorer are likely candidates. However, it is also possible to develop a peer-to-peer (P2P) protocol to store and distribute this information, which is not overly complex and may be better suited to the task. He also suggested that peer-to-peer (P2P) long-standing torrent networks and protocols explicitly optimized for use on Ethereum are viable options.
Another protocol explicitly optimized for Ethereum use is also being considered. EIP-4444 has the potential to significantly improve the decentralization of Ethereum nodes.
Regarding LOG reform, Vitalik Buterin proposed removing the bloom filter and simplifying the LOG opcode to only produce hashed values in the state. Next steps include developing a separate protocol leveraging ZK-SNARK and Incrementally Verifiable Computation (IVC) to generate a provably correct ‘log tree’. “These log trees act as searchable tables containing all logs for a specific topic, providing distributed applications that require logs with the ability to leverage these separate protocols,” he said in the article.
He also noted that Ethereum’s transition to SSZ is ongoing and the execution layer will need to be migrated to the same structure. Currently, three encrypted data structures are in use: SHA256 binary tree, SHA3 RLP hash list, and hexadecimal Patricia tree. Once the transition to SSZ is complete, only two remain: the SHA256 binary tree and the Verkle tree.
Once the transition to SSZ is complete, only two structures will remain in the system: the SHA256 binary tree and the Verkle tree. As “SNARKing hashes” evolve, it is likely that SHA256 binary trees and Verkle trees will be replaced by binary Merkle trees utilizing hashing algorithms that are compatible with SNARK.
disclaimer
In accordance with the Trust Project Guidelines, the information provided on these pages is not intended and should not be construed as legal, tax, investment, financial or any other form of advice. It is important to invest only what you can afford to lose and, when in doubt, seek independent financial advice. We recommend that you refer to the Terms of Use and help and support pages provided by the publisher or advertiser for more information. Although MetaversePost is committed to accurate and unbiased reporting, market conditions may change without notice.
About the author
Alisa is a reporter for Metaverse Post. She focuses on everything related to investing, AI, metaverse, and Web3. Alisa holds a degree in Art Business and her expertise lies in the fields of art and technology. She developed a passion for journalism through her work with VCs, notable cryptocurrency projects, and science writing. You can contact us at (email protected).
more articles
alice davidson
Alisa is a reporter for Metaverse Post. She focuses on everything related to investing, AI, metaverse, and Web3. Alisa holds a degree in Art Business and her expertise lies in the fields of art and technology. She developed a passion for journalism through her work with VCs, notable cryptocurrency projects, and science writing. You can contact us at (email protected).
more articles