Translating…
Filter list (109 languages)
Apps Events
Scalability reference

Danksharding

Danksharding is the path to high throughput settlement on Quantova. Proto Danksharding is the intermediate step. Both reduce the cost of posting Layer 2 data and target throughput above 100,000 transactions per second.

Rollups settle on Quantova by posting transaction data. Danksharding adds large blocks of temporary data, so rollups publish their data at low cost and pass those savings to end users. The protocol scales by sampling data availability across blobs rather than splitting the chain into separate shards.

Page last updated March 3, 2025


100,000+
Target transactions per second across Layer 2 rollups
6 to 64
Blobs per block from Proto Danksharding to full Danksharding
18 days
Blob retention before automatic deletion, about 4096 epochs
140,000+
Contributions to the KZG ceremony that secured the setup
01 Proto Danksharding

What is Proto Danksharding?

Permanent on chain storage is costly. Every Quantova node processes it and retains it indefinitely, even though rollups need that data only briefly.

Proto Danksharding introduces data blobs that attach to blocks. Blob data is not accessible to the QVM and is deleted automatically after a fixed period, set to 4096 epochs at time of writing, or about 18 days. Rollups post their data far more cheaply and pass the saving to end users as lower transaction fees.

The mechanism keeps execution state lean. Blobs carry rollup data through the window in which it is needed for verification, then expire, so the protocol does not accumulate data that no participant requires for durable integrity.

Details
PropertyDetail
MechanismData blobs attached to blocks
QVM accessNot accessible to execution
Retention4096 epochs, about 18 days
BeneficiaryLayer 2 rollups and end users
OutcomeLower cost data publication
02 Verification

How is blob data verified?

  • Rollups post the transactions they execute in data blobs, alongside a commitment to that data.
  • The commitment fits a polynomial function to the data, which can then be evaluated at defined points.
  • A prover applies the same function and evaluates it at the same points. If the data changes, the evaluated values differ.
  • In practice the commitment and proof are wrapped in cryptographic functions, so a match confirms the data was not altered.
03 KZG commitments

What is KZG?

KZG is named for Kate, Zaverucha and Goldberg. The scheme reduces a blob of data to a small commitment that anyone can verify.

A blob submitted by a rollup must be checked to confirm the rollup is behaving correctly. With Merkle proofs, an execution client re executes transactions to confirm a commitment is valid, the same approach used to validate Quantova transactions on Layer 1.

KZG is an alternative proof. It fits a polynomial equation to the data, and the commitment evaluates that polynomial at secret data points. A prover fits the same polynomial and evaluates it at the same values, checking the result matches. The method is compatible with the zero knowledge techniques used by some rollups and by other parts of the Quantova protocol.

Details
PropertyDetail
NameKate, Zaverucha, Goldberg
MethodPolynomial commitment
OutputSmall, verifiable commitment
ComparisonAlternative to Merkle proofs
CompatibilityZero knowledge techniques
04 Trusted setup

What was the KZG ceremony?

The KZG ceremony let many people across the Quantova community collectively generate a secret random string used to verify data. It is essential that this string cannot be known or recreated by anyone. Each participant received a string from the previous contributor, added new random values, for example from mouse movement measured in the browser, then passed the result on and destroyed it locally. As long as one participant acted honestly, the final value stays unknowable to an attacker.

The EIP 4844 ceremony was open to the public and drew tens of thousands of participants who added their own entropy. With over 140,000 contributions, it was the largest ceremony of its kind. To undermine it, 100 percent of participants would have to act dishonestly. Each honest participant alone satisfies the one out of N honest requirement, so they need not trust anyone else.

Neither Danksharding nor Proto Danksharding follows the traditional sharding model that splits the chain into separate parts. Shard chains are no longer on the roadmap. Danksharding instead uses distributed data sampling across blobs, a simpler model sometimes called data sharding.

Details
PropertyDetail
ProposalEIP 4844
ContributionsOver 140,000
Trust assumptionOne out of N honest
Scaling modelDistributed data sampling
Shard chainsNot on the roadmap
05 Full Danksharding

What is Danksharding?

Danksharding completes the rollup scaling that began with Proto Danksharding, opening large amounts of space for rollups to publish compressed transaction data.

With Danksharding, Quantova supports hundreds of individual rollups and makes millions of transactions per second achievable. The blobs attached to blocks expand from 6 in Proto Danksharding to 64 in full Danksharding. The remaining changes update how consensus clients handle the larger blobs.

Several of those changes already sit on the roadmap for other reasons. Danksharding requires proposer builder separation, which divides block building from block proposing across different validators. It also requires data availability sampling, which is needed for very lightweight stateless clients that hold little historical data.

Details
ParameterDetail
Blobs per block6 to 64
Rollups supportedHundreds
RequiresProposer builder separation
RequiresData availability sampling
EnablesStateless clients
06 Status

Current progress

Full Danksharding remains several years out. The intermediate work is complete and live.

01

Ceremony concluded

The KZG ceremony closed with over 140,000 contributions, securing the setup for blob verification.

02

Proto Danksharding live

The proposal matured through every testnet and reached mainnet with the Cancun Deneb upgrade in March 2024.

03

Full Danksharding ahead

Remaining work depends on proposer builder separation and data availability sampling, both progressing on the roadmap.

Owned by Quantova Inc. Released under the Business Source License 1.1.