![](/cdn/collaboration-between-neptune-mutual-and-sushiswap.webp)
Collaboration between Neptune Mutual and SushiSwap
Explore Neptune Mutual's ongoing collaboration with SushiSwap offering several benefits.
Youtube Video
Playing the video that you've selected below in an iframe
Understanding sharding, dank-sharding, and proto-danksharding Ethereum EIP-4844 Standard.
The notoriously high gas fees of Ethereum have hampered its widespread adoption. As on-chain activity grows, these fees may rise exponentially, making transactions more expensive than on other networks where gas fees are lower. Prior to the complete implementation of sharding on the Ethereum blockchain, the Ethereum Foundation proposed EIP-4844 as an interim solution to reduce transaction fees and increase throughput in an effort to enhance the user experience.
Sharding is a technique to increase the efficiency and scalability of a blockchain network. It involves dividing the network into smaller units called shards, and letting each shard process the transactions in parallel. This lets the network handle and process more transactions per second and reduces the pressure on individual nodes, making the network faster and more efficient.
Danksharding is a simpler version of sharding that focuses on storing large amounts of data in one place. Layer-2 rollup protocols currently use these sizable amounts of data—called blobs—to support high-throughput transactions. It implements the new concept of a merged fee market. This means that instead of having a fixed number of shards that each have distinct blocks and distinct block proposers, there will be only one proposer who chooses all the transactions and data that go into that slot.
A new system separates the proposer from the builder in order to ensure that the design doesn't force the validators to meet the high system requirements. Block builders are specialized actors who bid on the right to choose the contents of the slot. The proposer only has to choose the valid header with the highest bid. The block builder has to process the whole block. All other validators and users can check and verify the blocks very efficiently through data availability sampling.
Proto-Danksharding is a proposal to implement the majority of the logic and scaffolding that comprise a full Danksharding specification without actually implementing any sharding. The name is derived from the details of the two researchers, Protolambda and Dankrad Feist, who proposed the idea behind it. All validators and users must still directly validate the availability of the full data.
The main feature of proto-danksharding is the addition of a new transaction type known as a blob-carrying transaction. A blob-carrying transaction is similar to a regular transaction, except it also includes an extra piece of data known as a blob. Blobs are extremely large, requiring nearly 125 kB of data, and can be significantly less expensive than comparable amounts of calldata. Blob data, on the other hand, is not accessible to EVM execution; the EVM can only see a commitment to the blob.
Because validators and clients must still download the entire blob, proto-danksharding restricts the data bandwidth to 1 MB per slot rather than the full 16 MB. But, this data is not competing with the gas usage of existing Ethereum transactions; therefore, there are significant scalability improvements.
The EIP-4844 proposal attempts to alleviate the burden on the network of the increasing transaction size by adding roughly 2 MB of space to the blocks. This will provide modest comfort to both the network and the users, who can be sure to be capped with lower gas fees.
Rollups scaling solutions, which currently use calldata, are intended to temporarily relieve the network of its scaling issues, but they will no longer have the option of using calldata in future releases. Sharded data, or blobs, are also super cheap compared to call data, which the blockchain stores permanently. Blobs aren’t permanently stored on the blockchain, as the network removes them after a few weeks. They are invisible to EVM execution, meaning that they only exist on the consensus layer. A single transaction block can hold up to 16 blobs and transfer 1MB of data per 12 seconds.
EIP-4844 also adds execution logic, verification criteria, and fee markets required for full sharding. The final step in achieving full scalability for Ethereum is sharding. The multi-dimensional fee market necessitates the use of two resources: gas and blobs, each with its own floating gas prices and separate limit restrictions. Due to these changes, the block builders must also overcome a difficult situation. Instead of simply accepting transactions with the highest priority fee until they run out of transactions or reach the block gas limit, they must avoid hitting two different limits concurrently.
The data in the blobs is inaccessible to the EVM and is automatically deleted after a fixed time period, say, 1-3 months. Rollups commit transaction data to the blockchain and make the actual data available in data blobs. This means that provers can validate the commitments or challenge data that they believe is incorrect. Blobs of data are stored in the consensus client at the node level. The consensus among clients attests to their having seen the data and that it has spread throughout the network. If the data were to be kept indefinitely, these clients would bloat, resulting in high hardware requirements for running the nodes. Instead, the data is pruned from the node automatically every 1-3 months. The consensus client attestations show that there was enough time and opportunity for the provers to verify data. Rollup operators or users can store the actual data off-chain.
It also necessitates the use of a new cryptographic scheme known as KZG Commitments. KZG is an alternative proof that matches the data to a polynomial equation. It was coined by three researchers, Kate, Zaverucha, and Goldberg, who wrote the paper "Constant-Size Commitments to Polynomials and Their Applications", which outlines the underlying cryptographic mechanism that EIP-4844 intends to use. A prover must re-execute the transactions in the blob to ensure that the commitment was valid. This is conceptually equivalent to how execution clients on layer 1 use Merkel proofs to validate Ethereum transactions.
Full Danksharding is still a couple of years away, but Proto-Danksharding should arrive relatively soon. The KZG ceremony is nearing its completion and has so far attracted a handful of contributors. The EIP for Proto-Danksharding is complete, the specification has been agreed upon, and the clients have built prototypes that are being tested before being deployed on a full production scale.
The Ethereum researchers introduced and tested a full data-blob-transaction prototype, also known as mini-danksharding, at the ETHGlobal event in Denver last year. The same was also introduced and followed up on at the ETH Global event in Denver earlier this month.
With the completion of the Shanghai Upgrade on the Ethereum mainnet, developers are certain that this most anticipated EIP will follow the next-in-line upgrade by the Ethereum Foundation and will likely be slated for the second half of 2023, unless the timeline goes sideways. The readiness checklist for EIP-4844 can also be tracked here.
Reference Sources Danksharding, EIP-4844