LibraryConsensus2019Design paperCorpus record
The NEAR White Paper
NEAR. The NEAR team.
NEAR's public design paper: a sharded proof-of-stake chain with a single account model, nightshade-style data availability across chunks, and a stated intent that hiding the shards from application authors is part of the product.
NEAR shards execution across chunks, has a small group produce each chunk, and uses a nightshade-style assumption that a block can be valid even when some chunks are still hidden, as long as the data becomes available.
The five-minute read
A block is a list of chunks
Each shard produces a chunk. A block producer assembles chunk headers into a block. The design tries not to require every validator to re-execute every shard.
Nightshade hides chunks, carefully
The paper's scaling move is to let a block be proposed before every chunk body has been seen by everyone, and to punish a producer who hides data. Data availability, not raw execution, is the constraint it names.
Doomslug gives practical finality
A block that gathers enough endorsements is treated as final under the paper's fast path. The full Byzantine proof and the fast path are related and should not be blurred.
Human-readable accounts are a product choice
The paper spends real attention on account names, access keys and usability. That is unusual in a consensus paper and it is part of the design, not a website feature added later.
Resharding is promised, not free
Splitting a shard when it is busy is the long-term scaling plan. The paper describes the direction. Live resharding is an engineering milestone that has to be checked against the network, not against the abstract.
One action, walked through
- Validators are assigned to produce or validate chunks for particular shards in an epoch.
- A chunk producer executes the shard's transactions and publishes a chunk with a state root.
- A block producer gathers chunk headers. Under the nightshade rule it may proceed if enough chunks are present and the missing ones are accounted for.
- Validators endorse the block. After the doomslug threshold, applications are told the block will not be reversed on the fast path.
- If a producer withholds a chunk body, the protocol's challenge path is supposed to make that omission visible and costly.
The argument, unpacked
Availability is the real shard problem
A header without a body lets a shard claim it did work nobody can check. NEAR's text is useful because it centres that failure. A design review should ask what a fisherman or a validator actually downloads, and what happens in the slots before a fraud proof can land.
Fast finality is a threshold, not a mood
Doomslug finality means a stated share of stake endorsed a block and would be slashed for equivocation. It does not mean every laptop has executed every shard. Wallets that treat an endorsement as a local execution proof are over-reading.
Account names do not change consensus
They change who can safely use the chain. Access keys that limit a dapp's authority are a response to the 'one key signs everything' failure mode. That part of the paper is easy to skip and expensive to skip.
What has to be true
- Enough stake is online in each shard assignment to produce chunks.
- Hidden chunk bodies are detectable within the protocol's challenge window.
- State roots in chunks match execution. A wrong root must be provable.
- Epoch assignments are random with respect to stake, so an attacker cannot camp in one shard.
What happened after the paper
NEAR shipped, revised its nightshade implementation, and treated full resharding as a phased rollout rather than a day-one fact. Account-key improvements continued. Cite the 2019 paper for the chunk model. Cite the network for what is actually final this week.
What to check before you use the idea
- Can a block include a chunk whose body is not yet public, and how long may that last?
- What fraction of stake produces doomslug finality?
- How are validators assigned to shards, and how often does the assignment change?
- What can an access key restrict, in the paper's account model?
Terms
- Chunk
- The piece of a block that belongs to one shard: transactions plus the resulting state root.
- Nightshade
- The paper's approach of assembling a block from chunk headers and treating missing bodies as a fault to be proven.
- Doomslug
- The fast finality rule under which enough endorsements make a block practically irreversible.
- Access key
- A key with limited permission on an account, so one application is not given the right to move every asset.
The problem the paper names
Sharded systems often leak the shard map into every application. NEAR's paper treats that leak as a product failure. Developers should see one chain. The protocol underneath still has to produce chunks, assign validators, and make data available.
What the design proposes
- Chunk producers handle a portion of a block. Block producers assemble a header over those chunks.
- Nightshade, in the paper's terms, keeps one block that contains the chunks rather than a family of loosely coupled chains.
- Account names and a predictable rent or storage cost are part of making the system usable, not an appendix.
How the mechanism is specified
- A validator who hides chunk data should be detectable because other validators only sign what they could fetch.
- Cross-contract calls are asynchronous. The paper does not pretend a sharded call is a local function call.
- Resharding is described as a protocol feature. Later implementations have their own timeline.
What this page does not treat as proven
- The white paper is not the current protocol specification. NEAR publishes specs separately.
- Hiding shards from developers does not hide failure domains from operators.
- No throughput number from the paper is repeated here as a live measurement.
Why a venture studio still reads it
The studio lesson is the product constraint: if application authors must know the shard, the protocol is unfinished. That is a higher bar than 'we have committees'.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.