Read

Edit

History

Notify

Share

Danksharding

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

Overview

is one of the most popular networks for 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  chain, significantly reducing its power consumption and opening the door to innovations only possible on networks.

To achieve cheaper and faster transactions, one plan for the network was to implement - a way to reduce network congestion and fees by splitting the massive Ethereum blockchain into smaller partitions. involves physically splitting the into multiple parts. However, sharding can introduce security risks and challenges in data migration.

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

Danksharding introduces a way to communicate with existing Ethereum  solutions, which is much easier to implement than 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 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 , which proposes dividing layer one (L1) into multiple shard chains.
wiki

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 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 , 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 network. The concept was proposed in   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 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 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 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 sizeWorst case block size
Status quo85 kB1.8 MB
EIP-4488Unknown; 350 kB if 5x growth in calldata use1.4 MB
EIP-4844 (Proto-danksharding)1 MB (tunable if desired)2 MB

Blobs and KZG Polynomial Commitment

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 networks, like , which stores data on to share in its security guarantees. The temporary nature of these blobs ensures that they do not perpetually occupy space on the Ethereum network.

will be able to use 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]

are persisted in beacon nodes, not in execution layer (e.g. in prysm, not in geth). Future 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 network are primarily caused by network congestion. This can occur when there are huge numbers of people accessing apps and platforms on the Ethereum network. And Ethereum is the home of the majority of , meaning network congestion is a frequent issue users face.  By allowing the network to process more easily, danksharding will help Ethereum avoid congestion. This will improve gas fees on the wider Ethereum network—not just using a 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, , Danksharding involves validating blob-carrying transactions off-chain. This is a security risk, as less popular 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 . While rollups have security measures to defend against this, they are not as robust as the Ethereum .[2]
See something wrong? Report to us.

Danksharding

Commit Info

Edited By

0xF8bD29570D276c593125205A714D2623B311D2ce
Jaewon

Edited On

March 10, 2024

Feedback

Average Rating

Based on over 2 ratings

How was your experience?

Give this wiki a quick rating to let us know!

Media

REFERENCES

Join the IQ Brainlist

Sign up for the IQ Brainlist to get early access to editing on the IQ.wiki site!

Join Now

Subscribe to our newsletter

The IQ Ecosystem Report will keep you updated on everything IQ.

Subscribe

IQ.wiki

IQ.wiki's vision is to bring blockchain knowledge to the world and knowledge onto the blockchain. A part of Brainfund group

https://twitter.com/IQWIKIhttps://www.reddit.com/r/Everipedia/https://t.me/everipediahttps://www.instagram.com/iqwiki_/https://github.com/EveripediaNetworkhttps://discord.gg/x9EWvTcPXthttps://www.facebook.com/iqdotwiki

IQ

What's IQ?StakingBonds

Company

About usCareersBrandingIQ GPTIQ Dashboard

© 2024 IQ.wiki Powered By BrainDAO & IQ