What is Proto-Danksharding?

Proto-Danksharding is an Ethereum scaling upgrade introduced through EIP-4844 that created a dedicated, temporary data storage mechanism for rollups. It is considered the first major implementation stage on the path towards Danksharding, Ethereum’s broader approach to scaling data availability for Layer 2 networks.

Proto-Danksharding went live on Ethereum mainnet as part of the Dencun upgrade on 13 March 2024. Its most visible innovation was the introduction of blob-carrying transactions. Blobs, short for Binary Large Objects, allow rollups to publish large batches of data to Ethereum without placing all of that information permanently in conventional transaction calldata.

The upgrade did not implement full Danksharding. Instead, EIP-4844 introduced several components needed for Ethereum’s longer-term data availability architecture, including blobs, KZG commitments and a separate blob fee market. This gave rollups an immediate way to reduce data publication costs while allowing Ethereum developers to introduce more advanced data scaling mechanisms gradually.

Proto-Danksharding is therefore both a working scaling technology and an intermediate architectural step. It already provides dedicated data capacity to Layer 2 networks, while its design anticipates an Ethereum ecosystem in which considerably more rollup data can be processed without requiring every node to download and permanently store all of it.

Why Ethereum Needed Proto-Danksharding

Ethereum’s scaling strategy increasingly relies on rollups. Networks based on optimistic and zero-knowledge rollup technology execute transactions outside Ethereum’s main execution environment and use Layer 1 for functions such as settlement and data availability.

This architecture reduces the amount of computation Ethereum must perform directly. However, it creates another requirement: rollups must publish enough transaction data for independent participants to verify their state. Without accessible data, users could be forced to trust the Layer 2 operator’s version of what happened.

Before EIP-4844, rollups generally published batches using Ethereum calldata. Calldata is useful because it becomes part of the blockchain and is available for smart contract execution, but it was not specifically designed for the enormous volume of data that a mature rollup ecosystem could generate.

Using calldata also means competing for resources with ordinary Ethereum activity. Token transfers, decentralised exchange trades, NFT operations, lending transactions and rollup batches can all contribute to demand for Ethereum block space.

More importantly, rollup batch data does not necessarily need the same permanent storage properties as ordinary blockchain history. It must remain available long enough for network participants to retrieve and verify it, but Ethereum does not need to require every node to preserve every rollup batch indefinitely.

Proto-Danksharding introduced a specialised data resource designed around this requirement. Instead of treating all rollup information as permanent calldata, Ethereum can make blob data available temporarily and allow it to be pruned later.

How EIP-4844 and Blobs Work

EIP-4844 introduced a new transaction format known as a blob-carrying transaction. The transaction itself is processed by Ethereum, but the attached blobs are handled differently from ordinary calldata.

A blob contains 4,096 field elements of 32 bytes each, giving it a nominal size of 131,072 bytes, or 128 KiB. Rather than making the entire blob directly accessible to the Ethereum Virtual Machine, the protocol uses cryptographic commitments to connect the transaction to its blob data.

Ethereum uses KZG commitments, named after researchers Aniket Kate, Gregory Zaverucha and Ian Goldberg. These polynomial commitments make it possible to verify relationships involving blob data without placing the complete data directly inside EVM execution.

A simplified Proto-Danksharding workflow looks like this:

1. A Layer 2 rollup processes a batch of user transactions outside Ethereum Layer 1.
2. The rollup encodes the required transaction information into one or more blobs.
3. A blob-carrying transaction referencing the blob data is submitted to Ethereum.
4. Ethereum validators make the blobs available and verify the associated cryptographic commitments.
5. Rollup participants can download the data to reconstruct and verify Layer 2 activity.
6. After the protocol’s required availability period, nodes are permitted to prune the blob data instead of storing it indefinitely.

Smart contracts cannot simply read arbitrary blob contents in the same way that they read calldata. The EVM can access information related to blob commitments through the mechanisms provided by EIP-4844, but the bulk data exists primarily to provide data availability rather than general-purpose contract storage.

This distinction is what allows Ethereum to treat blobs as a specialised and potentially much larger resource.

Proto-Danksharding vs Full Danksharding

The name “Proto-Danksharding” can create the impression that Ethereum already uses full Danksharding on a smaller scale. The relationship is more specific. EIP-4844 introduced important parts of the future architecture but not all of the mechanisms required for much larger data throughput.

One of the most important differences concerns how nodes handle data. Simply increasing the number of blobs indefinitely would increase bandwidth requirements and eventually make running Ethereum infrastructure more demanding.

The longer-term solution is not just “more blobs”. Ethereum needs mechanisms that allow the network to verify data availability without requiring every node to download all available data.

This is where data availability sampling becomes important. Instead of downloading an entire dataset, nodes can sample portions of it. With appropriate cryptographic and networking mechanisms, enough independent samples can provide strong confidence that the complete data is available across the network.

PeerDAS, or Peer Data Availability Sampling, has become a major part of Ethereum’s roadmap towards increasing blob throughput. It develops the data availability architecture beyond the initial Proto-Danksharding implementation.

Blob Gas and the Economics of Proto-Danksharding

Proto-Danksharding did more than create a new place to put data. EIP-4844 also established a separate fee market for blob capacity.

Before blobs, rollup data posted through calldata consumed resources priced through Ethereum’s normal execution gas system. With EIP-4844, blob space is priced separately using blob gas. This means demand for Layer 2 data availability can develop its own market rather than being priced exactly like ordinary EVM computation.

The blob fee mechanism adjusts according to utilisation. Persistent demand above the protocol’s target increases the cost of blob space, while lower utilisation allows the price to decline. This is conceptually similar to the adaptive pricing principles introduced for Ethereum execution through EIP-1559, although blob gas is a separate resource.

The system provides several practical benefits:

• rollups receive a data resource specifically designed for publishing transaction batches;
• blob demand is priced separately from ordinary Ethereum execution;
• temporary data availability is cheaper to provide than requiring permanent EVM-accessible storage;
• Ethereum can increase blob capacity through later upgrades as networking technology improves;
• Layer 2 fees become less dependent on the cost of calldata.

The cost reduction can be significant, but Proto-Danksharding does not guarantee permanently cheap Layer 2 transactions. Blob space is scarce and its price responds to demand. If many rollups compete for the available capacity, blob fees can rise.

Layer 2 networks also have costs beyond Ethereum data availability. Sequencing, proof generation, infrastructure, execution and profit margins can all affect the final transaction fee paid by a user.

What Proto-Danksharding Changed for Layer 2 Networks

The impact of EIP-4844 was particularly important because it addressed one of the largest recurring expenses for Ethereum rollups. Before Dencun, publishing transaction batches to Layer 1 could account for a substantial portion of a rollup’s operating costs.

After the introduction of blobs, networks could migrate batch data away from conventional calldata and use the new dedicated data availability resource. Major optimistic and zero-knowledge rollups subsequently adopted blob transactions as part of their Ethereum settlement infrastructure.

The importance of this change extends beyond lower fees. Proto-Danksharding created a clearer division of responsibilities within Ethereum’s rollup-centric architecture.

Layer 2 networks can specialise in transaction execution. Ethereum provides consensus, settlement and data availability. Blobs act as an efficient data channel connecting these two layers without forcing Ethereum’s execution environment to permanently process and store every byte generated by Layer 2 activity.

Proto-Danksharding also makes future scaling more incremental. Ethereum did not need to introduce the maximum possible data capacity in a single upgrade. Developers could first deploy the transaction format, commitments and fee market, observe how the network handled blobs, and then increase capacity as supporting technologies matured.

From Proto-Danksharding to Ethereum’s Data Availability Future

Proto-Danksharding is sometimes described primarily as an upgrade that made Layer 2 transactions cheaper. That was an important immediate result, but its architectural role is broader.

Ethereum is attempting to support an ecosystem in which most routine transactions can occur on rollups while Layer 1 remains the common security and settlement foundation. If Layer 2 networks eventually process vastly more transactions than Ethereum Layer 1, the amount of data they generate can become enormous.

Requiring every Ethereum node to download and permanently preserve all of that data would undermine scalability. Proto-Danksharding begins solving the problem by separating temporary rollup data from permanent execution data.

The long-term roadmap builds on several ideas established or enabled by EIP-4844: dedicated blob space, cryptographic commitments, adaptive data pricing and increasingly sophisticated data availability mechanisms. Future improvements can increase the amount of rollup data Ethereum supports without requiring a proportional increase in resources from every node.

For users, Proto-Danksharding is largely invisible. A person using an Ethereum Layer 2 does not normally create blobs manually or interact with KZG commitments. They experience the technology indirectly through the fees, capacity and performance of the rollup.

For Ethereum itself, the change is fundamental. Proto-Danksharding transformed Layer 2 data from an improvised use of calldata into a dedicated protocol resource. That makes EIP-4844 not only a major scaling upgrade in its own right, but also a foundation for Ethereum’s longer-term transition towards much higher data availability and rollup throughput.