Ethereum Sharding Implementation: Why the Plan Changed to Danksharding

Ethereum Sharding Implementation: Why the Plan Changed to Danksharding Jul, 12 2026

You’ve probably heard that Ethereum was going to solve its congestion problems by splitting itself into pieces. That idea is called Ethereum sharding, and for years, it was the holy grail of the network’s roadmap. But if you look at the code today, you won’t find the classic sharding implementation everyone predicted in 2021. The plan changed. In fact, it changed dramatically.

As of mid-2026, the original vision of 64 separate chains running in parallel has been shelved. Instead, the community pivoted toward a strategy centered on Layer 2 rollups and a new data availability mechanism known as Danksharding. This shift wasn’t a failure; it was a strategic retreat to prioritize security and simplicity. Understanding this change is crucial for anyone building on or investing in Ethereum, because the way transactions are processed-and how cheap they become-depends entirely on this new architecture.

The Original Vision: How Classic Sharding Was Supposed to Work

To understand where we are, we have to look at where we were headed. The original Ethereum sharding proposal aimed to divide the network into 64 independent shard chains, each processing its own subset of transactions and state. Imagine a single highway with one lane (the current mainnet) versus a massive interstate with 64 lanes. In theory, every lane could handle traffic simultaneously, multiplying the network’s throughput from roughly 15-30 transactions per second (TPS) to potentially over 100,000 TPS.

Here is how the technical architecture was designed:

  • Independent State: Each of the 64 shards would maintain its own account balances, smart contract code, and transaction history. Nodes wouldn’t need to store the entire history of the whole network, just their assigned shard.
  • The Beacon Chain Coordinator: A central chain, already live as part of Ethereum’s Proof-of-Stake consensus, would manage validator assignments. It would use pseudorandom selection to assign validators to specific shards every epoch (approximately every 6.4 minutes).
  • Security via Randomness: Because validators were shuffled constantly, an attacker couldn’t easily target a specific shard. To take over one shard, you’d need to control two-thirds of the validators assigned to it. With random reshuffling, the probability of an attacker getting enough power in multiple shards simultaneously was calculated to be astronomically low-one in a trillion.

This design promised horizontal scaling. You could add more shards as demand grew, much like adding servers to a cloud cluster. But there was a catch: complexity. Managing cross-shard communication-getting a user on Shard A to send money to a user on Shard B-introduced significant technical hurdles and potential security vulnerabilities.

Why the Community Pivoted Away from Classic Sharding

If the math looked good, why did the developers stop? The answer lies in the rise of Layer 2 solutions. Between 2022 and 2025, technologies like Optimistic Rollups and ZK-Rollups matured rapidly. These Layer 2 networks process transactions off the main Ethereum chain and then post compressed proofs back to the mainnet. They offered immediate scalability without requiring the complex overhaul of the base layer.

Core developers realized that building 64 full execution environments (shards) was redundant when Layer 2s were already doing the heavy lifting. Moreover, classic sharding required nodes to verify data availability across all shards, which created bandwidth bottlenecks. If a node had to download data from 64 different shards to ensure nothing was missing, the network would slow down again, defeating the purpose.

The pivot allowed the team to focus on "The Merge"-transitioning Ethereum from Proof-of-Work to Proof-of-Stake-which happened successfully in 2022. Once that was secured, the priority shifted to making Layer 2s cheaper and more efficient, rather than rebuilding the base layer into 64 smaller chains.

Danksharding: The New Scalability Engine

Enter Danksharding, a hybrid approach named after researchers Protocols and Dankrad Feist, which focuses on data availability rather than execution. Unlike classic sharding, Danksharding does not create new execution environments. It doesn’t let you deploy smart contracts directly on a shard. Instead, it creates space on the Ethereum blockchain for Layer 2 networks to post their transaction data.

Think of it this way: Classic sharding was about building 64 new factories to make products. Danksharding is about expanding the warehouse so those factories can ship their goods faster and cheaper. By introducing "Proto-Danksharding" (via EIP-4844) in 2024, Ethereum introduced "blobs"-temporary data structures that hold Layer 2 transaction data without bloating the permanent blockchain state.

In the full Danksharding implementation planned for late 2026 and beyond, these blobs will be distributed across 64 data columns. This allows the network to support hundreds of Layer 2 networks simultaneously. Each Layer 2 can post its data to a different column, and thanks to a technique called erasure coding, users only need to sample a small fraction of the data to verify that the rest is available. This solves the bandwidth bottleneck that killed the classic sharding idea.

Comparison: Classic Sharding vs. Danksharding
Feature Classic Sharding Danksharding
Primary Goal Execute transactions in parallel Provide cheap data availability for L2s
Execution Environment Yes (each shard runs smart contracts) No (data only, no execution)
Node Requirements High bandwidth (verify all shards) Low bandwidth (sample data columns)
Cross-Shard Complexity High (complex messaging protocols) None (L2s handle logic independently)
Impact on Gas Fees Moderate reduction Drastic reduction (up to 100x cheaper for L2s)
Illustration comparing empty factories to a streamlined warehouse for L2 data storage.

How Danksharding Changes the User Experience

For the average user, the difference between classic sharding and Danksharding is subtle but profound. You won’t see a wallet interface asking you to choose between "Shard 1" and "Shard 2." Instead, you’ll continue using your favorite Layer 2 network-whether it’s Arbitrum, Optimism, Base, or zkSync-but the fees will drop significantly.

Currently, Layer 2s pay Ethereum for the right to post transaction data. This cost is passed down to users as gas fees. With Danksharding, the cost of posting that data plummets because the data is stored temporarily in blobs rather than permanently in the blockchain’s state trie. Early estimates suggest that transaction costs on Layer 2s could decrease by a factor of 10 to 100 once full Danksharding is live.

This means microtransactions become viable. Imagine paying $0.0001 for a game move or sending a tiny tip to a content creator. Under the old model, even with Layer 2s, the overhead was too high for such small amounts. Danksharding removes that friction by turning Ethereum into a high-capacity data bus for thousands of applications.

Security Implications and Data Availability Sampling

A common concern with any scaling solution is security. Does splitting the network make it easier to attack? In classic sharding, the fear was that an attacker could target a small shard with fewer validators. Danksharding mitigates this through Data Availability Sampling (DAS), a cryptographic method that allows light nodes to verify data integrity without downloading everything.

Here’s how it works: When data is posted to the network, it is encoded using erasure codes, which split the data into many fragments. To reconstruct the original data, you only need a portion of these fragments. Light nodes randomly sample a few fragments. If the data is missing or corrupted, the samples will fail to reconstruct, alerting the network. This ensures that no single entity can hide or delete transaction data without being detected.

This approach maintains Ethereum’s decentralization. You don’t need a supercomputer to run a node anymore. A laptop can verify the network’s health by sampling data, ensuring that power remains distributed among thousands of participants rather than concentrated in large data centers.

Abstract poster depicting data fragments connecting to a central node via light beams.

Comparative Context: How Other Chains Handle Sharding

Ethereum isn’t the only project experimenting with sharding. NEAR Protocol implemented a sharding system called Nightshade, which splits both the state and transaction processing. Unlike Ethereum’s Danksharding, NEAR’s shards are active execution environments. Every block contains information about all shards, and every validator tracks all shards, but the work is divided.

Another example is Polkadot, which uses a relay chain to coordinate multiple parachains. While similar in concept to Ethereum’s beacon chain, Polkadot’s parachains are dedicated blockchains with their own tokenomics and governance. Ethereum’s approach is distinct because it keeps a single economic security layer (ETH) while allowing diverse Layer 2 ecosystems to flourish on top. This unified security model is a key reason why Ethereum retained its dominance despite the complexity of its roadmap.

What This Means for Developers in 2026

If you’re a developer, the shift to Danksharding simplifies your life. You no longer need to worry about writing cross-shard messaging protocols or managing state across 64 different chains. Instead, you build your application on a Layer 2 of your choice, leveraging standard Ethereum Virtual Machine (EVM) compatibility.

The primary challenge now is interoperability between Layer 2s. Since each L2 operates somewhat independently, moving assets between them requires bridges. The industry is focusing on standardized bridge protocols and intent-based architectures to make these transfers seamless. As Danksharding scales, expect to see more modular designs where computation happens on specialized Layer 2s or Layer 3s, while Ethereum handles finality and data availability.

For enterprise adoption, this modularity is a win. Companies can choose a Layer 2 optimized for their specific needs-high throughput for gaming, privacy for healthcare, or low latency for finance-without sacrificing the security guarantees of the Ethereum mainnet.

Timeline and Future Roadmap

Where do we stand in July 2026? Proto-Danksharding is live, and users are already seeing reduced fees on major Layer 2s. Full Danksharding is in the testing phase, with targeted deployment expected in the next major upgrade cycle. Following that, the Verkle Tree upgrade is slated to further reduce node storage requirements, paving the way for even lighter clients.

The original dream of 64 execution shards may never happen, but the outcome is arguably better. By focusing on data availability, Ethereum has positioned itself as the settlement layer for the entire internet of value. The complexity is hidden beneath the hood, leaving users with a faster, cheaper, and more scalable experience.

Is classic Ethereum sharding dead?

Yes, the original plan for 64 execution shards has been abandoned. The community shifted focus to Layer 2 scaling and Danksharding, which provides data availability without the complexity of managing multiple execution environments.

What is Danksharding?

Danksharding is a scalability upgrade that increases the amount of data Ethereum can handle per block. It uses "blobs" to store Layer 2 transaction data temporarily, making it cheaper for Layer 2s to operate and reducing gas fees for users.

How does Danksharding affect gas fees?

Danksharding drastically reduces the cost of posting data to Ethereum. Since Layer 2s rely on this data posting, their fees drop significantly-potentially by 10 to 100 times-making microtransactions economically viable.

Do I need to update my node to support sharding?

If you run a full node, you will need to update your client software to support the new blob-carrying blocks and Data Availability Sampling. However, the hardware requirements remain manageable for most home users due to the sampling efficiency.

When will full Danksharding be live?

Proto-Danksharding is already live as of 2024. Full Danksharding, with all 64 data columns active, is expected to be deployed in subsequent upgrades throughout 2026 and 2027, depending on testing progress.