Ethereum's widely known steep gas fees have impeded its broad acceptance. As activities on the blockchain increase, these fees could surge exponentially, resulting in transactions becoming pricier compared to networks with lower gas fees. In anticipation of the full integration of sharding into the Ethereum blockchain, the Ethereum Foundation introduced EIP-4844 as an interim measure to lower transaction costs and boost throughput, aiming to enrich the overall user experience.
Danksharding
Sharding is a method employed to enhance the efficiency and scalability of a blockchain network. It entails partitioning the network into smaller entities known as shards, enabling each shard to concurrently process transactions. This approach enables the network to manage and execute a higher number of transactions per second, alleviating strain on individual nodes and consequently augmenting the network's speed and efficiency.
Danksharding simplifies the concept of sharding by concentrating on centralized storage for substantial data volumes. These data collections, termed "blobs," are harnessed by Layer-2 rollup protocols to facilitate high-throughput transactions. A novel merged fee market is introduced within Danksharding's framework. Unlike a fixed number of shards, each with distinct blocks and block proposers, a sole proposer is responsible for selecting all transactions and data for a designated slot.
A fresh system introduces a segregation of roles between proposers and builders to ensure that the design doesn't compel validators to meet demanding system prerequisites. Block builders, specialized entities, vie for the opportunity to curate slot contents through bidding. The proposer's role is confined to selecting the valid header with the highest bid, while the block builder assumes the responsibility of processing the entire block. All other validators and users can efficiently verify blocks through data availability sampling.
Proto-Danksharding
Proto-Danksharding constitutes a proposal aimed at incorporating the primary logic and framework that underlie a complete Danksharding specification, all without the actual implementation of sharding itself. The name derives from the combined contributions of two researchers, Protolambda and Dankrad Feist, who initially conceptualized this notion. It remains essential for all validators and users to directly verify the availability of the comprehensive data set.
The central hallmark of proto-danksharding is the introduction of a novel transaction type termed a "blob-carrying transaction." Functioning akin to a conventional transaction, a blob-carrying transaction possesses an additional data component referred to as a "blob." Blobs, characterized by their substantial size, necessitate nearly 125 kB of data and can prove notably more cost-effective than equivalent calldata quantities. However, it's important to note that blob data remains beyond the purview of EVM execution; the EVM is exclusively privy to a commitment regarding the blob's existence.
Given that validators and clients are still required to retrieve the entire blob, proto-danksharding enforces a data bandwidth constraint of 1 MB per slot, as opposed to the complete 16 MB. Notably, this data bandwidth doesn't vie with the gas consumption associated with prevailing Ethereum transactions. Consequently, considerable scalability enhancements are realized.
Features and Benefits
The EIP-4844 proposition seeks to ease the strain on the network caused by growing transaction sizes, achieved by introducing an approximate addition of 2 MB of space to the blocks. This adjustment offers a modest relief to both the network and its users, providing them with the assurance of reduced gas fees.
Rollup scaling solutions, which currently rely on calldata, are designed as a temporary remedy to address the network's scaling challenges. However, future releases of these solutions will no longer feature the option to utilize calldata. In contrast, sharded data, referred to as blobs, offer an extremely cost-effective alternative to calldata, which the blockchain permanently retains. Blobs, distinct from calldata, are not stored on the blockchain indefinitely; they are purged from the network after a span of a few weeks. Importantly, they remain imperceptible within EVM execution, exclusively existing within the consensus layer. A single transaction block can accommodate up to 16 blobs, facilitating the transfer of 1MB of data every 12 seconds.
EIP-4844 introduces essential elements, encompassing execution logic, verification criteria, and fee market mechanisms, necessary for the eventual realization of full sharding. The culmination of Ethereum's journey towards complete scalability hinges on the implementation of sharding. A multi-dimensional fee market introduces the requirement for two resources: gas and blobs, each characterized by its own dynamic gas prices and distinct limitations. Consequently, block builders are faced with a more complex scenario. Rather than solely prioritizing transactions based on the highest fees until exhausting transactions or reaching the block gas limit, they must navigate the challenge of avoiding the simultaneous constraint of two separate limits.
Data contained within blobs remains inaccessible to the EVM and is subject to automatic deletion after a predetermined period, typically ranging from 1 to 3 months. Rollups commit transaction data to the blockchain, while the actual data is made available within data blobs. This setup empowers provers to validate commitments and potentially challenge data they deem erroneous. Blobs storing data are maintained at the node level within the consensus client. Attestations from consensus clients signify their exposure to the data and its dissemination throughout the network. To prevent node bloat and alleviate hardware requirements for running nodes, the data is pruned from nodes automatically every 1-3 months. The consensus client attestations corroborate that provers had ample time and opportunity to verify the data. Rollup operators or users retain the capacity to store the actual data off-chain.
Furthermore, this introduces the requirement for the adoption of a novel cryptographic framework referred to as KZG Commitments. KZG, which stands for Kate, Zaverucha, and Goldberg, presents an alternate proof that aligns data with a polynomial equation. The term originates from the work of the three researchers who authored the paper "Constant-Size Commitments to Polynomials and Their Applications," outlining the foundational cryptographic mechanism that EIP-4844 seeks to employ. A prover is obliged to reexecute transactions within the blob, ensuring the authenticity of the commitment. This mirrors the conceptual similarity to how execution clients in Layer 1 employ Merkel proofs to validate Ethereum transactions.
Roadmap
Although full Danksharding is still a few years down the road, the advent of Proto-Danksharding is relatively imminent. The KZG ceremony is in the final stages of completion and has garnered participation from several contributors. The EIP for Proto-Danksharding has reached its final form, the specification has achieved consensus, and clients have developed prototypes that are currently undergoing testing before their full-scale deployment.
During last year's ETH Global event in Denver, Ethereum researchers introduced and evaluated a complete data-blob-transaction prototype, referred to as mini-danksharding. The same concept was also introduced and followed up at this year's ETH Global event in Denver.
