“Nightshade: Near Protocol Sharding Design” is a technical paper published in 2020 by Alex Skidanov and Illia Polosukhin, co-founders of NEAR Protocol. It describes NEAR’s approach to blockchain sharding — the technique of dividing transaction processing across multiple parallel shards to scale throughput linearly with the number of shards.

NEAR’s core insight is structuring sharding so that all shards share a single blockchain, with each block containing “chunks” representing the state transactions from each individual shard. This eliminates the cross-shard coordination complexity that defeats most sharding designs.

> PDF hosting: The Nightshade paper is hosted at near.org/papers/nightshade and the NEAR Protocol GitHub. It was released publicly with no redistribution restrictions.

---

Publication and Context

NEAR was founded in 2018 by Alex Skidanov (former engineer at Microsoft Research, MemSQL) and Illia Polosukhin (formerly Google Brain, co-author of the “Attention Is All You Need” transformer paper that led to modern AI). Despite their AI background, they pivoted to blockchain infrastructure after a failed product pivot, concluding that existing blockchains were too slow and too complex for mainstream developers.

By 2020, Ethereum 2.0’s sharding design was struggling with cross-shard complexity. NEAR designed Nightshade from scratch without the burden of backward compatibility with Ethereum’s execution model.

Key facts:

• NEAR Inc. founded: 2018
• Mainnet launch (Phase 0): April 2020
• Simple Nightshade (Phase 1): November 2021 (single shard operating as sharded)
• Full Nightshade (all 4 shards): Phased rollout 2022–2024
• NEAR token: Used for transaction fees, staking, governance

---

The Core Design: One Chain, Many Chunks

In most sharding designs, each shard is an independent blockchain — requiring separate consensus, separate validators, and complex bridging protocols for cross-shard communication. This creates both operational complexity and security concerns (each shard is independently attackable).

NEAR’s Nightshade approach: There is one blockchain; each block contains chunks — one chunk per shard. Each chunk represents the set of transactions and state transitions for that shard in that block. Validators process only their own shard’s chunk, but the block is atomically the collection of all chunks.

Practical benefits:

• Cross-shard transactions use async receipts routed through the main chain — no separate bridging protocol needed
• Single finality model: a block is final means all its chunks are final simultaneously
• Validators rotate across shards randomly, making targeted attacks harder

---

Key Technical Components

Chunk Producers: Each shard has a set of chunk producers who validate and produce chunks for that shard. They are selected via random assignment from the pool of staked validators. A different set of chunk producers handles each shard per epoch (12 hours in production).

Receipts: When a transaction in Shard A must affect state in Shard B, it generates a receipt — a cross-shard message. Receipts are included in subsequent blocks and executed by the destination shard. This introduces at least one block of latency for cross-shard effects.

Doomslug Finality: NEAR uses a practical finality gadget called Doomslug: a block at height H is considered “practically final” after the block at H+1 is produced by a different validator. Full BFT finality (requiring 2/3 of validators to sign) is layered on top for bridge security.

Data Availability: Each chunk must be available for validators to download. If a chunk is unavailable (chunk producer offline), the previous shard state is used, and the block is produced without that chunk’s new transactions.

---

Sections of the Whitepaper

Section	Content
1. Introduction	Why sharding; existing approaches and their limitations
2. High-Level Design	One logical chain with chunks; state distribution
3. Chunk Production	Validator assignment; chunk validity; availability
4. Cross-Shard Transactions	Receipt routing; atomic transaction semantics
5. Finality	Doomslug + BFT finality; fork resolution
6. State Sync	How validators catch up to current shard state
7. Security	Validator assignment; epoch transitions; economic security
8. Network Phases	Progressive decentralization roadmap

---

Reality Check

NEAR’s sharding rollout was slower than planned — full Nightshade was still rolling out through 2024, years after the mainnet launch. However, NEAR demonstrated that its single-chain sharding model works at a small scale (1–4 shards), with transaction throughput exceeding any un-sharded L1 in production.

The developer experience angle (Aurora EVM compatibility for Ethereum devs; JavaScript SDK for wider dev adoption) attracted some project deployment, but NEAR’s DeFi ecosystem remained modest compared to Ethereum, Solana, and BNB Chain.

---

Legacy

NEAR’s Nightshade influenced how subsequent teams thought about sharding — particularly the insight that a single chain with parallel processing is more developer-friendly than multiple independent shards. Ethereum’s own (cancelled) sharding roadmap evolved toward blob-based scaling (EIP-4844) partly because of the complexity lessons learned from designs like Nightshade.

---

Related Terms

• NEAR Protocol
• Zilliqa Whitepaper
• Harmony Whitepaper
• Ethereum Beacon Chain Whitepaper
• Celestia Whitepaper

---

Research

• Skidanov, A., & Polosukhin, I. (2020). Nightshade: Near Protocol Sharding Design. NEAR Protocol.

— Primary source. The async receipts model (§4) is the key novel contribution.

• Al-Bassam, M. (2019). LazyLedger: A Distributed Data Availability Ledger. arXiv.

— Complementary data availability approach; NEAR’s chunks address similar concerns differently.

• Buterin, V. et al. (2020). Ethereum 2.0: The Beacon Chain. ethereum.org.

— Ethereum’s competing sharding strategy; comparing it to Nightshade illuminates the tradeoffs.