What is Sharding?
Sharding is a database scaling technique adapted for blockchains, where the network is split into multiple parallel segments called “shards,” each responsible for processing a subset of transactions and maintaining a portion of the overall state. Instead of every node validating every transaction (the current approach for most blockchains), each node only validates transactions in its assigned shard, allowing the network to process transactions in parallel. The theoretical throughput increase is linear with the number of shards—if you have 64 shards, the network can handle roughly 64× more transactions than a single chain.
In traditional database systems, sharding is a well-established technique used by companies like Google, Amazon, and Netflix to scale their databases to billions of users. Each shard operates semi-independently, and a routing layer directs queries to the appropriate shard. The challenge of applying sharding to blockchains is that blockchains require all nodes to agree on a single, consistent state (consensus). If shards operate completely independently, cross-shard transactions become expensive and complex, and the security of the whole system depends on the weakest shard.
Ethereum originally planned to implement sharding as its primary scaling strategy, with the “Ethereum 2.0” roadmap envisioning 64 shards processing transactions in parallel. However, by 2020–2021, the Ethereum research community concluded that rollups were a better scaling solution than on-chain sharding. The rollup-centric roadmap that emerged retained the concept of sharding but repurposed it: instead of splitting execution across shards, Ethereum would shard only its data availability layer, providing massive amounts of cheap data space for rollups to post their compressed transactions. This approach is now called “danksharding.”
How It Works
Original Ethereum Sharding Design
The original Ethereum sharding proposal had the following architecture:
- 64 beacon chain shards: Each shard would process its own transactions and maintain its own state
- Cross-shard communication: Transactions affecting multiple shards would use “receipts” and “cross-shard calls”—a synchronous communication model where Shard A would create a receipt, and Shard B would execute based on that receipt in a later block
- Random committee assignment: Validators would be randomly assigned to shards every epoch (6.4 minutes) to prevent attacks on specific shards
- Merkle proof verification: Light clients could verify the state of any shard by checking Merkle proofs against the beacon chain’s “crosslink” commitments
The complexity was enormous. Cross-shard communication was estimated to add 2–4× latency overhead. Synchronous cross-shard calls created “head-of-line blocking” problems—if one shard was slow, dependent transactions on other shards would stall. The development timeline stretched from years to potentially a decade.
Why Rollups Replaced Sharding for Execution
The pivotal realization came from Ethereum researchers (notably Vitalik Buterin and the Rollup team at the Ethereum Foundation) that rollups provided a simpler path to scaling:
- Rollups already shard execution: Each rollup (Arbitrum, Optimism, zkSync) effectively operates as an independent execution shard. There’s no need to add sharding complexity to the L1 protocol when L2s already provide this.
- The bottleneck is data availability, not computation: L2 rollups can process millions of transactions off-chain, but they need to post transaction data somewhere secure. The bottleneck is not execution capacity—it’s the cost and availability of posting data to L1.
- Sharding DA is simpler than sharding execution: Sharding only the data availability layer (via blobs) is architecturally much simpler than full execution sharding, because DA shards don’t need to execute transactions or maintain state—they just need to ensure data is available.
Modern Sharding: Danksharding
The current Ethereum roadmap’s approach to sharding is called danksharding, which shards only the data availability layer. Key components:
- Blob-carrying transactions: Introduced by EIP-4844 (March 2024), each block can include up to 6 “blobs” of extra data (128 KB each = 768 KB per block). Blobs are cheaper than calldata because they are not accessible to the EVM and are pruned after ~18 days.
- Data Availability Sampling (DAS): A technique where light clients can verify data availability by randomly sampling small portions of blob data, without downloading the entire block. This allows the network to scale DA capacity massively while keeping light client verification possible.
- Proto-danksharding to full danksharding: EIP-4844 is the “prototype” step. Full danksharding will expand blob capacity to ~16 MB per slot (from 768 KB), using DAS and proposer-builder separation (PBS) to manage the increased data.
Cross-Shard Communication Models
Different sharding approaches handle cross-shard communication differently:
| Model | Latency | Complexity | Example |
|---|---|---|---|
| Synchronous | 1–2 blocks | High (head-of-line blocking) | Original ETH2 spec |
| Asynchronous | 10+ blocks | Medium (receipt-based) | Cosmos IBC |
| No cross-shard | Independent | Low (no composability) | Polkadot parachains |
| Optimistic cross-shard | 1–2 blocks + proof | Medium | ETH danksharding (via rollups) |
Real-World Examples
Ethereum’s EIP-4844 (implemented March 13, 2024 as the Dencun upgrade) is the first step of the sharding roadmap. It reduced L2 blob costs from ~$0.10–1.00 per transaction to ~$0.001–0.01. Before EIP-4844, Arbitrum and Optimism paid ~$0.05–0.10 per transaction in L1 calldata costs. After, costs dropped to ~$0.001–0.005—a 10–100× reduction that made many DeFi operations viable for smaller users.
NEAR Protocol implements a novel sharding design called “Nightshade” where each shard produces a portion of the block. The approach treats the entire network as a single blockchain, with each shard responsible for a “chunk” of the state. Cross-shard communication is handled through a “receipt” system where shards asynchronously process cross-shard messages. NEAR currently runs 4 shards but has tested up to 10 in production.
MultiversX (formerly Elrond) uses “Adaptive State Sharding” which combines three types of sharding: network sharding (nodes grouped by network proximity), transaction sharding (transactions routed to shards by sender address), and state sharding (accounts split across shards). It currently runs 3,162 shards and processes up to 100,000 TPS in benchmarks.
Polkadot takes a different approach called “parachains” (parallel chains) rather than shards. Up to 100 parachains can connect to the Relay Chain, each running its own logic and state. The Relay Chain provides shared security and consensus. Cross-chain communication uses XCM (Cross-Consensus Messaging). However, parachain slots are scarce (auctioned or granted) and not truly sharded in the database sense.
Key Risks / Considerations
- Cross-shard complexity: Synchronous cross-shard transactions introduce head-of-line blocking, dependency chains, and potential deadlock. Async models add latency and UX friction.
- Shard security dilution: With 64 shards, each shard’s validator set is 1/64 the size of the total. An attacker targeting one shard needs to compromise only 1/64 of the total stake to disrupt that shard. Random reassignment mitigates this but doesn’t eliminate the risk.
- State imbalance: Popular applications (like a major DEX) would concentrate load on specific shards, negating the parallelism benefit. Load balancing is an unsolved problem.
- Light client complexity: For sharding to work securely, light clients need to verify data availability across all shards. DAS makes this feasible but adds protocol complexity.
- Reorg coordination: If one shard reorganizes its chain, dependent transactions on other shards may need to be unwound, creating cascading effects.
Comparison: Sharding vs. Rollups
| Dimension | On-chain Sharding | Rollups |
|---|---|---|
| Execution location | On L1 (across shards) | Off-chain (on L2) |
| Implementation complexity | Very high (protocol-level) | Medium (separate systems) |
| Cross-shard communication | Complex, slow | Inter-L2 bridges (evolving) |
| Security model | L1 security per shard | L1 security for DA + L2 security for execution |
| Upgrade path | Hard fork required | L2 can upgrade independently |
| Developer experience | Must consider shard routing | Same as L1 (EVM equivalence) |
| Current status | Not implemented (Ethereum) | Production (Arbitrum, OP, Base, zkSync) |
Frequently Asked Questions
Q: Is Ethereum implementing sharding? A: Ethereum is implementing a simplified form of sharding called “danksharding” that shards only the data availability layer, not execution. Full execution sharding has been deprioritized in favor of rollups. The first step (EIP-4844) was deployed in March 2024.
Q: What’s the difference between sharding and partitioning? A: In traditional databases, sharding and partitioning are often used interchangeably. In blockchains, “sharding” specifically refers to protocol-level splitting where each shard is validated by a different subset of nodes but all share the same consensus layer. “Partitioning” in database terms doesn’t carry the consensus complexity.
Q: Can a shard be attacked independently? A: Yes, this is a known risk. An attacker who controls 1/3 of a shard’s validator set could prevent that shard from finalizing. Random committee reassignment mitigates this by rotating validators across shards, but during the assignment period, a targeted shard attack is possible. The cost of attacking a single shard is proportionally lower than attacking the whole chain.
Q: Why did Ethereum abandon execution sharding? A: The core insight was that rollups already provide “execution sharding” in a more flexible and upgradeable way. Each rollup is essentially an independent execution environment, and new rollups can be launched without protocol-level changes. Sharding execution on L1 would have locked Ethereum into a specific architecture that would be extremely difficult to modify. The rollup-centric approach preserves L1 simplicity while achieving the same throughput goals.