EIP-4844, also known as Proto-Danksharding, is an Ethereum Improvement Proposal that introduces blob-carrying transactions. These transactions attach large, temporary data chunks—called blobs—that are not stored permanently by the Ethereum Virtual Machine (EVM). The EVM can only reference a cryptographic commitment to the blob's content, drastically reducing the gas costs associated with posting rollup transaction data to the Layer 1 blockchain.
Glossary
EIP-4844
An Ethereum Improvement Proposal introducing blob-carrying transactions for temporary data storage, a precursor to full danksharding designed to reduce rollup data costs.
PROTO-DANKSHARDING
What is EIP-4844?
EIP-4844 introduces a new transaction type that carries temporary data blobs, significantly reducing the cost of Layer 2 rollup data posting to Ethereum.
The core mechanism relies on a KZG polynomial commitment scheme to generate a succinct proof of the blob's data. Blobs are pruned from consensus layer nodes after approximately 18 days, ensuring blockchain state bloat is minimized. This architecture serves as a critical precursor to full danksharding, establishing the data availability sampling infrastructure necessary for Ethereum's long-term scalability roadmap.
EIP-4844
Key Features of Proto-Danksharding
EIP-4844 introduces a new transaction type that carries temporary data blobs, decoupling data availability from execution to dramatically reduce costs for Layer 2 rollups.
01
Blob-Carrying Transactions
A new transaction format that attaches large data chunks—blobs—up to ~128 KB each. Unlike CALLDATA, blobs are not accessible to the EVM during execution. They are propagated separately by the consensus layer and pruned after a fixed window (~18 days), ensuring the chain does not retain unnecessary historical data permanently.
02
Decoupled Fee Market
EIP-4844 introduces a multi-dimensional fee market with a new gas type for blob data, separate from standard EVM execution gas. This prevents rollup data posting from competing directly with regular transactions for block space. Key mechanics:
- Blob Gas: A distinct resource tracked per block with its own target and maximum limits.
- EIP-1559-style pricing: A base fee adjusts dynamically based on blob gas utilization, targeting a specific number of blobs per block.
03
KZG Polynomial Commitments
Blob data is committed to using the KZG (Kate-Zaverucha-Goldberg) polynomial commitment scheme. This cryptographic primitive binds the prover to a specific polynomial representing the blob data. Key properties:
- Constant-size proofs: Verification proofs are tiny, regardless of the blob size.
- Vector commitments: Enables efficient proofs that specific data chunks exist within the blob.
- Trusted setup: Requires a one-time multi-party computation ceremony, which Ethereum completed in 2023 with over 140,000 participants.
04
Data Availability Sampling Readiness
Proto-danksharding lays the groundwork for full Data Availability Sampling (DAS). By structuring data into blobs with polynomial commitments, the architecture allows light nodes to probabilistically verify that all blob data is available without downloading entire blobs. This is the critical scalability primitive that will enable full danksharding, where the network can support hundreds of data blobs per block.
05
Rollup Cost Reduction
The primary practical impact is a 10-100x reduction in data posting costs for Layer 2 rollups. Before EIP-4844, rollups posted compressed transaction data to CALLDATA, paying standard execution gas. With blobs:
- Optimism & Arbitrum: Post compressed batch data to blobs at a fraction of the cost.
- ZK-Rollups: Post state diffs and validity proofs alongside blob data.
- End-user fees: Gas costs on L2s dropped from dollars to cents immediately after activation.
06
Temporary Data Pruning
Unlike permanent chain data, blobs are ephemeral storage with a finite lifetime. Consensus nodes retain blob data for approximately 4096 epochs (~18 days) before pruning. This design choice is critical for scalability—nodes do not bear the burden of storing historical rollup data indefinitely. After pruning, only the KZG commitment hash remains on-chain, preserving the cryptographic proof that the data existed without the storage overhead.
SCALING COMPARISON
EIP-4844 vs. Full Danksharding
A technical comparison of the current Proto-Danksharding implementation against the future Full Danksharding specification, highlighting key differences in data availability, consensus overhead, and validator requirements.
| Feature | EIP-4844 (Proto-Danksharding) | Full Danksharding |
|---|---|---|
Blob Count per Block | Target 3, Max 6 | Target 64, Max 128 |
Data Throughput | ~0.375 MB per slot | ~16 MB per slot |
Data Availability Sampling (DAS) | ||
Validator Requirement | Download all blobs in attested block | Sample random blob fragments |
KZG Commitment Usage | Polynomial commitments to blob data | Polynomial commitments to blob data |
Blob Pruning Window | ~18 days (4096 epochs) | TBD (likely shorter with DAS) |
Consensus Layer Overhead | Moderate (blobs coupled to beacon blocks) | Minimal (decoupled verification via DAS) |
Network Upgrade Complexity | Single hard fork (Cancun-Deneb) | Multiple phased upgrades |
EIP-4844 & PROTO-DANKSHARDING
Frequently Asked Questions
Clear, technical answers to the most common questions about Ethereum's blob-carrying transactions and their role in scaling rollups.
EIP-4844, also known as Proto-Danksharding, is an Ethereum Improvement Proposal that introduces a new transaction type carrying large, temporary data packets called blobs. These blobs are stored on the consensus layer for a short, fixed period (approximately 18 days) and are not executed by the Ethereum Virtual Machine (EVM). The mechanism works by attaching up to 6 blobs to a transaction, each with a maximum size of 128 KB, which are referenced by a KZG polynomial commitment in the execution layer. This design drastically reduces the cost of posting data for Layer 2 rollups because they compete in a separate, cheaper fee market (blob_gas) rather than the permanent, expensive CALLDATA storage. After the retention window, the blob data is pruned, ensuring the blockchain state does not bloat indefinitely while still providing enough time for validators and data availability sampling networks to verify the data's existence.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.
Enterprise searchRAGPermissions
Read more
Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.
AI agentsWorkflow automationGovernance
Read more
Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
AI integrationDecision supportModel routing
Read more
About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
LinkedIn
Limited slotsGet a Free AI Consultation
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us