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
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.
| Property | Detail |
|---|---|
| Mechanism | Data blobs attached to blocks |
| QVM access | Not accessible to execution |
| Retention | 4096 epochs, about 18 days |
| Beneficiary | Layer 2 rollups and end users |
| Outcome | Lower cost data publication |
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.
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.
| Property | Detail |
|---|---|
| Name | Kate, Zaverucha, Goldberg |
| Method | Polynomial commitment |
| Output | Small, verifiable commitment |
| Comparison | Alternative to Merkle proofs |
| Compatibility | Zero knowledge techniques |
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.
| Property | Detail |
|---|---|
| Proposal | EIP 4844 |
| Contributions | Over 140,000 |
| Trust assumption | One out of N honest |
| Scaling model | Distributed data sampling |
| Shard chains | Not on the roadmap |
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.
| Parameter | Detail |
|---|---|
| Blobs per block | 6 to 64 |
| Rollups supported | Hundreds |
| Requires | Proposer builder separation |
| Requires | Data availability sampling |
| Enables | Stateless clients |
Current progress
Full Danksharding remains several years out. The intermediate work is complete and live.
Ceremony concluded
The KZG ceremony closed with over 140,000 contributions, securing the setup for blob verification.
Proto Danksharding live
The proposal matured through every testnet and reached mainnet with the Cancun Deneb upgrade in March 2024.
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.