Danksharding is an Ethereum rollup scaling method where transactional throughput is increased by providing extra storage space for rollup transactions. Danksharding is a key feature of the second phase of Ethereum’s scaling roadmap called The Surge.^[1]

Overview

Ethereum is one of the most popular networks for blockchain apps, and as such this puts the network under huge amounts of pressure. Hosting many platforms, protocols, apps and tokens slows down its transaction finality and causes exorbitant fees.

To overcome this scalability issue, the Ethereum roadmap includes several upgrades. With the Merge, Ethereum became a proof-of-stake chain, significantly reducing its power consumption and opening the door to innovations only possible on PoS networks.

To achieve cheaper and faster transactions, one plan for the network was to implement sharding \

• a way to reduce network congestion and fees by splitting the massive Ethereum blockchain into smaller partitions. Sharding involves physically splitting the blockchain into multiple parts. However, sharding can introduce security risks and challenges in data migration.

Unlike traditional sharding, Danksharding focuses on improving data availability and efficiency utilizing data blobs and the KZG polynomial commitment scheme to optimize the handling of large data packets, specially for rollups.

Danksharding introduces a way to communicate with existing Ethereum layer 2 solutions, which is much easier to implement than sharding the whole Ethereum network. It also introduces a way to process more data per block, allowing for more complex transactions without slowing down the network or raising its gas fees but making blockchain rollups more efficient. ^[3]

Danksharding is named after Ethereum researcher Dankrad Feist who proposed it. It is an upgrade on the old Ethereum scaling plan called sharding, which proposes dividing layer one (L1) into multiple shard chains.

Danksharding vs. Sharding

Developers had originally planned on scaling Ethereum through sharding, which was going to split the L1 chain into 64 shard chains. Each shard chain would have a unique set of validators and would process transactions individually.

However, as rollups emerged as the way to scale Ethereum, the sharding roadmap was abandoned. The introduction of rollups reduced the need for shard chains as transactions were processed directly on the rollup chain. Moreover, the rollup-centric roadmap was less complicated, more decentralized, and offered better security than shard chains.

Danksharding was introduced to complement Ethereum’s rollup-centric roadmap. The most distinct feature of danksharding is the introduction of temporary data blobs, which will allow rollups to process more data meaning more transactions.^[11]

Proto-danksharing (EIP-4844)

Proto-danksharding is a proposal, which when implemented, would provide the foundations to introduce Danksharding to the Ethereum network. The concept was proposed in Ethereum Improvement Proposal  4844 (EIP-4844), and named after Ethereum researchers Dankrad Feist and Proto Lambda. EIP-4844 is soon due to be implemented as part of Ethereum’s Dencun Upgrade scheduled for March 13th, 2024. 

EIP-4844, or Proto-Danksharding, lays the groundwork for Ethereum’s future by introducing a new type of transaction and a way to store temporary data. ^[2]

Comparison of EIP-4844 with EIP-4488

EIP-4488 (Transaction calldata gas cost reduction with total calldata limit) is an earlier and simpler attempt to solve the same average case / worst case load mismatch problem with two simple rules:

• Calldata gas cost reduced from 16 gas per byte to 3 gas per byte

• A limit of 1 MB per block plus an extra 300 bytes per transaction (theoretical max: ~1.4 MB)

The hard limit is the simplest possible way to ensure that the larger increase in average-case load would not also lead to an increase in worst-case load. The reduction in gas cost would greatly increase rollup use, likely increasing average block size to hundreds of kilobytes, but the worst-case possibility of single blocks containing 10 MB would be directly prevented by the hard limit.

EIP-4844 (Proto-danksharding) instead creates a separate transaction type that can hold cheaper data in large fixed-size blobs, with a limit on how many blobs can be included per block. These blobs are not accessible from the EVM and the blobs are stored by the consensus layer (beacon chain) instead of the execution layer.^[10][9]

	Average case block size	Worst case block size
Status quo	85 kB	1.8 MB
EIP-4488	Unknown; 350 kB if 5x growth in calldata use	1.4 MB
EIP-4844 (Proto-danksharding)	1 MB (tunable if desired)	2 MB

Blobs and KZG Polynomial Commitment

Blobs

Blobs are inexpensive and temporary memory carrying data about transactions, called blob-carrying transactions.

Blobs are designed to make the verification of transactions more efficient. Instead of verifying each transaction in the block, the network will only have to confirm that the blob attached to the block carries the correct data. The transactions in these blob-carrying blocks will typically be related to Layer 2 networks, like Optimism, which stores data on Ethereum to share in its security guarantees. The temporary nature of these blobs ensures that they do not perpetually occupy space on the Ethereum network.

Rollups will be able to use blobs to store their transaction data. This will free up space on the Ethereum main chain and allow rollups to process more transactions at a lower cost. EIP-4844 introduces a new fee market for blobs.^[8]

Blobs are persisted in beacon nodes, not in execution layer (e.g. in prysm, not in geth). Future sharding work only requires changes to the beacon node, enabling the execution layer to work on other initiatives in parallel.^[9]

KZG Polynomial Commitment

KZG polynomial commitments, also known as the Kate-Zaverucha-Groth commitment scheme, is a cryptographic primitive that allows users to commit to a polynomial in a way that is both binding and hiding. This means that the commitment does not reveal any information about the polynomial, and it is impossible to change the polynomial once the commitment has been made.

In the KZG polynomial commitment scheme, the prover first needs to commit to the polynomial p(X) and then submit a proof π, along with his claim p(z) = y.

The commitment can later be opened at any position. The prover shows that the value of the polynomial at a certain position is equal to a claimed value.

KZG polynomial commitment scheme was introduced in 2010. ^[4][5][6][7]

Pros and Cons of Danksharding

Pros of Danksharding

• Reducing Transaction (Gas) Fees
  The first benefit of Danksharding is reduced transaction fees. High gas fees on the Ethereum network are primarily caused by network congestion. This can occur when there are huge numbers of people accessing blockchain apps and platforms on the Ethereum network. And Ethereum is the home of the majority of dApps, meaning network congestion is a frequent issue users face.  By allowing the network to process rollups more easily, danksharding will help Ethereum avoid congestion. This will improve gas fees on the wider Ethereum network—not just using a layer two chain.^[2]

• Faster Transactions
  Another benefit of Danksharding is that it allows Ethereum to process transactions much faster than was previously possible. By introducing a way to store data temporarily, it helps the network’s nodes. Previously, each node would store an entire copy of the blockchain’s history which is a heavy burden. With Danksharding, the nodes store and process much less data, allowing them to work more efficiently. This means that user's transactions become much faster.^[2]

Cons of Danksharding

• Security
  While Danksharding may be the answer to Ethereum’s scalability concerns, there are some concerns about its security. While this method is much easier to implement on the network than the previous plan, sharding, Danksharding involves validating blob-carrying transactions off-chain. This is a security risk, as less popular rollups may become targets for bad actors. The smaller and less experienced the chain, the easier it is to attack. This could mean that blob-carrying transactions from malicious sources could end up on the Ethereum mainnet. While rollups have security measures to defend against this, they are not as robust as the Ethereum mainnet.^[2]