Polkadot
NEAR Protocol
sharding-matters">Why Sharding Matters
A single-chain blockchain faces an inherent scalability ceiling: every node must process and store every transaction. This design guarantees that all participants can independently verify the chain's history — a core property of permissionless systems — but it means throughput cannot exceed what a single participant can handle. As transaction demand grows beyond that capacity, fees rise and the chain becomes unusable for many applications.
Sharding addresses this by dividing the network's workload across multiple parallel "shards" — each shard processing a subset of transactions, with a smaller subset of validators responsible for each shard. The total network capacity scales with the number of shards. The challenge is that sharding introduces new complexity: how do shards communicate securely, how does the network maintain cross-shard consistency, and how does data remain available when no single participant stores everything?
Three distinct approaches to sharding have emerged in production or near-production blockchains: Ethereum's Danksharding (a data availability sharding design), NEAR's Nightshade (state sharding with a unified chain), and Polkadot's parachain model (an execution sharding design with shared security). Each makes different architectural choices that reflect different priorities and different threat models.
Ethereum Danksharding: Sharding for Data Availability
Ethereum's sharding roadmap has evolved substantially from its original conception. The initial plan, described in Ethereum's research documentation from 2017-2020, called for execution sharding: dividing transaction execution across 64 shards, each processing a subset of smart contract calls. This approach was progressively deprioritized as the rollup-centric scaling strategy gained consensus.
The current sharding design, called Danksharding (named after researcher Dankrad Feist who developed key aspects of it), is specifically data availability sharding rather than execution sharding. Ethereum's execution scaling is delegated to Layer 2 rollups; Ethereum's base layer sharding focuses on increasing the amount of data that rollups can post to Ethereum cheaply.
The intuition: rollups batch thousands of transactions and post a compressed data blob to Ethereum. The bottleneck for rollup scaling is how much blob data Ethereum can accept per block. Danksharding increases this capacity by using a technique called data availability sampling (DAS).
Data Availability Sampling
In full sharding, validators are divided into committees that each only download and verify a fraction of block data. The risk is that a malicious block producer could omit some data — making a block appear valid while withholding data that would allow reconstruction of the full state. Without complete data, even honest validators cannot detect fraud or generate fraud proofs.
DAS solves this through a mathematical technique called erasure coding. Block data is encoded such that any 50% of the encoded data is sufficient to recover the full original data. The encoding is extended across the shard chunks, and each validator randomly samples a small number of chunks (say, 75 samples). If the probability that any given sample is available is high (because the data is genuinely distributed across the network), then each validator can be statistically confident the full data is available after sampling — even without downloading everything.
The key insight: an attacker who withholds even a small portion of data will be detected with high probability by the random sampling process. Validators can refuse to finalize blocks where their samples fail, preventing unavailable data from being included.
Proto-Danksharding (EIP-4844), implemented in Ethereum's Dencun upgrade in March 2024, introduced "blobs" — a new transaction type where rollups post blob data that is stored by full nodes for a limited period (approximately 18 days) but not processed by the EVM. This immediately increased rollup data capacity by approximately 6-10x and reduced rollup transaction costs by 10-100x on chains like Arbitrum, Optimism, and Base.
Full Danksharding, still under development, will extend this to 64 or more data columns distributed across the validator set, with DAS allowing validators to verify data availability by sampling rather than downloading everything. The target is approximately 32 MB per block of data availability capacity — enough to support hundreds of active rollups.
NEAR Nightshade: State Sharding with a Unified Chain
NEAR Protocol, described in its whitepaper published in 2019, implements Nightshade — a state sharding design that takes a different approach to the shard coordination problem.
In Nightshade, all shards are conceptually part of a single blockchain. The NEAR chain produces one unified block per round, but that block is composed of "chunks" — one per shard. Each shard has its own set of validators (selected by epoch random assignment) who produce and validate that shard's chunk. The NEAR protocol ensures that all chunks are included in the block and that cross-shard communication is handled through a receipt mechanism.
When a transaction on Shard A calls a contract on Shard B, the transaction creates a "receipt" — a message that is asynchronously processed in a subsequent block on Shard B. This asynchronous model means cross-shard calls complete in two or more blocks rather than synchronously, which is a significant simplification compared to synchronous cross-shard execution but requires application developers to reason about asynchrony.
NEAR launched with 4 shards in 2021 and has progressively expanded. The Stateless Validation upgrade (2024) is a significant architectural change that further reduces per-validator storage requirements: validators can validate chunks without storing the full shard state, instead verifying state witnesses (cryptographic proofs of the relevant state touched by a chunk's transactions). This enables a larger validator set to secure each shard without requiring each validator to store proportionally more data as shard count grows.
The Boundary Challenge
NEAR's Nightshade faces a fundamental challenge in state sharding: accounts and contracts are assigned to specific shards, and cross-shard transactions require asynchronous receipts. If a popular DeFi protocol lives on Shard 1, all interactions with that protocol route to Shard 1, potentially creating a hotspot that exceeds Shard 1's capacity while other shards are underutilized.
NEAR's solution is dynamic resharding: the protocol can split overloaded shards into two and merge underloaded shards, assigning accounts to new shards as needed. This automatic load balancing is complex to implement correctly and is an ongoing area of development. The NEAR whitepaper describes resharding as a key property, though its full implementation has taken longer than initially anticipated.
Polkadot Parachains: Execution Sharding with Shared Security
Polkadot's parachain model represents a different philosophical approach to sharding. Rather than treating sharding as a performance optimization on a single chain, Polkadot is designed from the ground up as a network of independent blockchains (parachains) that share security through a central Relay Chain.
Each parachain is a fully independent blockchain with its own state machine, its own transaction model, and potentially its own consensus rules. Parachain validators — a randomly assigned subset of the Relay Chain's validator set — verify parachain blocks and submit proofs of correctness to the Relay Chain. The Relay Chain provides finality for all parachains, anchoring their state to a single secure consensus.
From a sharding perspective, each parachain is an execution shard. Transactions on different parachains are processed in parallel by different validator subsets. The number of parachains (currently capped by the number of available parachain slots, typically around 40-50 active parachains) determines the execution parallelism.
Shared Security and Pooled Validation
Polkadot's key innovation is pooled security. A new blockchain built independently would have to bootstrap its own validator set and security budget — a chicken-and-egg problem where the chain isn't secure until it has value, but it won't have value until it's secure. Parachains inherit the Relay Chain's security from day one: the full economic weight of the staked DOT (billions of dollars) secures all parachains equally.
This shared security model means that a small new parachain has the same security guarantee as a large established parachain — in contrast to independent L1 chains, where security scales with market cap.
The tradeoff is that parachain slot access is competitive and limited. Parachain slots are allocated through auctions (parachain slot auctions) where projects lock DOT for the duration of a lease period. This creates an economic barrier and a finite number of execution shards. Polkadot's future Agile Coretime model replaces fixed slot auctions with a more flexible market for block production time, allowing projects to purchase only the execution time they need.
Cross-Shard Communication Compared
The three approaches handle cross-shard communication very differently:
Ethereum Danksharding: Cross-shard communication is not directly handled by the sharding layer — it's handled by rollups and their bridging infrastructure. Data availability sharding doesn't create execution shards that need to communicate; rollups handle their own internal state.
NEAR Nightshade: Cross-shard receipts are native to the protocol. The asynchronous receipt model is explicit and guaranteed: a cross-shard call queues a receipt that is processed in a subsequent block on the destination shard. Finality for cross-shard operations spans multiple blocks.
Polkadot XCMP: Cross-parachain messages use the XCM message format, with the Relay Chain providing ordering guarantees. The Relay Chain verifies that messages are sent and received correctly, creating a secure cross-chain communication channel without requiring trust in the individual parachains.
Data Availability: The Fundamental Constraint
All three sharding approaches ultimately confront the data availability problem: when validators only store a fraction of the total state, how can the network guarantee that all data is available to those who need it?
Ethereum's DAS approach (random sampling + erasure codes) provides probabilistic guarantees with mathematical rigor. NEAR's stateless validation shifts the burden to state witnesses included with blocks. Polkadot relies on the validation groups to store and make available the parachain proof-of-validity data they validate.
The sophistication of the data availability solution is increasingly recognized as the core technical challenge in sharding design. Ethereum's Danksharding roadmap has focused the most concentrated research effort on this problem, producing the EIP-4844 blob design and the ongoing work toward full DAS. The solutions from this research — erasure coding, polynomial commitments, and random sampling — will likely influence how all three ecosystems address data availability as they scale further.