For so long, when users want to store some data on the ethereum blockchain is either by storing it using a smart contract or else by making a transaction and including the data as calldata for the transaction. The smart contract method seems a better solution on the first glance, but the gas expenses of smart contract transactions are higher than the regular transactions. And also require more processing time.

For this reason, the high transacting dApps such as layer 2 (rollups) usually batch the transaction using an off-chain batcher (depending on the rollup mechanism) and then publish the proofs using the calldata in order to gain high TPS.

But the cons of using the calldata is that it is expensive as it stores the data on the EVM permanently which is restricting the layer 2 solutions to achieve lower gas prices as the major component of the gas spent on the layer 2 is layer 1 gas fee as described below using a transaction from the MANTLE network.

Here is the transaction https://mantlescan.info/tx/0xb767c13bdb48b2dff067354d2f3c464ebf48c69afff279f0af57904a84249b92

What is BLOB storage ?

To address this problem, EVM has introduced a new storage BLOB object. Blob storage on Ethereum refers to the use of blobs, which are large data packets designed primarily for Layer-2 chains, as a new alternative for data storage within Ethereum blocks. Blobs are approximately 125 kB in size and can be more cost-effective than storing similar amounts of calldata. These blobs are ephemeral, meaning they are only stored for 18 days before being pruned.

What is Proto-Danksharding ?

Proto-Danksharding, also known as EIP-4844(opens in a new tab), is a way for rollups to add cheaper data to blocks. The name comes from the two researchers who proposed the idea: Protolambda and Dankrad Feist. Proto-Danksharding is an intermediate step along the way. Both aim to make transactions on Layer 2 as cheap as possible for users and should scale Ethereum to >100,000 transactions per second.

What is Danksharding ?

Danksharding is the full adaptation of the rollup scaling solution which enables hundreds of individual rollups to make millions of transactions per second.

The way this works is by expanding the blobs attached to blocks from 1 in Proto-Danksharding, to 64 in full Danksharding. The rest of the changes required are all updates to the way consensus clients operate to enable them to handle the new large blobs. Several of these changes are already on the roadmap for other purposes independent of Danksharding. For example, Danksharding requires proposer-builder separation to have been implemented. This is an upgrade that separates the tasks of building blocks and proposing blocks across different validators. Similarly, data availability sampling is required for Danksharding, but it is also required for the development of very lightweight clients that do not store much historical data ("stateless clients").

Why are the blobs only stored for 18 days?

Along with the transaction data, the rollups also post a KZG commitment hash of the blob. The KZG uses cryptography algorithms to generate a commitment of the blob which is deterministic in nature. So, if the original data used to generate the hash has been changed, the commitment produced during block production will be different. By using this, the integrity of the commitment will be tested. We can discuss the architecture of the KZG commit in the next article,

Is EIP 4844 implemented?

The implementation of the EIP 4844 was performed on ETHDenver 2024 and the first transaction was made by Optimism batcher.

Check this link for more information https://etherscan.io/tx/0xa3e36193ab5ca4e6e98848640b1896def4c419ce203e7bd8e876dd2d5eb77e6c

In our upcoming articles, we will understand the fee structure and the KZG commitment process used.