Sign In
Learning Center

Danksharding vs. Proto-Danksharding

Proto-danksharding and danksharding are essential elements in the enhancement of the Ethereum consensus layer. The aforementioned technologies are designed to optimize the efficacy and scalability of Ethereum, specifically with respect to layer-2 rollup solutions.

Danksharding is a layer-2 scaling solution that aims to maximize the capabilities of Ethereum, the second most prominent blockchain in the world. Proto-danksharding represents a transitional phase along the roadmap for danksharding. The implementation of proto-danksharding, which was sanctioned as a component of EIP-4844, has been formally integrated into the Ethereum Cancun-Deneb enhancement proposals. 

The Danksharding method In light of increasing user congestion on the Ethereum blockchain, strives to optimize the speed and cost-effectiveness of layer-2 solutions, specifically rollups. Proto-danksharding and danksharding are fundamental to the scaling of Ethereum in the future. Key components of these processes thus far have comprised significant network transitions, such as the phased transition from proof-of-work to proof-of-stake consensus.

register LCX

How Layer-2 Solutions Enhance Blockchain Efficiency and Scalability

Layer 2s augment and fortify the functionalities of foundational layer blockchains, such as Ethereum. Rollups have emerged as a feasible and efficient layer-2 solution for Ethereum.

Layer-2 solutions encompass any supplementary framework or protocol constructed upon an established blockchain, incorporating functionalities that enhance the base chain’s scalability. Layer 2 functions as an independent network layered above the layer 1 base chains, through which transactions are processed and subsequently validated at regular intervals on-chain. 

Layer 2 solutions are capable of processing thousands of transactions at low costs due to design decisions made in the periphery network that optimize the transaction processing capabilities of layer-2 solutions, whereas base Ethereum can only process about 15 transactions per second.

A procedure exists whereby transactions from the off-chain layer 2 are validated by the larger, decentralized base chain, thereby preserving security and decentralization. A layer-2 front-end, such as Arbitrum, enables Blockchain users to engage with a platform that executes transactions considerably faster and at a lower cost than Ethereum.

Along with plasma, sidechains, and validium, rollups constitute a type of layer-2 solution. Transactions are dominated by rollup-based layer 2s such as Optimism and Arbitrum among Ethereum layer 2s. 

Rollups perform transaction execution on a layer 2 layer prior to aggregating the information they contain into a rollup and periodically transmitting it to the mainchain for verification. By distributing fixed costs across numerous transactions, this approach effectively mitigates the financial impact of petroleum price volatility.

Ethereum Scalability and the Evolution of Rollups

As a means of augmenting the scalability of Ethereum, rollups have emerged as a principal solution. Rollups that utilize technologies such as danksharding exemplify a strong endeavor to improve the scalability of Ethereum, diminish transaction expenses, and uphold the network’s fundamental tenets of decentralization and security.

Zero-knowledge rollups (ZK-rollups) and optimistic rollups are the two principal types of rollups that are accessible. At the moment, optimistic rollups are the most widely adopted type of scalability solution for Ethereum. They function in conjunction with the Ethereum blockchain and possess the crucial attribute of being composable.

Optimistic rollups derive their name from the assumption that the off-chain transactions they relocate are legitimate. No on-chain proof of validity exists, and optimistic rollups incorporate the capability to contest transactions in order to uphold security. 

Users may contest an optimistic rollup transaction that they deem to be illegitimate during the challenge period. They have the ability to contest the legitimacy of a transaction through the window by submitting a fraud proof. This proof serves as a mechanism to illustrate the invalidity of a specific transaction or group of transactions. 

The disputer and the sequencer, which functions similarly to a validator in layer 1s in that it submits and orders a block of translation, are both obligated to post a collateral. In the event that an invalid transaction is detected, the sequencer’s bond is decimated. In the event that the transaction is deemed valid despite the invalidity of the fraud proof, the disputer’s bond shall be forfeited. 

ZK-rollups are the second most popular type of rollup. Off-chain transaction cryptographic assurances of validity are published via zero-knowledge rollups. Validity proofs are submitted by operators of ZK-rollup chains to the main chain. These proofs provide cryptographic certainty that the proposed alterations to the state of Ethereum are the result of a collection of valid transactions that were executed off-chain.

Because optimistic rollups are capable of executing smart contracts, they are more popular than ZK rollups. In contrast, ZK-rollups primarily target uncomplicated transactions. 

At this time, rollups post transaction data to the mainnet as calldata, which is an inefficient method of transmitting such data outside of Ethereum. In order to optimize this procedure, proto-danksharding and danksharding are planned.

Introduction of Data Blobs to Ethereum

Data structures and the KZG polynomial commitment scheme are two particular components of danksharding and proto-danksharding that are essential for the optimization of Ethereum’s rollup solutions. These technological components form the basis for augmenting the rollup functionalities of Ethereum.

The fundamental component of the layer-2 scaling danksharding implementation consists of structures. Blobs are sizable data entities specifically engineered to function as components of the transactional framework of Ethereum. Currently, rollups store transaction data in calldata. 

Calldata is unsuitable for rollups due to the fact that any data recorded in it must be permanently processed by all Ethereum nodes and is appended to the blockchain. This permanence is not always required for rollups, as validation and execution of transactions typically only require the data for a limited duration.

Data fragments that are proto-danksharding-compatible and can be appended to transaction blocks will be deleted automatically within one to three months. Blobs, unlike calldata, consist of transactions conveying a 125-kilobyte “blob” payload that is stored on the Ethereum consensus layer rather than the Ethereum Virtual Machine (EVM). This approach facilitates a decrease in storage overhead and enables more economical transmission of data in rollup transactions, resulting in cost reductions for end users in the form of reduced gas fees.

The KZG polynomial commitment scheme, which is named after the scheme’s three original authors (Kate, Zaverucha, and Goldberg), is implemented in proto-danksharding. Data blobs are compressed using KZG into tiny cryptographic commitments. 

KZG employs a cryptographic method that enables the validation of data contained within blobs without requiring direct processing of the entire blob and without disclosing its complete contents.  This is consistent with the zero-knowledge architecture utilized by certain layer-2 protocols, which will eventually be implemented throughout Ethereum scaling. 

Consequently, danksharding represents the epitome of rollups. Rollup transactions can currently affix a single blob to a block using proto-danksharding; danksharding will increase this capacity to 64 blobs. Danksharding is anticipated to provide optimistic rollups with an enormous quantity of space to dump their compressed transaction data. By permitting thousands of transactions per second, Danksharding intends to support an expanding rollup ecosystem.

Danksharding and Proto-Danksharding Challenge the Blockchain Trilemma

It is nearly impossible for a blockchain to strike a balance between decentralization, scalability, and security. Layer 2 optimizations assist in resolving this dilemma. 

Considuousness regarding scalability, decentralization, and security concurrently presents a formidable obstacle for blockchain networks, according to the blockchain trilemma. Vitalik Buterin, co-founder of Ethereum, devised the term because, in his opinion, blockchain platforms can only effectively accomplish two of these three objectives. Blockchains are frequently confronted with the challenge of maintaining transaction throughput and scalability while preserving decentralization and security.

In contrast to conventional financial networks, blockchains operate without the need for intermediaries such as banks to uphold ledgers of transactions and validate them. This operation is carried out by a decentralized network of autonomous computers known as nodes within a blockchain. 

Additionally, a larger number of nodes in a decentralized network contributes to its security. In theory, the greater the number of nodes in a blockchain, the more secure it becomes. A larger network would require a greater investment of computational power from a prospective attacker in order to be taken over via a 51% attack or network takeover. 

As each transaction must be validated across a substantial number of nodes, the scalability of a network is directly impacted by security that is enhanced through greater decentralization. Therefore, as the size of the network increases, a greater quantity of data must be processed by a greater number of participants. 

During periods of network congestion, larger blockchains such as Bitcoin and Ethereum frequently experience transaction costs and delays for end users due to the imposition of an unalterable process mandated by blockchain security models. Scalability has been given precedence in the development of the Ethereum protocol in order to tackle these concerns, particularly in light of the considerable expansion of the network.

Danksharding and Proto-Danksharding Explained
Login @ LCX