How does NEAR Protocol's sharding architecture
Published 11/1/2026, 12:35:52 AM
Answer
Bottom line: NEAR Protocol scales by partitioning both state and computation across parallel shards — but it does it in a way that keeps a single, unified chain. Each block contains "chunks" from every shard, so adding shards adds throughput roughly linearly without fragmenting the user experience. The architecture has evolved through four generations (Simple Nightshade → Nightshade 2.0 stateless validation → Dynamic Resharding → SPICE), with shard count growing from 4 to 10 and throughput claims rising to 1M TPS in a first-party benchmark.
1. Core design: sharded blocks, not shard chains
Nightshade (the sharding design by Skidanov & Polosukhin, 2019) uses homogeneous sharding: "a blockchain is divided into multiple parallel shards that have the same execution environment… Each shard maintains its own state, which allows the blockchain to scale linearly by adding more shards" (near.org/papers/nightshade). The key differentiator is that NEAR does not run separate shard chains — it shards blocks, so "developers do not have to be concerned with the shard they are on" (near.org blog, OpenWeb China AMA). As one explainer puts it: NEAR "make[s] the chain look logically unified while making the underlying work physically partitioned" (cube.exchange). Validators "process their activity across parallel parts of the network called shards" (docs.near.org).
2. The four scalability phases
| Phase | When | What it did for scalability |
|---|---|---|
| Simple Nightshade | Nov 15, 2021 | Sharded state but not processing; all validators still validated all transactions, keeping safety guarantees identical. Per-shard capability: 800–1,000 TPS for token transfers (near.org) |
| Nightshade 2.0 (stateless validation) | Aug 22, 2024 | Validators no longer store a shard's state locally; they validate using state witnesses. This improved single-shard performance and added capacity for more shards (6 shards at launch, plan for 10+) (near.org, confirmed independently by CoinDesk) |
| Dynamic Resharding | Live in network upgrade 2.13, July 20, 2026 | Shards auto-split when hot and merge when underused — "without requiring a protocol upgrade" (NEP-639). Previously each shard addition meant "weeks of validator coordination" (PRNewswire; confirmed by Nansen Q2 2026 report) |
| SPICE (Separation of Consensus and Execution) | Previewed June 22, 2026; technical series began Sept 30, 2026 | Decouples transaction ordering, data availability, and execution so "execution moves off the critical path of block production" (near.org, Near One). Targets cutting block time from 600ms to 200ms as a step toward Nightshade 3 (chaincatcher, Gate News) |
3. How shard growth maps to throughput
- Mainnet launched Oct 2020 with 4 shards and "100% uptime" (per near.org).
- 8 → 9 shards in Q3 2025, increasing network throughput by 12.5%, with chunk validators expanded from 300 to 500 in nearcore v2.7.0/v2.8.0 (Messari / Blockworks).
- 10 shards on mainnet as of Oct 6, 2026 (Le Coin).
- 1M TPS benchmark: announced Dec 8, 2025 using "real NEAR core code in a realistic, publicly verifiable benchmark" on Google C4D machines with 5th-gen AMD EPYC processors (near.org); the Near One engineering post frames this as shard scaling "only using commodity hardware" (blog.nearone.org).
4. Risks, tradeoffs, and honest limitations
- Benchmark provenance is contested. The 1M TPS number comes from the protocol's own teams (first-party source). An independent arXiv study (Sept 2026, "Shards on a Shoestring," Illinois Institute of Technology) notes that published NEAR benchmarks "were produced on expensive Google Cloud Platform infrastructure costing approximately $700 per hour, leaving a significant reproducibility gap," and sets out to characterize Nightshade on commodity hardware (arXiv:2609.12091). So treat 1M TPS as a demonstrated ceiling under controlled conditions, not a proven production figure.
- The classic sharding security problem. Nightshade's own paper is candid: "with each shard having its own validators, each shard is now 10 times less secure than the entire chain" in a naive 10-shard design (near.org/papers/nightshade). NEAR's mitigation is validator rotation across shards plus all shards' chunks landing in one block — which is why Simple Nightshade let all validators validate everything first. The NEAR Foundation also published a post on "Unsolved Problems in Blockchain Sharding" acknowledging adaptively corrupting one shard of 1,000 is much cheaper than corrupting the whole system.
- Cross-shard communication overhead. "Currently… NEAR requires each step of inter-shard communication" to pass through consensus; SPICE exists precisely to remove that bottleneck by separating consensus and execution (blog.nearone.org).
- SPICE status caveat. Official NEAR posts still describe SPICE as the "next major protocol upgrade" (near.org), while Gate News reported "NEAR Protocol Launches SPICE Upgrade" on Sept 30, 2026. The 200ms block time should be read as a stated target, not yet independently verified on mainnet.
5. Why this is different from L2 scaling
NEAR deliberately chose L1 sharding over rollup-centric scaling: "NEAR… chose to scale through a different approach: sharding… why NEAR does not plan to scale through layer 2" (near.org, June 2023). Parallel mini-chains (e.g., rollups) give up unified cross-shard semantics and shared security, whereas Nightshade keeps "unified semantics" within a single chain (cube.exchange comparison).
Market context (as of Nov 1, 2026): NEAR trades around $4.43–$4.44 across chains (ETH wrap 0x85f17cf997934a597031b2e18a9ab6ebd4b9f6a4, +2.7% 24h), with the underlying sharding architecture increasingly cited in marketing as the basis for AI-scale apps (near.org); social posts this week reference Gemini listing NEAR and $1.4M daily inflows into Bitwise's NEAR ETF, e.g. x.com/kaidloscopes/status/2116660228758618562 — first-party/community claims, not independently verified. These are price-context signals; the scalability story itself rests on the architecture above.