Every node on the Ethereum network currently does the same work. When a transaction gets submitted, every full node independently validates it, stores it, and updates its local state. That redundancy is intentional — it's what makes the network trustless. But it also creates an obvious bottleneck: the network can only process as many transactions as a single node can handle alone.
Sharding is the proposed solution. The idea borrows from traditional database design: instead of every node storing and processing everything, you split the workload across many groups of nodes working in parallel. Each group handles a "shard" — a subset of total network activity. The result, in theory, is throughput that scales with the number of shards rather than being capped by any individual node.
In practice, making sharding work on a decentralized network without compromising security is considerably harder than it sounds. And Ethereum's original sharding plan looks nothing like what's actually being built today.
The Core Mechanism: Horizontal Partitioning
In a traditional database, sharding means splitting a large table into smaller horizontal partitions. If you have 100 million user records, you might split them into 10 shards of 10 million records each, handled by separate servers. Queries get routed to the relevant shard.
Blockchain sharding applies the same logic with additional constraints: the shards need to remain trustless, validators can't coordinate through a central authority, and any node should be unable to fake or withhold data from a shard it controls.
The general architecture requires a coordination layer — typically called a beacon chain or main chain — that doesn't process user transactions itself. Instead, it handles tracking which validators are assigned to which shard, processing attestations (cryptographic commitments from validators confirming shard data is available), and finalizing the overall state across all shards.
Individual shards run in parallel, each processing their own transactions. Validators get randomly assigned to shards in rotation, which prevents collusion. If you can't predict which shard you'll end up in, you can't pre-coordinate an attack against it.
Cross-shard communication — when a transaction in shard A needs to affect state in shard B — is the genuinely hard part. It typically requires routing through the main chain, which introduces latency and significant architectural complexity. This is partly why some approaches avoid full execution sharding entirely.
Why Ethereum's Plan Changed
The original Ethereum 2.0 roadmap proposed 64 execution shards, each running its own EVM and processing its own transactions independently. The beacon chain would coordinate them. This would have multiplied Ethereum's throughput roughly 64x.
That plan got deprioritized. Here's why.
The rollup ecosystem matured faster than anyone anticipated. By 2021-2022, both Optimistic and ZK rollups were demonstrating that you could scale Ethereum's execution layer without modifying the base protocol — by moving transaction execution off-chain and posting only proofs and compressed data to Ethereum L1. Ethereum's role shifted: rather than being the execution engine, it could function as a data availability and settlement layer.
Once that framing took hold, execution sharding became redundant. If rollups handle computation, Ethereum just needs to make data posting cheap and abundant. That's data sharding — and it's a fundamentally different problem.
Data sharding (formalized as Danksharding, after Ethereum researcher Dankrad Feist) doesn't shard the EVM at all. It shards the data availability layer — specifically, it allows the network to verify that large amounts of data are available without every node downloading all of it. The mechanism is called data availability sampling (DAS): each node randomly samples small pieces of the data, and if enough samples succeed, the full dataset is probabilistically guaranteed to be available.
This is easier to reason about than execution sharding, but it's still technically demanding and hasn't shipped in its full form.
Where Things Actually Stand: Blobs
Danksharding isn't live yet. What is live is proto-Danksharding, implemented via EIP-4844 in the Dencun upgrade in March 2024.
EIP-4844 introduced blob transactions — a new transaction type that lets rollups attach large data payloads to Ethereum blocks in a dedicated field. Blobs are cheap relative to calldata, aren't processed by the EVM, and get pruned from nodes after roughly 18 days. That's fine for rollups: they only need the data available long enough for fraud proofs or validity proof windows to close.
As of mid-2026, Ethereum supports around 3-6 blobs per block. Full Danksharding targets 64 blobs per block — roughly 16 times the current limit. Getting there requires three things.
Data availability sampling (DAS): instead of downloading full blobs, each node samples random pieces of the data. If enough samples succeed, the data is statistically guaranteed available. This requires a new p2p network layer designed specifically for sampling, which doesn't exist yet at mainnet scale.
Erasure coding: blobs get encoded so that even if some fraction of the data is missing, the rest can be used to reconstruct it. This makes DAS more robust — you need to withhold a large amount of data, not just a little, to fool the sampling check.
KZG commitments: cryptographic proofs that blob data matches what was committed, without requiring a full download. These are already implemented in EIP-4844. Danksharding extends their use.
No mainnet timeline for full Danksharding has been confirmed as of mid-2026. The specification is active research.
The Validator Assignment Problem
One security assumption in sharding: validators must be randomly assigned to shards. If an attacker could predict assignment in advance, they could concentrate their stake on a target shard and attack it cheaply.
The solution is randomness derived from the chain itself — using mechanisms like RANDAO or verifiable random functions — so that assignment is unpredictable until the moment it happens. Validators rotate regularly, making sustained shard-level attacks impractical.
The tradeoff is real: smaller shards mean fewer validators per shard, which lowers the cost of a takeover. Danksharding's DAS-based approach partially sidesteps this because validators don't need to process full shard execution — they only sample data availability. A data withholding attack requires fooling many independent samplers simultaneously, which gets exponentially harder as sampling density increases.
What Would Confirm This Direction
Increasing the blob count significantly on mainnet — 16 or more blobs per block — would indicate Danksharding is progressing. Rollup fees falling proportionally as data capacity expands would confirm the mechanism is working. The DAS p2p network going live without data withholding incidents would validate the sampling-based security model.
Sustained rollup fee compression is the most observable signal for most users: if L2 transactions stay cheap as network activity grows, the data availability layer is doing its job.
What Would Break It
Data availability sampling fails if the sampling algorithm produces false positives — validators conclude data is available when it isn't. This could happen if an attacker withholds data in a pattern that systematically avoids being sampled, or if the erasure coding scheme has implementation flaws.
A more fundamental break: if rollups fail to gain adoption, Ethereum's pivot toward being a data availability layer becomes moot. The whole architecture assumes rollups are the execution layer. If that assumption fails, the original execution sharding plan would need to be revisited.
Timing
Now: Proto-Danksharding (EIP-4844 blobs) is live. Rollups post data to blob space rather than calldata. L2 fees dropped substantially after the Dencun upgrade in March 2024 — many L2 transactions cost fractions of a cent.
Next: Full Danksharding specification continues as active research. Increasing the blob count beyond the current limit requires the DAS p2p network. No confirmed mainnet date exists.
Later: Execution sharding — the original 64-shard EVM plan — isn't on the active roadmap. It may resurface in modified form, but isn't being actively built toward as of now.
Boundary
This covers how sharding works as a mechanism and why Ethereum's implementation pivoted from execution sharding to data sharding. It doesn't cover rollup mechanics in detail, how to use any specific L2, or what any of this means for fees or prices. The design rationale is reasonably well understood. The timeline is not — nothing here should be read as a commitment to any delivery schedule.
