EIP Fun Weekly #50: PeerDAS
Explore PeerDAS: the cutting-edge data availability solution transforming network scalability and reliability.
Hello everyone! Welcome to read the 50th 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.
EIP Editing Office Hour Meeting #37
The EIP Editing Office Hour Meeting is a biweekly gathering for EIP editors and authors to address issues during EIP creation process. If you have any trouble in writing and submitting your EIP, comment in the recurring agenda post of each meeting or directly join the meeting.
EIP Status Change
Here are the EIPs that have been approved for a status change on the EIP Editing Office Hour Meeting this week:
EIP-7709: Read BLOCKHASH from storage and update cost
Status: Undefined → Draft
Abstract: Modify the BLOCKHASH (0x40) opcode to retrieve and serve data from the system contract storage, enabling stateless execution. Apply the additional (cold or warm) gas fees similarly to SLOAD for the respective slot.
EIP-7706：Separate gas type for calldata
Status: Undefined → Draft
Abstract: Introduce a new type of gas specifically for transaction calldata. Implement a new transaction type that includes max_basefee and priority_fee as a vector, offering values for execution gas, blob gas, and calldata gas. Adjust the basefee mechanism to apply uniformly across these three gas types.
Add EIP: NONREENTRANT and REENTRANT opcodes
Status: Undefined → Draft
Abstract: Add two opcodes: NONREENTRANT and REENTRANT. The NONREENTRANT opcode sets a contract's reentrancy status, preventing it from being called (CALL, STATICCALL, or DELEGATECALL) until the REENTRANT opcode clears the status.
AllCoreDevs Consensus Layer Call #134
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. Devnet 0 Recap
EIP 7549 Implementation: During the launch of Pectra on Devnet 0, client teams agreed to keep attestation behavior unchanged during the hard fork activation to avoid invalid attestations, activating EIP 7549 in the same epoch as other Pectra EIPs.
EIP 7251 Uncertainty: Developers remain uncertain about enabling staked ETH consolidations from the execution layer (EL), which could benefit staking pools like Lido. Progress on validator stake consolidation in client implementations will be reviewed in a few weeks to decide if it should be an EL or CL operation.
EIP 6110 and Version Control Discussion: Open questions about validator deposit finalization under EIP 6110 were summarized by Teku developer Mikhail Kalinin. Additionally, there was a discussion about version control for the “GetPayloadBodies” request in the Engine API, with developers encouraged to share their thoughts on GitHub.
2. Pectra Scope Discussion
Pectra Upgrade Considerations: Developers discussed including EIP 7688 and PeerDAS in the Pectra upgrade. EIP 7688 ensures forward compatibility for EIP 7549 attestation changes, while PeerDAS enhances data availability for rollups, potentially increasing blob transactions per block from 3 to 64 or more.
Debate on PeerDAS Integration: Some developers preferred integrating PeerDAS in Pectra even if it delays the upgrade, while others suggested decoupling its activation to avoid frequent client upgrades. Testing PeerDAS alongside Pectra EIPs will continue, with PeerDAS activating in a later epoch on devnets and testnets.
EIP 7688 and EIP 7549 Discussion: The inclusion of EIP 7688 in Pectra was debated, with no agreement reached. This topic, along with EIP 7549 considerations, will be revisited in the next ACDC call.
Further Reading
Ethereum All Core Developers Consensus Call #134 Writeup by Christine Kim:
https://www.galaxy.com/insights/research/ethereum-all-core-developers-consensus-call-134/
EIP of the Week
Then let's take a look together at the applications or developments related to EIPs this week.
ERC-7208: On-chain Data Container
On-chain Data Containers are smart contracts based on ERC-721 that store on-chain data within structures known as “Properties.” The information within these Properties can be accessed and modified by specific smart contracts called “Property Managers.” This ERC establishes a set of interfaces to separate the storage layer from the functional layer that manages the data. Additionally, we present an interface for “Restrictions,” which are structures linked to Properties that impose limitations on the ability of Property Managers to access or alter the data stored in Properties.
What’s its potential uses?
1. Decentralized Identity (DID) Management:
Identity Verification: Store and manage decentralized identity credentials, ensuring they can be updated and verified by authorized entities only.
Data Privacy: Implement restrictions to control who can access sensitive identity data, ensuring privacy.
2. Supply Chain Tracking:
Item Traceability: Record the entire lifecycle and movement of goods, from production to delivery, ensuring transparency.
Access Restrictions: Restrict data modification to authorized supply chain participants only.
3. Health Records:
Patient Data Storage: Store patient health records securely, allowing access and updates only by authorized healthcare providers.
Data Sharing: Implement restrictions to share data with specific healthcare providers or institutions as needed.
Further Reading
FEM forum discussion:
https://ethereum-magicians.org/t/erc-7208-on-chain-data-container/14778
ERC-7496: NFT Dynamic Traits
This specification presents a new interface that expands upon ERC-721 and ERC-1155, providing methods to set and retrieve dynamic on-chain attributes associated with non-fungible tokens. These dynamic attributes can represent various elements such as properties, characteristics, redeemable entitlements, or other features that may evolve over time. By establishing these traits on-chain, they can be utilized and updated by other on-chain contracts.
Why proposed it?
Trait values for non-fungible tokens are often stored off-chain, making it difficult to query and modify these values within contract code. Enabling the setting and retrieving of traits on-chain opens up new possibilities, such as redeeming on-chain entitlements and conducting transactions based on a token's traits.
On-chain traits can be utilized by contracts in various scenarios. For instance, a contract can use these traits to entitle a token to a consumable benefit (e.g., a redeemable item) and reflect this robustly on-chain. Marketplaces can facilitate bidding on tokens based on their trait values without depending on off-chain states, thus protecting users from frontrunning attacks. The primary motivation for this proposal is to safeguard users against frontrunning attacks in marketplaces, where NFTs with certain traits are listed and expected to maintain those traits during fulfillment.
Further Reading
FEM forum discussion:
https://ethereum-magicians.org/t/erc-7496-nft-dynamic-traits/15484
Anecdote of the Week: PeerDAS
PeerDAS, short for Peer Data Availability Sampling, is a mechanism introduced in EIP-7594 for monitoring and sampling data availability across nodes in the Ethereum network. It aims to enhance data availability guarantees, ensuring data remains accessible and verifiable by nodes. PeerDAS improves network reliability, scalability, and efficiency by optimizing data sharing, minimizing the workload on honest nodes, and maintaining data storage and transmission integrity. By considering different types of nodes and network organization, PeerDAS contributes to a more secure and robust Ethereum ecosystem.
Buterin recently addressed this concept. He emphasized that while primary scaling issues have been resolved, there is a need to enhance rollup efficiency in optimizing each data segment. He suggested that this improvement should particularly involve leveraging PeerDAS. Additionally, he highlighted that Ethereum's upcoming phase should focus on Data Availability Sampling (DAS), a method for validating block data existence without requiring every node to download the entire block. This approach aids scalability by reducing storage demands for individual nodes.
With the integration of PeerDAS, scalability will surpass the capabilities introduced by EIP-4844 with Dencun, resulting in a notable reduction in node workloads. Under the PeerDAS framework, each node would store a substantial portion (e.g., 1/8) of all data blobs, establishing connections to multiple peers in the peer-to-peer network. When a node needs data sampling, it seeks assistance from a peer responsible for that data segment. Consequently, more individual stakers will have the opportunity to engage in fortifying the network's security through PeerDAS.
EIP Events
EIPIP Meeting #105
Date & Time - June 5, 2024, at 17:30 UTC
For details about the meeting, you can visit this GitHub issue.
AllCoreDevs Execution Layer Meeting #188
Date & Time - Jane 6, 14:00 UTC
For details about the meeting, you can visit this GitHub issue.
That's all for this week from EIP Fun. EIP Fun is created and supported by LXDAO and ETHPanda. 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.