EIP Fun Weekly #52: The Blob
The Ethereum Blob is a cost-effective solution that enhances scalability and privacy by temporarily storing transaction data off-chain, reducing congestion and transaction costs.
Hello everyone! Welcome to read the 52nd 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 #38
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-7716: Anti-correlation attestation penalties
Status: Undefined → Draft
Abstract: Decentralizing the validator set is crucial for Ethereum’s credible neutrality and its ability to resist censorship. This EIP suggests modifying penalties to encourage decentralization, diversification, and robustness. Entities with more diversity would receive lower penalties, while those with highly correlated setups would incur stricter penalties.
EIP-7708: ETH transfers emit a log
Status: Undefined → Draft
Abstract: Every ETH transfer, irrespective of whether it's a transaction, CALL, or SELFDESTRUCT, generates a log.
EIP-7600: Hardfork Meta - Pectra
Status: Undefined → Draft
Abstract: This Meta EIP catalogs the EIPs officially reviewed and incorporated into the Prague/Electra network upgrade.
ERC-7720: Deferred Token Transfer
Status: Undefined → Draft
Abstract: This standard outlines a system where users can deposit ERC-20 tokens for a beneficiary, who can only withdraw the tokens after a specific future date. Each deposit transaction receives a unique ID and contains details such as the token address, sender, recipient, amount, unlock time, and withdrawal status.
ERC-5521: Referable NFT
Status: Last Call → Final
Abstract: This standard extends ERC-4626 to support multiple assets or entry points for the same share token. It also allows Vaults to convert between two arbitrary external tokens, even if they don't have a true share token.A new share method is added to the Vault to externalize the ERC-20 dependency.Additionally, it includes a Vault-to-Share lookup for the share token.Finally, it requires Vaults and the share token to support ERC-165.
ERC-7540: Asynchronous ERC-4626 Tokenized Vaultss
Status: Review → Last Call
Abstract: This standard extends ERC-4626 to support multiple assets or entry points for the same share token. It also allows Vaults to convert between two arbitrary external tokens, even if they don't have a true share token.A new share method is added to the Vault to externalize the ERC-20 dependency.Additionally, it includes a Vault-to-Share lookup for the share token.Finally, it requires Vaults and the share token to support ERC-165.
AllCoreDevs Consensus Layer Call #135
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. Announcements
Parithosh Jayanthi from the EF DevOps team announced that ethPandaOps would take over the maintenance of the ethereum-package Kurtosis module, urging users to update their links and watch for new releases.
Tim Beiko shared his efforts to introduce new processes for staging EIPs in Ethereum upgrades and asked developers to review and provide feedback on a draft EIP before the next ACD call.
2. Electra
Developers are finalizing specifications for Electra v1.5.0-alpha.3 and have agreed to merge PR #3768, which appends the "committee_bits" field to the end of "Attestation" to resolve serialization issues.
Most client teams expect to have a new release ready for testing within one to two weeks after this version is finalized, with the timing for the next Pectra Devnet to be revisited in a few weeks.
3. PeerDAS
Developers discussed PeerDAS, a networking change for handling large data transactions, deciding to activate it on separate devnets from other Pectra EIPs.
They raised concerns about merging PeerDAS with other implementations and agreed to keep them separate until stable, revisiting the merge in a month.
There was also debate on whether to increase the blob gas limit alongside PeerDAS, weighing the risks of simultaneous implementation versus staged changes.
Further Reading
Ethereum All Core Developers Consensus Call #135 Writeup by Christine Kim:
https://www.galaxy.com/insights/research/ethereum-all-core-developers-consensus-call-135/
EIP of the Week
Then let's take a look together at the applications or developments related to EIPs this week.
EIP-7503: Zero-Knowledge Wormholes
While researching privacy solutions and ZKP applications, we discovered a technique where people can burn their digital assets (e.g., ETH) by sending them to an unspendable address. Later, they can create a ZK proof showing that some tokens are in an unspendable account, without revealing the account itself.
This EIP proposes adding a minting functionality to Ethereum, allowing people to re-mint Ethers they have intentionally burned. This privacy solution offers strong plausible deniability for the sender, as it becomes impossible to prove their participation in the privacy protocol. Additionally, it creates an anonymity pool that includes all Ethereum accounts with no outgoing transactions by default.
What’s its potential uses?
Enhanced Privacy and Anonymity:
Burning and Re-Minting: Users can anonymize their transactions by burning Ethers and later re-minting them, effectively breaking the traceability of funds. This process helps ensure that transaction details remain confidential, protecting user identities.
Zero-Knowledge Proofs (ZKPs): Utilizing ZKPs, users can prove they have tokens in an unspendable account without disclosing which one, further enhancing privacy.
Anti-Censorship and Protection from Surveillance:
Resisting Tracking and Censorship: The unlinkable nature of the burn and re-mint process makes it much harder for authorities or malicious actors to track or censor specific transactions. This gives users the freedom to conduct transactions without fear of censorship or retaliation.
Anonymous Participation: Users can participate in privacy protocols without revealing their identity, protecting them from potential scrutiny or negative consequences.
Secure Donations and Financial Privacy:
Private Contributions: Individuals can make anonymous donations or payments without exposing their identities or financial details. This is particularly useful for supporting sensitive or controversial causes where privacy is paramount.
Confidential Holdings and Movements: Organizations and individuals can keep their financial holdings and transactions private, preventing unwanted scrutiny and enhancing overall financial security.
Further Reading
FEM forum discussion:
https://ethereum-magicians.org/t/eip-7503-zero-knowledge-wormholes-private-proof-of-burn-ppob/15456
EIP-7007: Verifiable AI-Generated Content Token
The zkML AIGC-NFTs standard expands upon the ERC-721 token standard to support AI-Generated Content. It introduces interfaces for basic and enumerable interactions with AIGC-NFTs, along with a new mint event and a JSON schema for AIGC-NFT metadata. Additionally, the standard integrates zkML capabilities to verify AIGC-NFT ownership, with the tokenId indexed by the prompt.
Why proposed it?
zkML AIGC-NFTs extends the ERC-721 standard to meet the unique needs of AI-Generated Content (AIGC) NFTs using Zero-Knowledge Machine Learning (zkML). It introduces specific interfaces for basic and enumerable interactions, a standardized JSON schema for metadata, and a new mint event to facilitate AI-generated content integration.
The inclusion of zkML ensures secure ownership verification without revealing sensitive information, enhancing privacy and security. Additionally, indexing tokenId by the prompt used for AI content generation organizes tokens more efficiently. This proposal aims to create a specialized, secure, and interoperable framework for AI-generated content NFTs within the Ethereum ecosystem.
Further Reading
FEM forum discussion:
Anecdote of the Week: The Ethereum Blob
Today, the Ethereum network continues to struggle with scalability, an ongoing issue for years. To tackle this, various solutions have been proposed, including network sharding.
Sharding divides the Ethereum network into smaller units, each functioning as an individual blockchain secured by a rotating group of validators. This approach aims to reduce the cost of storing data on the blockchain, thereby improving scalability. However, sharding involves complex upgrades that can pose risks if executed simultaneously.
Proto-danksharding, or EIP-4844, introduces many necessary changes for sharding without fully implementing it. This upgrade introduces "blobs," which are key to Shard Blob Transactions and help scale the Ethereum network.
What Is an Ethereum Blob
Blobs are cost-effective, temporary memory units containing information about transactions, known as blob-carrying transactions. They streamline the verification process by requiring the network to only confirm the attached blob's data, rather than each transaction individually. These blobs often relate to Layer 2 networks like Optimism, which use Ethereum for data storage while benefiting from its security. Blobs are temporary, so they do not occupy space on the Ethereum network indefinitely.
Potential Impact of Ethereum Blobs
Most Layer 2 network fees are for storing data on Ethereum. The introduction of blobs reduces computational effort, leading to faster processing times and lower costs. EIP-4844 will create two separate fee marketplaces: one for Layer 1 execution and another for blobs. This separation ensures that congestion on the Ethereum network does not impact blob fees, maintaining low fees even during peak activity.
The proto-danksharding upgrade, scheduled alongside the Dencun upgrade for later this year, might be postponed to 2024 according to recent communications from core developers. Once EIP-4844 is implemented, Layer 2 networks will also need to upgrade to accommodate and support blobs.
EIP Events
AllWalletDevs #24
Date & Time - June 17, 13:00 UTC
For more details about the meeting agenda, you can join the Discord channel here.
Verkle Implementers Call #19
Date & Time - June 17, 15:00 UTC
For details about the meeting, you can visit this GitHub issue.
EIPIP Meeting #106
Date & Time - June 19, 2024, at 17:30 UTC
For details about the meeting, you can visit this GitHub issue.
AllCoreDevs Execution Layer Meeting #190
Date & Time - June 20, 14:00 UTC
For details about the meeting, you can visit this GitHub issue.
ePBS Breakout room #3
Date & Time - June 21, 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.