The NEAR White Paper

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'.