What Is NEAR Protocol? Stateless Validation
Learn what NEAR Protocol is, how Nightshade sharding works, and what stateless validation means for validators and decentralization.
NEAR Protocol completed its stateless validation upgrade as Nightshade Phase 2, and the change affects every participant in the network differently. Developers evaluating NEAR as a smart contract platform need to understand what the architecture actually does. Investors assessing NEAR's technical roadmap want to know whether stateless validation represents a meaningful advancement. Validators planning their infrastructure need the operational delta: what changes, what stays the same, and what it means for hardware.
This article covers all three angles, starting with what NEAR is and building through to how stateless validation works, what a state witness is, how chunk validators and chunk producers divide their responsibilities, and what Phase 3 dynamic resharding aims to accomplish once stateless validation provides its foundation.
Contents
- What Is NEAR Protocol?
- The Problem NEAR Solves
- How NEAR Works: Nightshade Sharding Explained
- What Is NEAR Stateless Validation?
- Why Stateless Validation Matters
- Dynamic Resharding: What Comes After Stateless Validation
- NEAR vs. Ethereum and Solana
- The NEAR Ecosystem
- NEAR Token, Staking, and Validator Economics
- What Stateless Validation Means for Validators
- Frequently Asked Questions
- Conclusion
What Is NEAR Protocol?
NEAR Protocol is a Layer-1 proof-of-stake blockchain designed for high scalability, low transaction costs, and developer accessibility. The NEAR blockchain uses a sharding architecture called Nightshade sharding, which divides the network into parallel processing lanes, and has deployed stateless validation as its Nightshade Phase 2 upgrade to enable decentralized, high-throughput transaction processing. NEAR Protocol (the blockchain network) uses NEAR (the native token) for transaction fees and staking.
NEAR Protocol was co-founded by Illia Polosukhin (co-author of the 2017 "Attention Is All You Need" paper that introduced the Transformer architecture underlying modern large language models) and Alex Skidanov (former software engineer at Microsoft and co-architect of the Nightshade sharding design).
Key features of NEAR Protocol:
- Nightshade sharding: parallel transaction processing across multiple shards, each producing a shard-level block segment called a chunk
- Stateless validation (Phase 2, live): chunk validators verify transactions without storing local shard state, using state witnesses instead
- WebAssembly (Wasm) runtime: smart contracts compile to Wasm, supporting Rust and JavaScript as development languages
- Human-readable account names: accounts follow a naming format (e.g., yourname.near) rather than raw cryptographic addresses
- Low transaction fees: NEAR's fee model is designed to remain predictable as network throughput scales through sharding
- Developer grants: the NEAR Foundation distributes ecosystem funding to support protocol-adjacent projects
NEAR uses Thresholded Proof of Stake (a variant in which validators are selected based on a minimum stake threshold rather than a strict top-N ranking). This distinguishes NEAR's consensus from standard Delegated Proof of Stake. NEAR has approximately 100 active validators per epoch, and NEAR token holders can delegate stake to validators without running their own node.
NEAR's WebAssembly (Wasm) runtime executes smart contracts in a sandboxed, deterministic, language-agnostic format. Developers write contracts in Rust or JavaScript, both mainstream languages with large existing communities, and compile them to Wasm for execution. Deterministic execution matters specifically for stateless validation: given the same state inputs delivered via a state witness, every validator produces identical output, making stateless verification mathematically sound. For developers evaluating NEAR, see the What Is NEAR Stateless Validation? section for how this architecture affects network operation.
NEAR is used for smart contracts, decentralized applications (dApps), DeFi protocols, NFT platforms, gaming applications, and cross-chain interaction with Ethereum via the Aurora ecosystem project.
The Problem NEAR Solves
Blockchain designers face a widely-accepted tension known as the scalability trilemma: building a network that is simultaneously scalable, secure, and decentralized is difficult because optimizing for any two of those properties tends to compromise the third. This framework, associated with Ethereum co-founder Vitalik Buterin, is a design tension rather than an absolute constraint, but it describes a real trade-off that every major blockchain has navigated differently.
Ethereum has historically prioritized security and decentralization, accepting throughput limitations that produced high gas fees during periods of congestion. Solana prioritizes throughput and security through a single-shard, high-hardware architecture, which concentrates validator participation among operators who can afford the required infrastructure. Neither approach satisfies all three properties simultaneously under high load.
NEAR's Nightshade sharding architecture and stateless validation upgrade are designed to address all three dimensions: sharding distributes transaction processing to increase throughput, stateless validation reduces validator hardware requirements to support broader participation, and the overall design maintains cryptographic security throughout. Whether NEAR achieves this in practice at scale remains an open question. Phase 3 dynamic resharding, which extends this model further, is still in development.
How NEAR Works: Nightshade Sharding Explained
Nightshade sharding is NEAR Protocol's architecture for parallel transaction processing. It splits the blockchain into separate processing lanes called shards (parallel processing lanes that each handle a subset of network transactions simultaneously). Each shard's contribution to a block is called a chunk (a shard-level portion of a block; each shard produces one chunk per block interval). Validators are assigned to specific shards each epoch, and the resulting chunks are assembled into a single final block. (Nightshade sharding blog post)
Think of Nightshade like a multi-lane highway rather than a single road. In a single-lane system, every transaction waits behind every other. Nightshade builds parallel lanes: each shard is a lane, and each chunk is that lane's portion of the total traffic processed in a given block interval. In technical terms: NEAR maintains one logical chain that is physically partitioned into shards. Each shard processes its own transaction set, generates a chunk, and those chunks are merged into a unified block by block producers.
How NEAR Protocol sharding works:
- Incoming transactions are routed to the shard responsible for the sender's account
- Each shard processes its assigned transactions in parallel with all other shards
- Each shard's validator set produces a chunk containing its processed transactions
- Chunk validators verify that each chunk's transactions are valid
- Block producers aggregate all chunks from all shards into a single final block
- The final block is added to the chain and validator rewards are calculated
Validator shard assignments change at each epoch boundary. Before stateless validation, rotating to a new shard required downloading and syncing that shard's full state, a time-consuming and I/O-intensive operation. Stateless validation changes this, as described in the The Nightshade Roadmap table below.
The Nightshade Roadmap
Nightshade is a multi-phase upgrade. Each phase builds on the previous one, and stateless validation is the second of three planned phases.
| Phase | Name | Key Feature | Status |
|---|---|---|---|
| Phase 1 | Congestion Control | Protocol-level limits on cross-shard receipt flow to prevent shard overload from cascading across the network | Live |
| Phase 2 | Stateless Validation | Chunk validators verify transactions using state witnesses without storing local shard state | Live |
| Phase 3 | Dynamic Resharding | Network automatically splits or merges shards based on real-time transaction demand | Planned |
Last verified: 2025. Check near.org for current roadmap status.
Phase 1 introduced congestion control mechanisms to manage cross-shard transaction flow, ensuring that shard overload does not cascade across the network. Phase 2 (stateless validation) is the live upgrade this article covers in depth. Phase 3 (dynamic resharding) is planned; see Dynamic Resharding: What Comes After Stateless Validation for why Phase 2 is a prerequisite for Phase 3.
What Is NEAR Stateless Validation?
NEAR stateless validation is a blockchain architecture model in which chunk validators verify shard transactions without storing a local copy of the shard state. Instead, validators receive a state witness (a compact cryptographic proof generated by the chunk producer) containing only the state data needed to verify a specific chunk. This is Nightshade Phase 2, deployed as a live protocol upgrade. (Nightshade Phase 2 blog post)
Before stateless validation, every validator assigned to a shard had to maintain a continuously-updated local copy of that shard's state. Storing all account balances, smart contract storage values, and other state entries for every account within the shard was the core hardware obligation. When validators rotated to a new shard assignment at the epoch boundary, they had to download and sync the new shard's entire state before they could begin validating, a process that often took hours of I/O work.
Stateless validation removes that requirement entirely for chunk validators. The chunk producer, a stateful node that does maintain full shard state, generates a state witness alongside each chunk and broadcasts both to chunk validators. Chunk validators verify the chunk against the witness without any local state storage. For a precise explanation of what a state witness contains and how it is generated, see What Is a State Witness?
The practical difference between the two models:
| Dimension | Stateful Validation (Before) | Stateless Validation (Phase 2) |
|---|---|---|
| State storage required | Yes: full shard state maintained locally | No: state delivered per chunk via state witness |
| Hardware requirements | High SSD capacity for state storage | Reduced; no persistent state storage needed |
| Shard rotation cost | High: state sync required at each epoch | Low: begin receiving state witnesses immediately |
| Validator pool size | Limited by hardware cost | Designed to expand as hardware barrier decreases |
Why this matters: NEAR can support more validators with less infrastructure cost, a direct improvement to network decentralization.
For the step-by-step process of how stateless validation operates, see How NEAR Stateless Validation Works Step by Step. For the specific role of chunk validators versus chunk producers, see Chunk Validators vs. Chunk Producers.
How NEAR Stateless Validation Works Step by Step
The stateless validation process runs as follows for each chunk processed in NEAR's network:
- A transaction is submitted to the network and routed to the shard responsible for the sender's account
- The chunk producer executes the transactions in its assigned shard against its local shard state database
- The chunk producer generates a state witness containing only the state entries touched by this chunk's transactions, plus Merkle proofs of their inclusion in the shard state trie
- The chunk producer broadcasts the chunk and state witness together to the assigned chunk validators for that shard
- Chunk validators receive the state witness and verify that the transactions in the chunk apply correctly to the witnessed state, with no local state database required
- The validated chunk is forwarded to block producers, who aggregate all shard chunks into the final block
What This Means for Validators: Chunk validators no longer need to maintain or sync shard state. Each chunk arrives with its own self-contained proof package. When your validator rotates to a new shard at an epoch boundary, there is no state download. You begin receiving state witnesses for that shard's chunks and start validating immediately.
Why this matters: the separation between state storage (chunk producers) and state verification (chunk validators) allows the validator pool to grow without proportional hardware cost increases.
What Is a State Witness?
A state witness in NEAR is a compact cryptographic proof generated by the chunk producer that contains all the shard state data a chunk validator needs to verify a specific chunk. Chunk validators receive the state witness alongside the chunk data and use it to confirm transaction validity without querying any local state database.
Think of a state witness like a notarized excerpt from a filing cabinet. Rather than shipping the entire cabinet to every validator, the chunk producer extracts only the pages relevant to this chunk's transactions, certifies them cryptographically, and sends only what is needed. The analogy holds at a practical level: the validator receives a self-contained proof package rather than a full state copy.
In technical terms: the state witness contains the state trie entries (account balances, contract storage values) touched by the transactions in a particular chunk, plus Merkle proofs of their inclusion in the current shard state trie. A validator receiving the witness can verify each Merkle proof to confirm that the state entries are genuine, then execute the transactions against those entries to confirm the chunk's outputs are correct.
How a state witness is generated and used:
- The chunk producer executes all transactions in its chunk against its local shard state
- During execution, it records every state trie entry that was read or written
- It generates Merkle proofs proving each recorded entry belongs to the shard state trie
- It packages those entries and proofs into the state witness
- Chunk validators receive the witness, verify the Merkle proofs, and re-execute transactions against the provided entries
One disambiguation that matters for technical readers: NEAR's state witnesses are Merkle proof-based attestations of state data. They are not zero-knowledge proofs. The mechanism does not involve ZK circuits or proof systems; it uses standard Merkle tree inclusion proofs to certify that specific state entries are genuine portions of the shard state.
What This Means for Validators: The state witness is the data package that makes your stateless validation possible. You do not need to trust the chunk producer's state database; you verify the Merkle proofs included in the witness yourself. If the proofs check out and the transactions re-execute correctly against the provided entries, the chunk is valid.
Why this matters: because state witnesses are self-contained and verifiable, any validator can check any chunk without prior knowledge of the shard's history, opening the door to frequent, frictionless shard reassignment.
Chunk Validators vs. Chunk Producers
Chunk validators in NEAR are nodes responsible for validating individual shard chunks, the shard-level portions of each block. Under stateless validation, chunk validators do not store or maintain local shard state. They receive a state witness from the chunk producer and use it to verify that the transactions in a chunk apply correctly to the witnessed state.
Chunk producers are the stateful counterpart. A chunk producer maintains a full local copy of its assigned shard's state, builds the chunk by executing transactions against that state, generates the state witness, and broadcasts both the chunk and the witness to chunk validators. Chunk producers have elevated hardware requirements because of their state storage obligation. This is the stateful layer that enables the rest of the network to operate statelessly.
Block producers are a third, distinct role: they aggregate validated chunks from all shards into the final block. Do not conflate these three roles; they have different functions, state requirements, and hardware profiles.
| Dimension | Chunk Validators | Chunk Producers |
|---|---|---|
| Role | Verify chunk transactions against state witness | Build chunks, execute transactions, generate state witnesses |
| State storage | None required | Full shard state maintained locally |
| State witness | Receives and verifies | Generates and broadcasts |
| Hardware tier | Lower (no persistent state storage) | Higher (state storage I/O is primary cost) |
| Shard assignment | Rotates each epoch; frictionless under stateless validation | Assigned to shard; maintains state continuity |
NEAR uses an epoch (NEAR's time unit, approximately 12 hours, at the end of which validator shard assignments rotate) to govern validator rotation. At each epoch boundary, chunk validators are reassigned to shards. Under the previous stateful model, this rotation required downloading and syncing the new shard's complete state, an expensive operation that slowed down validator reassignment and concentrated the validator set. Under stateless validation, a validator reassigned to a new shard simply begins receiving state witnesses for that shard's chunks and starts verifying immediately. Staking rewards are calculated and distributed at epoch boundaries. (NEAR validator documentation, NEAR epoch documentation)
What This Means for Validators: Shard rotation at the epoch boundary no longer requires a state download. If your validator is reassigned from Shard A to Shard B at the next epoch, you begin receiving state witnesses for Shard B's chunks and can start validating within seconds of the new epoch opening.
Why this matters: frictionless shard rotation makes it practical for a much larger set of validators to participate, because the operational cost of reassignment is near zero under the stateless model.
Why Stateless Validation Matters
Stateless validation improves NEAR's decentralization by removing the shard state storage requirement from chunk validators. Lower storage and hardware requirements mean more participants can operate validator nodes, expanding the active validator set and distributing network security across a broader base of operators.
The mechanism chain is direct: state witnesses eliminate the need for chunk validators to store shard state, which removes the dominant hardware cost for the validation role. With a lower hardware floor, a larger pool of operators can run chunk validators economically. A larger, more geographically distributed validator pool reduces concentration risk and strengthens the network's resistance to coordinated interference.
Stateless validation itself does not change NEAR's gas fee model; transaction fees are still determined by computational complexity and network demand. However, by creating the architectural prerequisite for Phase 3 dynamic resharding, stateless validation provides the foundation for fee stability as transaction volume grows: more shards mean more processing capacity, and that capacity can expand without proportional fee increases. For how dynamic resharding builds on this, see Dynamic Resharding: What Comes After Stateless Validation.
NEAR's stateless validation upgrade strengthens its technical foundation by separating state storage from state verification, a structural change that affects validator economics, network decentralization, and the feasibility of elastic throughput scaling.
Dynamic Resharding: What Comes After Stateless Validation
Dynamic resharding is NEAR's planned Phase 3 upgrade that aims to allow the network to automatically split or merge shards based on real-time transaction demand, scaling throughput up or down without requiring validator downtime or manual reconfiguration.
The prerequisite relationship between stateless validation and dynamic resharding is architectural. Under stateful validation, rotating a validator to a new shard required syncing that shard's full state, a process measured in hours. Adding a new shard dynamically would require all validators assigned to it to complete this sync before any validation could begin. This operational bottleneck made on-the-fly shard splitting impractical.
Stateless validation removes that bottleneck. Because chunk validators no longer pre-load shard state, they can be instantly assigned to a new shard, a split shard, or a merged shard configuration and begin validating immediately; state witnesses provide everything they need per chunk. Phase 3 aims to build on this property to allow the protocol to automatically increase shard count when individual shards approach capacity, and decrease shard count when demand falls.
Phase 3 dynamic resharding is not yet live. NEAR's roadmap describes it as a planned upgrade. Protocol roadmaps are subject to change; check near.org for current development status.
Why this matters: stateless validation's immediate effect is lower hardware requirements for chunk validators. Its downstream significance is that it makes elastic throughput scaling architecturally feasible in a way that was not possible before Phase 2.
NEAR vs. Ethereum and Solana
NEAR differs from Ethereum in three measurable ways: NEAR uses Nightshade sharding to process transactions across parallel shards, while Ethereum operates as a single execution chain; NEAR has deployed stateless validation as a live protocol feature, while Ethereum's equivalent proposal (EIP-4762) remains in research and development as of 2025; and NEAR smart contracts compile to WebAssembly and can be written in Rust or JavaScript, while Ethereum's primary smart contract environment is Solidity on the Ethereum Virtual Machine (EVM).
| Dimension | NEAR Protocol | Ethereum | Solana |
|---|---|---|---|
| Consensus mechanism | Thresholded Proof of Stake | Proof of Stake (LMD-GHOST/Casper) | Proof of History + Proof of Stake |
| Sharding approach | Nightshade sharding (multi-shard, live) | Single execution chain (no sharding) | Single global state (no sharding) |
| Stateless validation | Live (Nightshade Phase 2) | Proposed (EIP-4762, in development) | Not applicable |
| Smart contract language | Rust, JavaScript (compiles to Wasm) | Solidity (EVM) | Rust, C, C++ |
| Validator hardware profile | Lower for chunk validators under Phase 2 | Moderate | High (CPU, RAM, NVMe SSD) |
Ethereum's stateless client proposal: Ethereum's research into stateless clients shares the same conceptual goal as NEAR's Phase 2 upgrade, allowing nodes to verify blocks without storing full state. Ethereum's proposed approach, outlined in EIP-4762, requires transitioning from Merkle Patricia Tries to Verkle Trees as the underlying state structure. This is a multi-year protocol migration that remains in research and development as of 2025. NEAR has deployed its stateless validation implementation as a live protocol feature; Ethereum's equivalent is proposed but not yet deployed. These are distinct implementations pursuing a similar architectural goal at different stages of development.
Solana's architectural trade-off: Solana achieves high transaction throughput through a single-shard architecture in which all validators process all transactions against the full global state. This approach delivers high performance but requires validators to maintain substantial hardware (high-end CPU, large RAM allocation, fast NVMe SSDs), which concentrates validator participation among operators with significant infrastructure resources. NEAR's sharded plus stateless approach aims to achieve comparable throughput capacity while allowing chunk validators to operate with lower hardware requirements. NEAR also competes in the Layer-1 platform market alongside Avalanche and Move-based chains like Aptos and Sui, though those architectures differ significantly from NEAR's sharding approach.
NEAR: current strengths and limitations
Strengths:
- Nightshade sharding is live and processing transactions across parallel shards
- Stateless validation (Phase 2) is deployed, reducing the hardware barrier for chunk validators
- WebAssembly runtime supports Rust and JavaScript, lowering the developer learning curve compared to Solidity-only environments
- Low transaction fees by design, with a fee model built to scale through sharding
- Developer grants available through the NEAR Foundation
Limitations:
- NEAR's ecosystem is smaller than Ethereum's in terms of total value locked and developer activity
- Phase 3 dynamic resharding is not yet live
- Developer community size is smaller than Solana's
The NEAR Ecosystem
The NEAR Foundation is a Swiss-based non-profit organization that oversees ecosystem development, developer grants, partnerships, and protocol governance for NEAR Protocol. It is distinct from the core engineering teams responsible for protocol development. The Foundation administers grants for projects building on NEAR infrastructure and supports developer onboarding.
NEAR Protocol supports a range of application categories, including DeFi protocols, NFT platforms, gaming applications, and social media platforms. NEAR's developer tooling is designed for accessibility: Rust and JavaScript support (both mainstream languages), human-readable account names, and documentation at docs.near.org.
Aurora is an Ethereum Virtual Machine (EVM) compatible execution layer built on NEAR infrastructure that allows developers to deploy Solidity smart contracts on NEAR without rewriting code. Aurora is a separate ecosystem project, not a NEAR Protocol feature. Rainbow Bridge enables trustless asset transfers specifically between NEAR and Ethereum, allowing users to move ETH and ERC-20 tokens between the two networks. NEAR also offers a data availability service (NEAR DA) used by Ethereum rollups and Layer-2 networks seeking low-cost, high-throughput data availability layers.
For developers considering NEAR as a platform: the Wasm runtime's support for Rust and JavaScript lowers the learning curve compared to EVM-only environments, and the Aurora ecosystem project provides a migration path for existing Solidity codebases.
NEAR Token, Staking, and Validator Economics
The NEAR token serves four functions within the protocol:
- Transaction fees (gas): NEAR pays for computation on the network; a portion is burned and a portion distributed to validators
- Staking: validators and delegators lock NEAR to secure the network and earn staking rewards
- Governance: NEAR token holders participate in protocol governance decisions
- Ecosystem grants: the NEAR Foundation distributes NEAR tokens as grants for ecosystem development
NEAR token holders can participate in network security by running a validator node directly or by delegating stake to an existing validator through a NEAR wallet. Delegation does not require running any infrastructure; holders select a validator and delegate their stake. For detailed staking instructions, see docs.near.org/validator/staking-overview.
Stateless validation's effect on staking dynamics is structural: by reducing the hardware requirements for chunk validators, the upgrade is designed to expand the pool of economically viable validator operators over time. A larger validator pool means staking is more distributed, which is positive for network decentralization. Staking yields vary based on total network participation and the number of active validators; as the validator pool expands, these dynamics may shift.
This article is for informational and educational purposes only. Nothing in this article constitutes financial, investment, or legal advice. Cryptocurrency and blockchain assets carry significant risk. Always conduct your own research before making investment decisions.
What Stateless Validation Means for Validators
Under stateless validation, the operational model for chunk validators changes in five specific ways:
- No shard state storage required: chunk validators no longer maintain a local copy of their assigned shard's state
- State witnesses replace state sync: chunk validators receive a state witness with each chunk, containing all state data needed for verification
- Frictionless shard rotation: when assigned to a new shard at an epoch boundary, validators begin receiving that shard's state witnesses immediately, with no state download required
- Reduced storage hardware requirements: the storage obligation that previously represented the largest hardware cost for the chunk validation role has been removed
- Chunk producers retain full state: the chunk producer role still requires full shard state maintenance and elevated hardware, and this distinction matters for infrastructure planning
Do chunk validators still need to store shard state? No. Chunk validators no longer need to store local shard state. They receive a state witness from the chunk producer each time they validate a chunk. Chunk producers (the nodes that build chunks and generate state witnesses) still maintain full shard state and retain elevated storage requirements.
Chunk validators under stateless validation do not need high-capacity SSD storage for shard state. The previous model required this storage as the primary hardware cost for the validation role; that requirement is gone. Chunk producers maintain full shard state and require storage hardware proportional to their shard's state size; operators planning to run chunk producers should account for this. Official hardware specifications for both roles are published at docs.near.org/concepts/basics/validators.
Shard assignment operates on approximately 12-hour epochs. At each epoch boundary, NEAR's validator selection mechanism reassigns chunk validators across shards. Under stateless validation, this reassignment is frictionless: the newly assigned validator receives state witnesses for its new shard's chunks from the chunk producer and begins validating immediately. The previous model required a state sync that could take hours; that cost is eliminated for chunk validators. Epoch mechanics and reward distribution details are documented at docs.near.org/concepts/basics/epoch.
What This Means for Validators: If you operate a chunk validator node, your storage provisioning model has changed. You no longer need to allocate large SSD capacity for shard state on chunk validator hardware. Shard rotation at epoch boundaries is now operationally negligible. If you operate or are considering a chunk producer role, the stateful requirements remain: full shard state storage is still required at that layer.
Frequently Asked Questions
What Is NEAR Protocol?
NEAR Protocol is a Layer-1 proof-of-stake blockchain that uses Nightshade sharding to process transactions across parallel shards. It has deployed stateless validation as its Phase 2 upgrade, allowing chunk validators to verify transactions without storing shard state locally. NEAR Protocol uses the NEAR token for transaction fees, staking, and governance. For full coverage, see: What Is NEAR Protocol?
Who Created NEAR Protocol?
NEAR Protocol was co-founded by Illia Polosukhin, co-author of the 2017 "Attention Is All You Need" paper that introduced the Transformer architecture underlying modern large language models, and Alex Skidanov, former software engineer at Microsoft and co-architect of the Nightshade sharding design. Both founders brought distinct technical backgrounds that shaped NEAR's research-first architecture. For full coverage, see: What Is NEAR Protocol?
What Is Stateless Validation in Blockchain?
Stateless validation is a blockchain architecture model in which validators verify transactions without maintaining a local copy of the network state. Instead of storing state, validators receive a state witness, a cryptographic proof containing only the state data needed to verify a specific block or chunk. NEAR has deployed stateless validation as Nightshade Phase 2; it is the first major Layer-1 to implement this model in production. For full coverage, see: What Is NEAR Stateless Validation?
How Does NEAR Sharding Work?
NEAR's Nightshade sharding splits the blockchain into parallel processing lanes called shards. Each shard processes a subset of transactions simultaneously and produces a shard-level block segment called a chunk. Validators are assigned to specific shards per epoch, and block producers aggregate all chunks from all shards into a single final block. For full coverage, see: How NEAR Works: Nightshade Sharding Explained
What Is a State Witness in NEAR?
A state witness in NEAR is a compact cryptographic proof generated by the chunk producer that contains all the shard state data a chunk validator needs to verify a specific chunk. It includes the state trie entries touched by the chunk's transactions, plus Merkle proofs of their inclusion in the shard state trie. State witnesses are Merkle proof-based attestations; they are not zero-knowledge proofs. For full coverage, see: What Is a State Witness?
What Are Chunk Validators in NEAR?
Chunk validators in NEAR are nodes responsible for validating individual shard chunks, the shard-level portions of each block. Under stateless validation, they do not store local shard state; they receive a state witness from the chunk producer and verify that the chunk's transactions apply correctly to the witnessed state. Chunk validators are distinct from chunk producers (who build chunks and maintain state) and block producers (who assemble final blocks). For full coverage, see: Chunk Validators vs. Chunk Producers
Does NEAR Use Proof of Stake?
Yes. NEAR uses Thresholded Proof of Stake, a variant in which validators are selected based on a minimum stake threshold rather than a strict top-N ranking by stake size. NEAR has approximately 100 active validators per epoch. NEAR token holders can delegate stake to validators without running their own infrastructure. For full coverage, see: What Is NEAR Protocol?
How Does Stateless Validation Improve Decentralization?
Stateless validation improves decentralization by removing the shard state storage requirement from chunk validators. Lower hardware requirements reduce the economic barrier to running a validator node. As more participants can afford to operate validators, the validator set expands, distributing network security across a larger and more geographically diverse set of operators. For full coverage, see: Why Stateless Validation Matters
What Is Dynamic Resharding?
Dynamic resharding is NEAR's planned Phase 3 upgrade that aims to allow the network to automatically split or merge shards based on real-time transaction demand, scaling throughput up or down without validator downtime or manual reconfiguration. It is not yet live. Stateless validation is an architectural prerequisite for dynamic resharding because stateless validators can be instantly assigned to new or reconfigured shards without a state sync operation. For full coverage, see: Dynamic Resharding: What Comes After Stateless Validation
What Are the Hardware Requirements for NEAR Validators After Stateless Validation?
Chunk validators no longer need high-capacity SSD storage for shard state under stateless validation; the dominant hardware cost for the chunk validation role has been removed. Chunk producers still require full shard state storage and have elevated hardware requirements. Specific hardware specifications for both roles are published in the NEAR validator documentation. For operational context, see: What Stateless Validation Means for Validators
Conclusion
NEAR Protocol's stateless validation upgrade separates chunk validation from state storage, reducing the hardware barrier for chunk validators and creating the technical foundation for Phase 3 dynamic resharding. Chunk validators now receive a state witness per chunk rather than maintaining a local shard state database. Shard rotation at epoch boundaries is frictionless. The validator pool is designed to expand as the hardware floor for chunk validation decreases.
The Nightshade roadmap positions this as a sequential build: Phase 1 established cross-shard congestion control, Phase 2 delivered stateless validation, and Phase 3 aims to add dynamic resharding once the stateless validator model makes instant shard reassignment operationally viable.
Next steps for developers and validators:
- NEAR developer documentation for full protocol specifications, SDK guides, and validator setup
- NEAR Rust SDK for building smart contracts in Rust
- NEAR JavaScript SDK for building smart contracts in JavaScript
- NEAR validator staking overview for staking setup and delegation
- NEAR Foundation grants for ecosystem project funding