EIP-4844: A Technical Deep Dive into Proto-Danksharding and Ethereum’s Scalability Leap

Ethereum’s long-awaited Dencun upgrade, live on mainnet since March 2024, marks a pivotal moment in the network’s evolution. At the heart of this upgrade lies EIP-4844, also known as Proto-Danksharding—a foundational step toward scalable, decentralized Layer 2 (L2) solutions. This proposal introduces a novel data structure called blobs to drastically reduce L2 transaction costs while laying the groundwork for future full sharding.

By optimizing data availability and storage efficiency, EIP-4844 sets the stage for Ethereum to support thousands of transactions per second across multiple rollups—without compromising decentralization or security. Let’s explore how this transformative upgrade works, why it matters, and what it means for the future of Ethereum scalability.

What Is EIP-4844?

EIP-4844 introduces blob-carrying transactions, a new type of Ethereum transaction designed specifically for Layer 2 rollups. These transactions carry large volumes of temporary data called blobs (Binary Large Objects), which are cheaper to store than traditional calldata but still ensure data availability.

The key innovation? The EVM does not execute or read blob data. Instead, it verifies their integrity through cryptographic commitments—specifically KZG commitments—ensuring that data is available off-chain without bloating the main Ethereum ledger.

👉 Discover how next-gen blockchain scaling is unlocking faster, cheaper transactions

This makes EIP-4844 a "proto" version of full Danksharding, preparing the network for future horizontal scaling by implementing core components now—like new transaction formats, gas mechanics, and consensus-layer sidecars—while deferring complex features like data sampling.

Why Was EIP-4844 Needed?

Despite the rise of rollups, many users still face high fees. Why?

Because current Layer 2 solutions publish their transaction data on Layer 1 via calldata, which is expensive. Calldata is designed for small, permanent smart contract inputs—not massive batches of L2 transactions.

The Problem with Calldata

Each byte in calldata costs 16 gas under EIP-1559.
With block gas limits around 30 million, max calldata capacity is roughly 1.875 MB per block.
As L2 adoption grows, this bottleneck inflates costs.

While full data sharding will eventually provide dedicated 16 MB of data space per block, it's years away due to complexity and security requirements.

Enter Proto-Danksharding: an interim solution that mimics the final sharding architecture but limits blob storage to ~0.375 MB per block (target) and up to ~0.75 MB (maximum)—enough to slash L2 fees today while keeping network load manageable.

Core Components of EIP-4844

1. Blob Data Structure

A blob is a ByteVector of size:

FIELD_ELEMENTS_PER_BLOB × BYTES_PER_FIELD_ELEMENT = 4096 × 32 = 131,072 bytes ≈ 0.125 MB

Each blob can carry up to 131 KB of L2 transaction data. A single block can include up to six blobs, totaling about 786 KB.

Blob Lifecycle

Blobs are stored temporarily as sidecar data, separate from the beacon chain block body.
Nodes must retain blob data for at least 4096 epochs (~18.2 days).
After this period, nodes may delete them—reducing long-term storage pressure compared to calldata.

This temporary retention satisfies rollup security models, where honest actors need only verify data within a challenge window (e.g., 7 days for Optimistic Rollups).

2. Blob-Carrying Transactions

These are a new transaction type (TransactionType = 0x03) compliant with EIP-2718 (typed transactions). They include both standard EVM fields and new blob-specific parameters:

Field	Description
`max_fee_per_blob_gas`	Max fee user pays per unit of blob gas
`blob_versioned_hashes`	List of versioned hashes derived from KZG commitments

Unlike regular transactions, blob transactions cannot create contracts (to field cannot be null).

Each transaction references one or more blobs via versioned hashes, allowing execution-layer contracts to verify data integrity without accessing raw content.

3. Blob Gas Mechanism

A separate blob gas market operates alongside the traditional gas system:

Constant	Value	Purpose
`GAS_PER_BLOB`	131,072	Cost per blob
`TARGET_BLOB_GAS_PER_BLOCK`	393,216 (3 blobs)	Target usage
`MAX_BLOB_GAS_PER_BLOCK`	786,432 (6 blobs)	Hard limit

Blob base fee adjusts dynamically using an exponential formula similar to EIP-1559:

blob_base_fee = MIN_BLOB_BASE_FEE * e^(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)

Where:

MIN_BLOB_BASE_FEE = 1 wei
BLOB_BASE_FEE_UPDATE_FRACTION = 3,338,477

This ensures stable pricing: if demand exceeds target, fees rise exponentially until usage drops.

Importantly, blob gas fees are burned, just like base fees—aligning economic incentives and reducing inflationary pressure.

4. Block Header Extensions

Two new fields are added to the block header:

blob_gas_used: Total blob gas consumed in the block
excess_blob_gas: Rolling surplus above target, used to compute next block’s base fee

These values are calculated based on parent block data:

def calc_excess_blob_gas(parent):
    surplus = parent.excess_blob_gas + parent.blob_gas_used - TARGET_BLOB_GAS_PER_BLOCK
    return max(0, surplus)

This mechanism enables smooth fee adjustment across blocks, independent of network congestion patterns.

5. Execution Layer Verification: BLOBHASH Opcode

A new opcode, BLOBHASH (0x49), allows smart contracts to access versioned hashes of blobs included in a block.

Usage:

bytes32 hash = BLOBHASH(index);

If the index is valid, it returns the corresponding blob_versioned_hashes[index]. Otherwise, returns zero.

Gas cost: only 3 units, making it efficient for rollups to validate data roots.

6. Point Evaluation Precompile

At address 0x0A, a precompiled contract enables verification of KZG proofs, proving that a specific value exists within a blob at a given point.

Input format (192 bytes):

versioned_hash: Commitment identifier
z: Evaluation point (x-coordinate)
y: Expected output (p(z) = y)
commitment: KZG commitment
proof: Cryptographic proof

The precompile:

Confirms the commitment maps to the provided versioned hash
Validates the KZG proof using verify_kzg_proof()

Gas cost: 50,000 units

This feature is critical for:

ZK Rollups linking blob data to their internal proofs
Optimistic Rollups verifying fraud proofs incrementally

7. Consensus and Network Layer Changes

Blobs are transmitted as sidecars, decoupled from beacon blocks. This design supports future data availability sampling (DAS), where light clients randomly sample parts of blobs to confirm availability—without downloading everything.

Key benefits:

Reduces load on full nodes
Enables scaling to larger data sets
Maintains decentralization

Nodes do not automatically propagate blob transactions. Instead:

Only transaction hashes are gossiped via NewPooledTransactionHashes
Full data fetched on-demand via GetPooledTransactions

This prevents bandwidth abuse and mitigates DoS risks.

How Rollups Benefit from EIP-4844

Optimistic Rollups

Previously relied entirely on calldata for state commitments. Now:

Submit batch data via blobs → lower cost
During fraud proof challenge:
- Load individual values from blob using BLOBHASH
- Provide KZG proof for each value
- Use point evaluation precompile to verify correctness

Result: Cheaper submission + secure dispute resolution.

ZK Rollups

Can now submit two commitments:

Blob commitment (enforced by Ethereum protocol)
Internal ZK proof commitment

Using the point evaluation precompile, they prove equivalence between both commitments—ensuring that the ZK proof refers to the same data published on L1.

👉 See how cutting-edge rollups are leveraging EIP-4844 for ultra-low-cost DeFi

Security & Performance Considerations

Bandwidth Impact

Max theoretical increase: +0.75 MB/block, about 40% more than current calldata limits (~1.875 MB). However:

Blob data is temporary (~18 days)
No need for archival nodes to store indefinitely
Static slot times (12s) allow predictable propagation

Memory Pool Risks

Blob transactions are large and could overwhelm mempools. Mitigations include:

Delayed fetch model (announce first, request later)
EIP-5793: Enhanced announcements with size/type metadata
Replacement rule requiring 1.1× blob base fee bump

These reduce spam risk and give nodes control over resource usage.

Future Outlook: From Proto-Danksharding to Full Sharding

EIP-4844 isn’t the end—it’s the beginning.

It implements nearly all execution-layer logic needed for full Danksharding:

Transaction format compatibility
Cross-layer validation
Sidecar-based data transmission
Independent blob fee market

Future upgrades will add:

Data availability sampling (DAS)
PBS (Proposer/Builder Separation) for handling large payloads
Per-validator responsibility for shard segments

Eventually, Ethereum could support 16 MB of shard data per block, increasing L2 throughput by orders of magnitude.

Additionally, EIP-4844’s cleaner fee logic may inspire improvements to primary gas pricing—paving the way for broader protocol refinements.

Frequently Asked Questions (FAQ)

Q: What is the main goal of EIP-4844?

A: To reduce Layer 2 transaction costs by introducing low-cost, temporary data storage (blobs) while preparing Ethereum for full sharding.

Q: How much cheaper will L2 transactions become?

A: Estimates suggest cost reductions of 5–50x, depending on rollup implementation and network conditions.

Q: Are blobs stored forever?

A: No. Nodes only need to retain blob data for ~18 days. After that, deletion is allowed—unlike permanent calldata.

Q: Can any dApp use blob transactions?

A: Not directly. Only rollups and protocols that batch transactions benefit most. General dApps still use standard transactions.

Q: What happens if a node loses blob data?

A: As long as enough nodes preserve it during the availability window (~18 days), data remains recoverable. Long-term loss doesn’t affect consensus safety due to temporary nature.

Q: Does EIP-4844 compromise decentralization?

A: No. By limiting initial blob count and using sidecars, it balances performance with node operability—ensuring even modest hardware can participate.

Conclusion

EIP-4844 represents a major leap forward in Ethereum’s scalability roadmap. By introducing blobs, it delivers immediate relief to Layer 2 users through dramatically lower fees—while seamlessly aligning with the long-term vision of full Danksharding.

It proves that Ethereum can evolve incrementally: solving real-world problems today without sacrificing architectural integrity tomorrow.

As rollups adopt this new standard, we’ll see explosive growth in on-chain activity—from gaming and social platforms to mass-market financial applications—all powered by a more efficient, accessible Ethereum base layer.

The era of affordable, scalable blockchain is no longer a promise—it's here.

👉 Stay ahead of Ethereum’s evolution with tools built for tomorrow’s Web3

Core Keywords:
EIP-4844, Proto-Danksharding, blob transactions, Ethereum scalability, Layer 2 rollups, data availability, Dencun upgrade