EIP Fun Weekly #33: Verkle Trees
This week we delve into two exciting EIPs revolutionizing the world of blockchain and unravel the mysteries of Verkle Trees, Ethereum's groundbreaking data storage resolution,and more.
Hello everyone! Welcome to read the 33rd issue of EIP Fun Weekly. Let's take a look at what happened in the EIP community this week.
EIP Updates
First, let's review some of the key meetings this week and the formal changes to EIPs.
AllCoreDevs Execution Layer Meeting #180
The AllCoreDevs meetings alternate weekly between ACDC (consensus layer focus) and ACDE (execution layer focus) to guide Ethereum protocol forks. Core EIPs related to protocol changes are typically discussed here more with developers than editors.
Takeaways
1.Dencun updates: Developers decided to delay setting a mainnet activation date for the Dencun upgrade due to pending investigations. They agreed to revisit the topic during the next ACD call on February 8. Potuz expressed the need for additional feedback from Layer-2 rollup teams.
2.Prague proposals: Developers engaged in discussions on three significant code changes, namely Verkle, EOF (Ethereum Virtual Machine Object Format), and history expiry.Verkle will be implemented in the EL upgrade after Prague, known as Osaka.
3.Besu Jan 6 Mainnet Event: Besu developer Matt Nelson discussed an outage that affected around 70% of Besu Ethereum nodes in early January. Fortunately,a hotfix has been deployed to address the issue in the Besu client.
Further Reading
Ethereum All Core Developers Execution Call #180 Writeup by Christine Kim: https://www.galaxy.com/insights/research/ethereum-all-core-developers-execution-call-180/
EIPIP Meeting #99
EIPIP stands for “Ethereum Improvement Proposal improvement process”, which intends to bring together experienced developers and experts to facilitate the Ethereum Improvement Proposal improvement process.
Takeaways (Derived from Pooja Ranjan's Summary):
1.RIP process documentation
Although there are still no members of the RIP working group participating in the meeting,Juan Caballero had an opportunity to speak with the author of RIP-7212, who is active in the community but not a member of the RIP working group.
2.Web Page Rendering to include EIPs, ERCs, RIPs
Sam Wilsn and Ansgar express interest in seeing RIPs rendered by a working group,while Ullas (author of RIP-7212) at the time, didn't seem to know about the roles and responsibilities of the working group.
Gavin John has stepped down as an EIP Editor and provides an update on the progress of the working group-based page rendering. Sam Wilsn shares a high-level overview and demo of the working group page and demoed the working group page.
EIP Status Change
Here are EIPs that has been approved for a status change:
EIP-7045: Increase max attestation inclusion slot
Status: Review → Last CallAbstract: The proposed modification raises the maximum attestation inclusion slot from attestation.slot + SLOTS_PER_EPOCH to the final slot of epoch N+1, where N represents the epoch that includes the attestation slot. This adjustment is essential for both the current LMD-GHOST security analysis and the confirmation rule.
EIP-6780: SELFDESTRUCT only in same transaction
Status: Review → Last CallAbstract: This EIP introduces a modification to the functionality of the SELFDESTRUCT opcode. The revised functionality will only involve transferring all Ether in the account to the specified target. However, the existing behavior will be preserved when SELFDESTRUCT is called within the same transaction that a contract was created.
EIP-4788: Beacon block root in the EVM
Status: Review → Last CallAbstract: The suggested approach is to commit the hash tree root of every beacon chain block in the execution payload header associated with that block. These roots will be stored in a smart contract for future reference.
EIP-7516: BLOBBASEFEE opcode
Status: Review → Last CallAbstract: This proposal suggests locking the validator voluntary exit signature domain on Capella to ensure perpetual validity. Currently, signed voluntary exits are only valid for two upgrades. By implementing this change, the voluntary exits signed by validators will remain valid indefinitely on the Capella upgrade.
EIP-4844: Shard Blob Transactions
Status: Review → Last CallAbstract: This proposal introduces blob-carrying transactions, a new transaction format in Ethereum. These transactions contain large data that can't be accessed by the EVM but can have their commitment accessed. The goal is to provide compatibility with future full sharding and enable inclusion of substantial data payloads in transactions.
EIP-5793: eth/68 - Add tx type to tx announcement
Status: Review → Last CallAbstract: EIP-5793 introduces "Immutable Transaction Arguments" in Ethereum. This concept allows marking specific transaction arguments as immutable, enhancing security and transaction validation efficiency. Immutable arguments cannot be modified by subsequent transactions, resulting in improved network performance and reliability.
EIP-4938: eth/67 - Removal of GetNodeData
Status: Review → Last CallAbstract: The proposal suggests removing the GetNodeData and NodeData messages from the Ethereum Wire Protocol, which are used for requesting and retrieving trie nodes or contract code from the state trie by hash. This change aims to streamline the protocol by eliminating these specific message types.
EIP of the Week
Then let's take a look together at the applications or developments related to EIPs this week.
EIP-1153: Transient storage opcodes
This proposal presents the concept of transient storage opcodes, which enable the manipulation of state in a manner similar to regular storage. However, there is a key distinction: transient storage is discarded after each transaction, unlike permanent storage. In practical terms, the values in transient storage are not read from or written to the storage, resulting in cost savings as disk access is not required. Smart contracts can access transient storage using two newly introduced opcodes: TLOAD and TSTORE, where "T" signifies "transient."
What’s its potential uses?
Real-time market data: Smart contracts can subscribe to market data feeds to get real-time updates on prices, allowing for more accurate and timely execution of trades.
Event-driven automation: Smart contracts can subscribe to specific events, such as token transfers or contract interactions, and automatically trigger actions based on those events.
Decentralized finance (DeFi): DeFi protocols can use EIP-1153 to notify users about changes in their positions, liquidity pool updates, or opportunities for arbitrage.
Gaming ecosystems: Gaming platforms can utilize EIP-1153 to notify players about in-game events, updates, and rewards.
Further Reading
FEM forum discussion: https://ethereum-magicians.org/t/eip-1153-transient-storage-opcodes/553
EIP-2330: EXTSLOAD opcode
EIP-2330 proposes a standardized metadata extension for token contracts on the Ethereum network. This extension allows token issuers to attach additional information to their tokens, including metadata such as name, symbol, decimals, and other optional attributes. The goal of EIP-2330 is to enhance the usability and interoperability of ERC-20 tokens by providing a consistent and easily accessible way to retrieve essential information about a token contract.
What’s its potential uses?
Improved user experience: With EIP-2330, wallets, exchanges, and other applications can easily retrieve essential information about tokens, such as token name, symbol, and decimals. This enhances the user experience by providing clear and consistent information about tokens.
Enhanced token listing and discovery: EIP-2330 allows token issuers to provide additional information about their tokens, such as website links, logos, and descriptions. This enables better token listing and discovery, making it easier for users to identify and understand different tokens.
Interoperability and standardization: By providing a standardized metadata format, EIP-2330 promotes interoperability among token contracts. Applications and services can uniformly process token metadata, ensuring consistent behavior across various platforms.
Accessibility and transparency: Token metadata defined in EIP-2330 is publicly accessible, fostering transparency and allowing users to verify important information about tokens before engaging with them.
Further Reading
FEM forum discussion: https://ethereum-magicians.org/t/eip-2330-extsload-and-abi-for-lower-gas-cost-and-off-chain-apps/3733
Anecdote of the Week: Verkle Trees
In the recent ACDE Call #180, developers primarily focused on three significant code changes: Verkle, Ethereum Virtual Machine Object Format (EOF), and history expiry.
A decision was made to plan the implementation of Verkle in the EL upgrade, which will occur after the Prague upgrade, known as Osaka.
What are Verkle Trees?
Verkle Tries represent a data structure that shares similarities with Merkle Patricia Trees (MPT), the current data structure employed in Ethereum. While Verkle Tries adopt a tree-like structure akin to MPT, a significant distinction lies in the usage of vector commitments, a specialized type of hash, by each node to commit to its child nodes. These vector commitments offer long-term advantages and contribute to the potential realization of statelessness in Ethereum.
Why do we need Verkle Trees?
The utilization of vector commitments in Verkle Trees offers a significant advantage in helping Ethereum achieve statelessness. By using vector commitments, Verkle Trees enable much smaller proof sizes, known as witnesses. Unlike Merkle Trees where all sibling nodes' hashes are required at each level, Verkle Trees only need the parent nodes and an optional proof along the paths from leaf nodes to the root. This difference allows Verkle Tries to have a wider structure compared to Merkle Trees, resulting in smaller witness sizes.
The importance of small witness sizes lies in overcoming the challenge posed by large witnesses in achieving statelessness. When witnesses are small enough, they can be contained within each block, enabling block verification solely based on the block's internal information.
How can we realize Verkle Trees?
Overlay Method: Currently, the primary approach involves using a leading candidate method. This method entails the use of two trees: an empty overlay tree (referred to as the Verkle tree) and an existing Merkle tree called the base tree. During each block, a specific number of values are selectively transferred from the base tree to the overlay tree. When accessing the state, a search is first performed in the overlay tree for a given key. If the key is not found, a subsequent search is conducted in the base tree. On the other hand, when modifying the state, any updates are made exclusively to the overlay tree.
Conversion Node: A limited number of highly capable machines perform the translation at a specific block height and subsequently distribute the outcome to the rest of the network. Less powerful clients retrieve the conversion and replay blocks using Verkle mode until they catch up to the latest block.
Local Bulk: Without the presence of a distinct category of nodes, all machines independently carry out the conversion process themselves. While this approach was previously deemed impractical, recent enhancements in performance have made it appear viable.
State Expiry: In this approach, the Merkle tree remains unchanged and is effectively "frozen" in its current state. A new tree is created from scratch. The process of reading and writing data operates similarly to the overlay method, but there is no merging or conversion between the trees at any point. Each tree maintains its separate state and data, without any interaction or synchronization between them.
The existing strategy involves conducting this conversion process discreetly before the fork takes place, happening seamlessly in the background.
Further Reading
Slides on Verkle Trees showcased during ACDE Call #180: https://docs.google.com/presentation/d/1R_UkS0WyGN1FK3qYxSBK5zZxBbN8Cx2mFHQj6rQ0jRA/edit#slide=id.g1efdf8ca04f_0_1
The official website of Verkle Trees: https://verkle.info/
EIP Events
EIP Editing Office Hour Meeting #31
Date & Time - February 6, 2024, at 15:00 UTC
For more details about the meeting agenda, you can visit this GitHub issue.
AllCoreDevs Consensus Layer Meeting #127
Date & Time - February 8, 2024, at 14:00 UTC
For more details about the meeting agenda, you can visit this GitHub issue.
That's all for this week from EIP Fun. EIP Fun is created and supported by LXDAO and PlanckerDAO. We aim to serve as the “layer 2” of the EIP ecosystem, simplifying and accelerating the adoption of EIPs.
Please inform us if you have any additional suggestions or feedback. EIP Fun is a fully open-source and community-driven public good! Donate to us here.
Join the Telegram of EIP Fun: https://t.me/eipfun for more discussions and build connections with EIP buidlers. Follow our Twitter: @EIPFun.