NEAR Protocol: Stateless Validation Explained
Learn how NEAR Protocol uses stateless validation and Nightshade sharding to achieve 100,000+ TPS while reducing validator hardware requirements.
Disclaimer: This article is for informational purposes only and does not constitute financial or investment advice. Cryptocurrency markets are volatile and speculative. Consult a qualified financial adviser before making investment decisions.
Table of Contents
- The Origins of NEAR: Founders, History, and Mission
- How NEAR Protocol Works: Consensus, Tokens, and the Basics
- NEAR's Ecosystem: What You Can Build and Do
- Understanding Blockchain Sharding: The Foundation for Everything That Follows
- The Nightshade Sharding Roadmap: From Launch to Stateless Validation
- What Is NEAR Stateless Validation?
- NEAR vs. Ethereum vs. Solana: How the Architectures Compare
- Frequently Asked Questions
- Conclusion: Why Stateless Validation Matters for NEAR's Future
NEAR Protocol is a layer-1 proof-of-stake blockchain designed for scalability through a sharding architecture called Nightshade. Its native cryptocurrency, the NEAR token, powers gas fees, validator staking, and protocol governance. The protocol's stateless validation upgrade (Phase 2 of the Nightshade roadmap) lowers validator hardware requirements and advances network decentralization while targeting 100,000+ transactions per second (TPS) at full scale.
The blockchain trilemma, commonly attributed to Vitalik Buterin, holds that a blockchain can achieve at most two of three properties at once: scalability, security, and decentralization. NEAR Protocol's architectural choices, particularly stateless validation, are designed to address all three. By the end of this article, you will be able to explain what NEAR Protocol is, describe how stateless validation differs from stateful validation, understand what state witnesses and chunk validators do, and place stateless validation on NEAR's development roadmap relative to Ethereum's own stateless architecture work.
The Origins of NEAR: Founders, History, and Mission
NEAR Protocol was founded in 2018 by Illia Polosukhin and Alexander Skidanov. Polosukhin is a co-author of the landmark 2017 paper "Attention Is All You Need", the research that introduced the Transformer architecture underlying today's large language models, including GPT and BERT. Skidanov is a former Google engineer with a background in distributed systems research. Their combined credentials placed NEAR Protocol from its founding in the hands of researchers who had already produced foundational work in machine learning and large-scale distributed computing.
The founding motivation was practical: build a layer-1 blockchain that developers could actually ship applications on without sacrificing scalability. At the time, existing blockchains forced builders to choose between developer experience and network throughput. NEAR's design goal was to break that trade-off through a sharded architecture built from the ground up.
NEAR Protocol launched its mainnet in April 2020. The NEAR Foundation, a nonprofit organization, stewards the protocol's development, grant programs, and ecosystem growth. The Foundation is distinct from NEAR Protocol the network and from the NEAR token the asset. This distinction matters when reading official communications about the project.
How NEAR Protocol Works: Consensus, Tokens, and the Basics
NEAR Protocol secures its network through a proof-of-stake consensus model in which validators stake NEAR tokens as economic collateral to participate in block production and validation.
Proof-of-Stake: How NEAR Secures the Network
Proof-of-stake is the consensus mechanism NEAR uses to select validators and secure the network against dishonest behavior. Validators lock up NEAR tokens as economic collateral through a process called staking. They are then selected to produce blocks based on the size of their stake. NEAR uses a thresholded proof-of-stake (PoS) model: validators above a minimum stake threshold are eligible for selection, with larger stakes increasing selection probability. Validators who behave dishonestly risk slashing, the penalty mechanism that destroys a portion of a validator's staked tokens if they act against protocol rules or go offline.
Block finality on NEAR is governed by an algorithm called Doomslug, which allows block production to proceed without waiting for full Byzantine fault-tolerant finality on every block. Doomslug handles how blocks reach finality; Nightshade handles how the chain is partitioned across shards. These are separate components of NEAR's architecture, not interchangeable terms.
Validator hardware requirements are shaped directly by NEAR's sharding design. Before stateless validation, validators storing full shard state faced significant disk and memory demands. That connection between hardware cost and validator participation is the architectural problem stateless validation was designed to address. Full details are in the NEAR Protocol validator documentation.
The NEAR Token: Gas Fees, Staking, and Protocol Governance
The NEAR token is the native cryptocurrency of NEAR Protocol, serving three primary functions: paying gas fees (the transaction costs paid to validators for processing network activity), providing staking collateral for validators, and enabling participation in protocol governance.
NEAR produces blocks approximately every one second. The network currently processes thousands of transactions per second (TPS) across its active shards, with a long-term architecture target of 100,000+ TPS at full sharding with stateless validation. That figure is a design goal, not a current performance claim. The architecture is built to reach that throughput by distributing transaction processing across parallel shards rather than processing every transaction on a single chain. Staking rewards compensate validators for their participation in network security as a network participation incentive, not as an investment product.
NEAR's Ecosystem: What You Can Build and Do
NEAR Protocol supports a range of decentralized applications (dApps) across DeFi, gaming, NFTs, and Web3 social platforms. The following ecosystem components give developers and users multiple ways to interact with the network:
- Smart contract development: Contracts on NEAR are written in Rust or JavaScript/TypeScript and compiled to WebAssembly (WASM), a portable binary format used as the smart contract execution runtime on NEAR. The NEAR SDK supports both languages, making the platform accessible to a broad developer base.
- Ethereum developer access: Aurora, NEAR's EVM compatibility layer, allows Ethereum developers to deploy existing Solidity smart contracts on NEAR with minimal modification. Aurora is a separate product built on top of NEAR Protocol, not part of NEAR's native WASM environment.
- Cross-chain asset movement: The Rainbow Bridge, NEAR's Ethereum asset bridge, enables trustless asset transfers between NEAR Protocol and Ethereum. Trustless here means the bridge operates without requiring trust in a central party, allowing users to move tokens between the two networks without relying on a centralized custodian.
- Data availability for rollups: NEAR also offers a data availability layer (NEAR DA) that allows Ethereum rollups and other chains to use NEAR's sharded architecture for low-cost, high-throughput data availability, extending the benefits of NEAR's architecture beyond its own ecosystem.
Developers ready to build can start with the NEAR developer documentation at docs.near.org, which covers the NEAR SDK, smart contract deployment, and developer tooling in full.
Understanding NEAR's sharding architecture is the next step for grasping how the network delivers this ecosystem at scale.
Understanding Blockchain Sharding: The Foundation for Everything That Follows
Sharding is the architectural technique at the center of NEAR Protocol's scalability design, and understanding it is the foundation for understanding stateless validation.
What Is Blockchain Sharding?
Blockchain sharding is a horizontal partitioning technique borrowed from database design that splits a blockchain's transaction processing workload across multiple parallel processing partitions called shards. Instead of every node processing every transaction (which is how Bitcoin and pre-sharding Ethereum operate), sharding allows parallel processing across multiple chains simultaneously. Think of it like parallel checkout lanes at a supermarket: instead of one line processing all customers sequentially, multiple lanes handle different customers at the same time, multiplying the effective throughput of the system.
Sharding introduces a coordination challenge that single-chain architectures avoid. When a transaction involves accounts or smart contracts on different shards, the protocol must coordinate between shards to complete it, requiring receipts and callback messages across shard boundaries. These are called cross-shard transactions, and managing this coordination overhead is one of the central design problems in sharded blockchain architecture. It connects directly to why stateless validation matters for NEAR's long-term scalability.
Nightshade: NEAR's Sharding Architecture
Nightshade is NEAR Protocol's sharding architecture that maintains one logical blockchain while splitting transaction processing across parallel shards, each producing a subset of transactions called a chunk per block. All chunks from all shards are included in the same block, maintaining the appearance of a single unified chain while enabling parallel processing underneath.
Here is how Nightshade processes transactions:
- Each account on NEAR is assigned to a specific shard based on its account ID
- Transactions are routed to the shard that owns the sender's account
- Each shard produces a chunk of transactions for that block period
- All chunks from all active shards are assembled into a single block
- Block producers validate the block; chunk validators (post Phase 2) verify individual chunks
As of 2024, NEAR operates with six active shards, per NEAR's Nightshade sharding documentation. Phase 3+ of the Nightshade roadmap introduces dynamic resharding, which will allow the number of shards to scale automatically based on network demand rather than being fixed.
Cross-shard transactions require additional coordination steps: the sending shard generates a receipt, which the receiving shard processes in a subsequent block. This coordination complexity grows with the number of shards. Stateless validation reduces the validator-side overhead of managing state across shard boundaries by decoupling state storage from validation work entirely, contributing to more efficient cross-shard execution at scale.
Understanding Nightshade's phased development is the essential context for placing stateless validation on the roadmap, which the next section covers.
The Nightshade Sharding Roadmap: From Launch to Stateless Validation
The Nightshade sharding architecture has been deployed in phases, with each phase changing how validators interact with shard state.
| Phase | Name | What Changed | Validator Behavior | Status |
|---|---|---|---|---|
| Phase 0 | Simple Nightshade | Mainnet launch; no state sharding | All validators process all state on a single shard | Completed (April 2020) |
| Phase 1 | State Sharding | State distributed across multiple shards | Validators store and maintain the full state of their assigned shard | Completed |
| Phase 2 | Stateless Validation | State witnesses introduced; chunk validators verify without storing state | Chunk validators use state witnesses provided by block producers; no persistent state storage required | Active on mainnet as of late 2024 (verify current status at near.org/blog) |
| Phase 3+ | Dynamic Resharding | Shard count scales automatically based on network demand | Validator assignments adjust dynamically as shard count changes | In development |
The Phase 1 to Phase 2 transition is the conceptual core of this article. In Phase 1, each validator stored the complete state of its assigned shard locally, a significant hardware burden that grew as the shard accumulated more account data and contract storage. In Phase 2, that storage requirement is eliminated for chunk validators entirely: they receive exactly the state they need for each chunk in the form of a state witness, verify the chunk, and discard the witness.
Phase 2 (stateless validation) is the focus of the next section: exactly what it is, how it works, and what it changes for validators and users alike.
What Is NEAR Stateless Validation?
Stateless validation is a NEAR Protocol upgrade (Phase 2 of Nightshade) in which chunk validators verify transaction chunks without storing full shard state. Instead of maintaining persistent state data locally, validators receive state witnesses, cryptographic data packages generated by block producers, containing exactly the information needed to verify each chunk.
Stateless validation is not unique to NEAR; it is an architectural approach being explored across multiple blockchain ecosystems. NEAR's implementation is a specific, concrete deployment at the execution layer, distinct from Ethereum's stateless client roadmap, which operates at the data-access layer. NEAR's official terminology for this feature is "stateless validation," not "stateless clients" (Ethereum's term) or "stateless execution."
For the full technical specification, see the NEAR Foundation's stateless validation announcement.
The Problem: Why Stateful Validation Doesn't Scale
In a stateful sharding model, each validator must store and maintain the full state of its assigned shard locally. As the blockchain grows, this creates three compounding problems: hardware cost inflation that prices out smaller validators, centralization pressure that concentrates validation among well-funded node operators, and a scalability ceiling where adding more shards multiplies storage requirements proportionally across the validator set.
The table below shows how stateful and stateless validation compare across five dimensions:
| Dimension | Stateful Validation | Stateless Validation |
|---|---|---|
| State storage requirement | Each validator stores full shard state locally | Validators receive state witnesses; no persistent state stored |
| Hardware intensity | High disk I/O and storage requirements | Substantially lower storage requirements for chunk validators |
| Validator participation barrier | High: significant hardware investment required | Lower: chunk validators can run on less expensive hardware |
| Decentralization impact | Centralizing: high cost excludes smaller participants | Broadening: lower cost enables wider validator participation |
| Scalability ceiling | Adding shards proportionally increases storage burden | Shard count can increase without proportional per-validator storage growth |
As the network grows and state accumulates, the stateful model eventually forces a choice: raise hardware requirements further, reduce shard count, or accept validator centralization. Stateless validation breaks that constraint by separating who stores state from who verifies transactions.
The Solution: Stateless Validation Defined
Stateless validation removes the state storage requirement from chunk validators. Instead of maintaining a local copy of shard state, a chunk validator receives precisely the state data it needs for each chunk it verifies, packaged as a state witness from the block producer. After verification, the witness is discarded. No persistent storage occurs.
The practical consequence is that validators no longer need significant disk capacity to hold shard state. The network can increase shard count to improve throughput without proportionally increasing per-validator storage requirements. The validation work and the state storage work are now performed by different participants with different hardware profiles: block producers who maintain state, and chunk validators who verify without storing it.
State Witnesses: The Cryptographic Key
A state witness in NEAR Protocol is a cryptographic data package generated by a block producer that contains all the account balances and contract storage values a chunk validator needs to verify a specific transaction chunk, without requiring the validator to store the full shard state locally.
The mechanism works in five steps:
- A block producer maintains full shard state and produces a chunk for its assigned shard
- The block producer generates a state witness for that chunk, containing the relevant state values drawn from NEAR's state trie (the cryptographic data structure recording all account balances and contract storage)
- The state witness is transmitted to the chunk validators assigned to that shard for this block
- Chunk validators use the witness to verify transaction correctness for each transaction in the chunk
- Chunk validators discard the witness after verification, with no persistent state storage
Think of a state witness like a certified receipt from the block producer. It proves the account had sufficient balance and the contract state was valid at the time of the transaction, without the validator needing to hold the entire ledger. The receipt contains exactly what is needed to verify that specific transaction, and nothing more.
The term used throughout NEAR's protocol specification is "state witness," not "state proof" or any other variant. Readers looking for technical specification depth can consult the NEAR Enhancement Proposals (NEPs) repository.
Chunk Validators vs. Block Producers: Two Tiers of Network Participation
A chunk validator on NEAR is a validator node that verifies a specific transaction chunk using a state witness provided by a block producer, without storing full shard state locally.
Block producers and chunk validators form a two-tier architecture:
- Block producers maintain full shard state, produce blocks, and generate state witnesses for each chunk they produce. They carry higher hardware requirements because they must store and update shard state continuously.
- Chunk validators receive state witnesses from block producers, use them to verify the transactions in a specific chunk, and then discard the witnesses. They do not maintain persistent state and do not produce blocks.
Chunk validators are randomly rotated across shards per epoch, with each epoch lasting roughly 12 hours on NEAR. This rotation prevents any validator from being assigned to the same shard long enough to collude with others or become a targeted attack surface for that shard.
| Dimension | Block Producers | Chunk Validators |
|---|---|---|
| State storage requirement | Maintain full shard state locally | No persistent state storage required |
| Hardware intensity | High: significant storage and compute | Substantially lower: no state storage burden |
| Role in block production | Produce blocks for their assigned shard | Do not produce blocks |
| Role in stateless validation | Generate state witnesses for their chunks | Receive and verify state witnesses; discard after use |
| Decentralization impact | Fewer nodes due to high hardware cost | More nodes enabled by lower hardware requirements |
Because chunk validators do not store persistent state, the capital cost to run one is substantially lower than running a block-producing validator node. This broadens who can participate in securing the NEAR network.
What Stateless Validation Means for Decentralization and Scalability
Stateless validation produces three interconnected outcomes for the NEAR network: broader decentralization, improved scalability, and measurable progress on the blockchain trilemma.
Decentralization. Lower hardware requirements for chunk validators expand the validator set by reducing the capital barrier to running a validator node. Block producers still require higher hardware specifications, but chunk validators represent the larger and growing share of active validation work as shard count increases. The result is a broader, more accessible path to network security participation.
Scalability. Decoupling state storage from validation work means NEAR can increase shard count without proportionally increasing per-validator hardware requirements. The network targets 100,000+ TPS with full sharding and stateless validation, a design goal supported by the architecture, not a current performance figure. Validation throughput no longer bottlenecks on state storage input/output, which was the primary constraint in Phase 1.
Blockchain trilemma advancement. The blockchain trilemma (commonly attributed to Vitalik Buterin) holds that a blockchain can achieve at most two of scalability, security, and decentralization simultaneously. Stateless validation addresses all three at once. Scalability improves through higher validation throughput per shard. Decentralization improves through a lower hardware bar for chunk validators. Security improves through random chunk validator rotation that prevents targeted attacks on specific shards.
Key takeaways:
- Stateless validation is NEAR's Phase 2 Nightshade upgrade, removing the state storage requirement from chunk validators
- Block producers generate state witnesses; chunk validators use them to verify chunks and then discard them
- Chunk validators do not store full shard state. This is the defining distinction from stateful validation.
- Lower hardware requirements for chunk validators broaden who can participate in network security
- NEAR targets 100,000+ TPS with full sharding; stateless validation removes a primary bottleneck on that path
To understand how NEAR's approach compares to what Ethereum and Solana are building, the next section examines the architectural trade-offs across these three networks.
NEAR vs. Ethereum vs. Solana: How the Architectures Compare
NEAR Protocol, Ethereum, and Solana represent three distinct architectural approaches to the same core challenge: achieving high transaction throughput at scale. Understanding the differences helps evaluate each protocol's design trade-offs without ranking one as superior.
NEAR vs. Ethereum: Execution Sharding vs. Data Sharding
NEAR and Ethereum differ in three fundamental architectural dimensions: their sharding approach, their stateless architecture implementation, and their developer tooling.
On sharding, NEAR pursues execution sharding through Nightshade. The transaction processing workload itself is split across parallel shards, with each shard producing chunks that are assembled into blocks. Ethereum pursues data sharding through danksharding (Ethereum's data availability sharding approach), which focuses on providing cheap data storage for Layer-2 rollups rather than sharding execution at the base layer. Ethereum's execution scaling is handled by rollups built on top of the base chain, not by partitioning the base chain itself.
On stateless architecture, NEAR's stateless validation is an active Phase 2 implementation. Ethereum has a roadmap for stateless clients built around Verkle trees, a cryptographic data structure that allows Ethereum light clients to verify state without storing the full state trie, which remains in active development. Both NEAR and Ethereum are pursuing stateless architectures, but at different layers. NEAR's approach is at the execution and validation layer; Ethereum's stateless client work operates at the data-access layer. These are parallel approaches to the same fundamental problem, not competing implementations of the same design.
On developer tooling, NEAR uses WebAssembly (WASM) as its smart contract execution runtime, with Rust and JavaScript/TypeScript as the primary smart contract languages. Ethereum uses the Ethereum Virtual Machine (EVM) with Solidity as the primary language. NEAR offers EVM compatibility through Aurora, making it accessible to Solidity developers without requiring them to learn Rust or JavaScript for contract development.
NEAR and Ethereum are designed for different architectural trade-offs rather than being directly comparable on a single performance axis. For Ethereum's detailed data sharding roadmap, see Ethereum's danksharding roadmap.
| Dimension | NEAR Protocol | Ethereum |
|---|---|---|
| Consensus mechanism | Proof-of-stake with Doomslug finality | Proof-of-stake with Casper FFG |
| Sharding approach | Execution sharding (Nightshade) | Data sharding (danksharding) for L2 rollups |
| Stateless architecture | Stateless validation (Phase 2, active) | Stateless client roadmap via Verkle trees (in development) |
| Smart contract language | Rust, JavaScript/TypeScript (native); Solidity via Aurora | Solidity/Vyper (native EVM) |
| Execution runtime | WebAssembly (WASM) | Ethereum Virtual Machine (EVM) |
| EVM compatibility | Yes, via Aurora layer | Native |
NEAR vs. Solana: Sharded Scale vs. Single-Chain Speed
Solana takes a different path to high throughput: a single-chain architecture that processes all transactions on one chain without sharding, relying on high validator hardware requirements to sustain network performance. This design achieves significant throughput but places the hardware cost burden on every validator in the network, which constrains how many independent participants can run validator nodes economically.
NEAR's sharded architecture distributes the workload across parallel shards and, with stateless validation, reduces per-validator hardware requirements for chunk validators. The design philosophy difference is one of trade-offs: Solana prioritizes single-chain performance consistency; NEAR distributes load across shards to preserve validator accessibility as throughput scales.
Frequently Asked Questions About NEAR Protocol and Stateless Validation
The following questions address the most common search queries about NEAR Protocol and stateless validation.
What is NEAR Protocol?
NEAR Protocol is a layer-1 proof-of-stake blockchain designed for high throughput through a sharding architecture called Nightshade. Validators stake the NEAR token to participate in block production and network security. The protocol targets 100,000+ TPS at full sharding scale and launched its mainnet in April 2020. Its stateless validation upgrade (Phase 2) reduces validator hardware requirements and broadens network participation.
What is stateless validation in NEAR?
Stateless validation is NEAR's Phase 2 Nightshade upgrade in which chunk validators verify transaction chunks without storing full shard state locally. Block producers generate cryptographic data packages called state witnesses for each chunk. Chunk validators receive these witnesses, verify the transactions, and discard the witnesses. The result is lower hardware requirements for validation and a more accessible validator participation model.
What is Nightshade sharding?
Nightshade is NEAR Protocol's sharding architecture that maintains one logical blockchain while splitting transaction processing across parallel shards, each producing a chunk of transactions per block. All chunks are assembled into a single block. Transactions are assigned to shards by account ID. As of 2024, NEAR operates six shards, with Phase 3+ introducing dynamic resharding to scale shard count based on demand.
Who created NEAR Protocol?
NEAR Protocol was co-founded in 2018 by Illia Polosukhin and Alexander Skidanov. Polosukhin is a co-author of the 2017 "Attention Is All You Need" paper that introduced the Transformer architecture behind modern AI models including GPT. Skidanov is a former Google engineer with distributed systems expertise. The protocol launched on mainnet in April 2020, with NEAR Foundation serving as the nonprofit steward.
What is a chunk validator?
A chunk validator on NEAR is a validator node that verifies a specific transaction chunk within a block using a state witness provided by a block producer, without storing the full state of its assigned shard. Chunk validators are randomly rotated across shards each epoch, reducing collusion risk. Because they require no persistent state storage, their hardware requirements are substantially lower than those of block-producing validators.
What are state witnesses?
State witnesses are cryptographic data packages that block producers generate for each chunk they produce. Each witness contains the account balances and contract storage values needed to verify the transactions in that chunk, drawn from the state trie. Chunk validators use the witness to check transaction correctness, then discard it. State witnesses are what make stateless validation possible: they carry exactly the state information needed for verification without the validator needing to store the full ledger.
How fast is NEAR Protocol?
NEAR produces blocks approximately every one second, giving it low transaction finality times relative to many layer-1 networks. Current sustained throughput across active shards is measured in thousands of TPS, with the architecture designed to reach 100,000+ TPS at full sharding and stateless validation scale. Speed on NEAR has two dimensions: throughput (TPS across all shards) and latency (time to finality), both of which improve as shard count increases under the Nightshade model.
What phase is NEAR's sharding roadmap currently on?
As of late 2024, NEAR is operating in Phase 2 (stateless validation), which is active on mainnet. Phase 0 (mainnet launch with no state sharding) and Phase 1 (state sharding with validator-held state) are both complete. Phase 3+ (dynamic resharding, where shard count scales based on demand) is in active development. Verify current deployment status and roadmap updates at near.org/blog.
How is NEAR different from Ethereum?
NEAR and Ethereum differ primarily in three areas. First, their sharding approach: NEAR uses execution sharding (Nightshade) to distribute transaction processing; Ethereum uses data sharding (danksharding) to support Layer-2 rollups, with execution scaling left to those rollups. Second, their stateless architecture status: NEAR has active stateless validation; Ethereum's stateless client work via Verkle trees is still in development. Third, their developer tooling: NEAR's native environment uses WASM and Rust/JavaScript; Ethereum uses the EVM and Solidity natively.
Is NEAR Protocol a good investment?
This article does not provide investment advice and cannot assess NEAR Protocol as an investment. Token prices and network adoption figures change rapidly. For technical roadmap information, see NEAR Foundation's official website at near.org. For investment decisions, consult current market data and independent financial analysis from a qualified financial adviser.
Conclusion: Why Stateless Validation Matters for NEAR's Future
NEAR Protocol's stateless validation upgrade represents the most structurally significant change to the Nightshade architecture since mainnet launch. By decoupling validator state storage from validation work through state witnesses and chunk validators, stateless validation breaks the direct link between blockchain growth and validator hardware cost. This is the practical answer to the blockchain trilemma challenge that opened this article: more participants can validate, more shards can be added, and the network becomes harder to attack through targeted shard concentration.
Phase 3+ (dynamic resharding) is the next milestone on NEAR's roadmap. It will allow the number of active shards to scale automatically in response to network load rather than requiring manual protocol upgrades. The architecture built through Phase 2 provides the foundation for that dynamic scaling to function without proportionally increasing the hardware burden on individual validators.
For readers who want to go further, the next steps depend on your perspective:
- Investors and researchers: Follow NEAR Foundation's official website at near.org and the NEAR Foundation blog for roadmap announcements, Phase 3+ development updates, and ecosystem news.
- Developers: The NEAR developer documentation at docs.near.org covers the NEAR SDK, smart contract deployment in Rust and JavaScript/TypeScript, and the full technical architecture of Nightshade.
- Validators and node operators: The NEAR Protocol validator documentation details validator requirements, staking mechanics, and the hardware specifications for both block producers and chunk validators under stateless validation.
Stateless validation is not a performance tweak. It is an architectural redesign of who can participate in securing a sharded blockchain, and that redesign gives NEAR Protocol a credible path to scaling throughput without scaling centralization.