什么是 NEAR Protocol？无状态验证
Learn what NEAR Protocol is, how Nightshade sharding works, and what stateless validation means for validators and decentralization.
NEAR Protocol 完成了其 Nightshade Phase 2 无状态验证升级，而这项变更对网络中的每位参与者都有不同的影响。评估 NEAR 作为智能合约平台 的开发人员需要了解该架构的实际作用。评估 NEAR 技术路线图的投资者希望了解无状态验证是否是一项有意义的进展。在规划其基础设施的验证者需要了解操作上的 Delta：哪些内容会改变，哪些保持不变，以及这对硬件意味着什么。
本文涵盖了所有三个方面，从 NEAR 是什么开始，逐步深入到无状态验证的工作原理、状态见证是什么、Chunk 验证者和 Chunk 生产者如何划分他们的职责，以及一旦无状态验证为其奠定基础，Phase 3 动态分片旨在实现什么目标。
目录
- 什么是 NEAR Protocol？
- NEAR 解决的问题
- NEAR 的运作原理：Nightshade 分片技术详解
- 什么是 NEAR 无状态验证？
- 为何无状态验证至关重要
- 动态重分片：无状态验证之后的下一步
- NEAR 与以太坊及 Solana 的对比
- NEAR 生态系统
- NEAR 代币、质押及验证者经济学
- 无状态验证对验证者意味着什么
- 常见问题解答
- 总结
什么是 NEAR Protocol？
NEAR Protocol 是一个 Layer-1 权益证明 区块链，旨在实现高可扩展性、低交易成本和开发者易用性。NEAR 区块链使用一种称为Nightshade 分片的分片架构，将网络划分为并行处理通道，并已将其无状态验证作为 Nightshade Phase 2 升级部署，以实现去中心化、高吞吐量的交易处理。NEAR Protocol（区块链网络）使用 NEAR（原生代币）来支付交易费用和质押。
NEAR Protocol 由 Illia Polosukhin（2017年“注意力即一切”论文的合著者，该论文介绍了现代大型语言模型所基于的 Transformer 架构）与 Alex Skidanov（前微软软件工程师，Nightshade 分片设计的联合架构师）共同创办。
NEAR Protocol 的关键特征：
- **Nightshade 分片：**跨多个分片并行处理交易，每个分片生成一个称为“块段”的分片级区块片段。
- **无状态验证（第二阶段，已上线）：**块段验证者无需存储本地分片状态，而是使用状态见证来验证交易。
- **WebAssembly (Wasm) 运行时：**智能合约编译成 Wasm，支持 Rust 和 JavaScript 作为开发语言。
- **人类可读的账户名称：**账户采用一种命名格式（例如：yourname.near），而非原始的加密地址。
- **低交易费用：**NEAR 的费用模型旨在随着网络吞吐量通过分片扩展而保持可预测性。
- **开发者资助：**NEAR 基金会分发生态系统资金，以支持与协议相关的项目
NEAR 使用阈值证明质押（一种验证者根据最低质押阈值而非严格的排名靠前 N 位来选择的变体）。这区分了 NEAR 的共识与标准的委托证明质押。NEAR 每个时期大约有 100 名活跃验证者，而 NEAR 代币持有者可以将质押委托给验证者，而无需运行自己的节点。
NEAR 的 WebAssembly (Wasm) 运行时以沙盒化、确定性、语言无关的格式执行智能合约。开发者可以使用 Rust 或 JavaScript 这两种拥有庞大现有社区的主流语言编写合约，并将其编译成 Wasm 以供执行。确定性执行对于无状态验证尤为重要：给定通过状态见证提供的相同状态输入，每个验证者都会产生相同的输出，从而使无状态验证在数学上得以健全。对于评估 NEAR 的开发者，请参阅 NEAR 无状态验证是什么？ 部分，了解此架构如何影响网络运行。
NEAR 用于智能合约、去中心化应用 (dApps)、DeFi 协议、NFT 平台、游戏应用，以及通过 Aurora 生态系统项目与以太坊进行跨链交互。
NEAR 解决的问题
区块链设计者面临一个广为接受的权衡，称为可扩展性三难困境：构建一个同时兼具可扩展性、安全性与去中心化的网络是困难的，因为优化其中两个特性往往会牺牲第三个。此框架与以太坊联合创始人 Vitalik Buterin 相关，它是一种设计上的权衡而非绝对限制，但它描述了每个主要区块链都以不同方式应对的真实取舍。
以太坊历史上优先考虑安全性和去中心化，其吞吐量限制在拥堵期间导致了高昂的 Gas 费。Solana 通过一种单链、高硬件要求的架构来优先处理吞吐量和安全性，这使得验证者参与集中在能够负担所需基础设施的运营商之间。在高负载下，这两种方法都未能同时满足这三个属性。
NEAR 的 Nightshade 分片架构和无状态验证（Stateless Validation）升级旨在解决这三个维度的问题：分片通过分散交易处理来提高吞吐量，无状态验证降低了验证者的硬件要求以支持更广泛的参与，而整体设计在整个过程中保持了加密安全性。NEAR 是否能在实际的大规模应用中实现这一目标仍是一个悬而未决的问题。进一步扩展此模型的第三阶段动态重分片（Phase 3 Dynamic Resharding）目前仍在开发中。
NEAR 运作原理：Nightshade 分片详解
Nightshade 分片是 NEAR 协议并行交易处理的架构。它将区块链划分为被称为分片（shards）的独立处理通道（即同时处理网络交易子集的并行处理通道）。每个分片对区块的贡献被称为 chunk（区块的分片级部分；每个分片在每个区块间隔产生一个 chunk）。验证者在每个纪元（epoch）被分配到特定的分片，生成的 chunk 随后会被组装成一个最终区块。（Nightshade 分片博客文章)
将 Nightshade 想象成一条多车道高速公路，而不是一条单行道。在单车道系统中，每笔交易都必须排在其他交易后面。Nightshade 构建了平行车道：每个分片（shard）是一条车道，而每个数据块（chunk）是该车道在给定区块间隔内处理的总流量的一部分。从技术上讲：NEAR 维护一个逻辑链，该链被物理划分为多个分片。每个分片处理自己的交易集，生成一个数据块，这些数据块由区块生产者合并成一个统一的区块。
NEAR Protocol 分片技术的运作方式：
["入站交易会被路由到负责发送方账户的分片。","每个分片并行处理其分配的交易，同时与其他所有分片进行。","每个分片上的验证者集生成一个包含其已处理交易的区块。","区块验证者验证每个区块中的交易是否有效。","区块生产者将所有分片中的区块聚合到一个最终区块中。","最终区块被添加到链中，并计算验证者奖励。"]
验证者分片分配在每个周期边界都会发生变化。在无状态验证之前，切换到新的分片需要下载并同步该分片的完整状态，这是一项耗时且 I/O 密集的操作。无状态验证改变了这一点，具体描述在下方的 The Nightshade Roadmap 表格中。
The Nightshade Roadmap
Nightshade 是一个多阶段的升级计划。每个阶段都建立在先前阶段的基础之上，而无状态验证是三个计划阶段中的第二个阶段。
| 阶段 | 名称 | 关键特性 | 状态 |
|---|---|---|---|
| 第 1 阶段 | 拥塞控制 | 协议层级的跨分片收据流量限制，防止分片过载对全网产生连锁反应 | 已上线 |
| 第 2 阶段 | 无状态验证 | 区块分片验证者通过状态证明 (State Witnesses) 验证交易，无需存储本地分片状态 | 已上线 |
| 第 3 阶段 | 动态分片 | 网络根据实时交易需求自动拆分或合并分片 | 计划中 |
最后验证：2025年。请查看 near.org 以获取最新路线图状态。
第一阶段引入了拥堵控制机制，用于管理跨分片交易流，确保分片过载不会在网络中级联。第二阶段（无状态验证）是本文深入介绍的当前升级。第三阶段（动态重分片）已计划进行；请参阅 动态重分片：无状态验证之后是什么 以了解为何第二阶段是第三阶段的先决条件。
NEAR 无状态验证是什么？
NEAR 无状态验证是一种区块链架构模型，在此模型中，分块验证者在不存储分片状态本地跟单的情况下验证分片交易。相反，验证者会收到状态见证（由分块生产者生成的紧凑密码学证明），其中仅包含验证特定分块所需的状态数据。这是 Nightshade 第 2 阶段，作为实时协议升级部署。（Nightshade 第 2 阶段博客文章)
在无状态验证之前，分配到某个分片的每个验证者都必须维护该分片状态的本地副本，并且该副本需要持续更新。存储分片内每个账户的所有账户余额、智能合约存储值以及其他状态条目是主要的硬件要求。当验证者在纪元边界轮换到新的分片分配时，他们必须下载并同步新分片的全部状态，然后才能开始验证，这个过程通常需要数小时的 I/O 工作。
无状态验证完全取消了对块片段验证者的这项要求。块片段生产者（即维护完整分片状态的有状态节点）在生成每个块片段时会同时生成一个状态见证，并将这两者广播给块片段验证者。块片段验证者无需任何本地状态存储，即可参照状态见证对块片段进行验证。有关状态见证的具体内容及其生成方式的详细说明，请参阅什么是状态见证？。
这两款模型的实际差异：
| 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 |
重要性：NEAR 能够以更低的基础设施成本支持更多的验证者，这是对网络去中心化的直接改进。
有关无状态验证如何分步运行的过程，请参见 NEAR 无状态验证分步工作原理。有关分块验证者与分块生产者具体作用的说明，请参见 分块验证者 vs. 分块生产者。
NEAR 无状态验证分步工作原理
在 NEAR 网络中，针对每个处理过的分片，无状态验证流程如下：
- 交易被提交到网络并路由到负责发送者账户的分片
- 区块片段生产者在本地分片状态数据库中执行其分配分片的交易
- 区块片段生产者生成一份状态见证，其中仅包含该片段交易触达的状态条目，以及这些条目包含在分片状态 Merkle 树中的 Merkle 证明
- 区块片段生产者将区块片段和状态见证一起广播给该分片分配的区块片段验证者
- 区块片段验证者接收状态见证并验证片段中的交易是否正确应用于见证状态，无需本地状态数据库
- 验证后的区块片段被转发给区块生产者，由其将所有分片区块片段聚合到最终区块中
这对验证者意味着什么： 区块分片验证者（Chunk validators）不再需要维护或同步分片状态。每个分片块在到达时都会附带其独立的自包含证明包（Proof package）。当您的验证者在纪元（Epoch）边界轮换到新的分片时，无需下载任何状态。您将开始接收该分片块的状态见证人（State witnesses），并立即开始验证。
为什么这很重要：状态存储（区块片段生产者）与状态验证（区块片段验证者）的分离，使得验证者池能够在硬件成本不随之成比例增加的情况下扩大规模。
什么是状态见证？
NEAR 中的状态见证 (state witness) 是由分片生产者 (chunk producer) 生成的一种紧凑加密证明，包含了分片验证者 (chunk validator) 验证特定分片时所需的所有分片状态数据。分片验证者在接收分片数据的同时也会收到状态见证，并利用它来确认交易的有效性，而无需查询任何本地状态数据库。
可以把状态见证（state witness）想象成文件柜中经过公证的摘录。分片块生产者（chunk producer）无需将整个文件柜运送给每个验证者，而是仅提取与该分片块交易相关的页面，进行加密认证，并只发送必要的部分。这个类比在实际操作层面同样适用：验证者收到的是一个自包含的证明包，而不是完整的状态跟单。
就技术层面而言：状态见证（state witness）包含特定区块（chunk）中交易所涉及的状态树（state trie）条目（账户余额、合约存储值），以及这些条目被包含在当前分片状态树中的默克尔证明（Merkle proofs）。接收到该见证的验证者可以验证每个默克尔证明，以确认这些状态条目是真实的，然后根据这些条目执行交易，以确认该区块的输出是正确的。
状态见证是如何生成和使用的：
["1. 块生产者在本地分片状态上执行其区块内的所有交易。","2. 在执行过程中，它会记录每一个被读取或写入的状态树条目。","3. 它生成 Merkle 证明，以证明每个记录的条目属于分片状态树。","4. 它将这些条目和证明打包成状态见证 (state witness)。","5. 块验证者接收见证，验证 Merkle 证明，并在提供的条目上重新执行交易。"]
一个对技术读者而言重要的澄清：NEAR 的状态见证（state witnesses）是基于 Merkle 证明（Merkle proof）的状态数据证明（attestations of state data）。它们并非零知识证明（zero-knowledge proofs）。该机制不涉及 ZK 电路（ZK circuits）或证明系统（proof systems）；它使用标准的 Merkle 树包含性证明（inclusion proofs）来认证特定的状态条目是分片状态（shard state）的真实组成部分。
这对验证者意味着什么： 状态见证（state witness）是让您的无状态验证（stateless validation）成为可能的数据包。您无需信任分块生产者（chunk producer）的状态数据库；您需亲自验证包含在见证中的 Merkle 证明。如果证明通过且交易针对提供的分录重新执行正确，则该分块是有效的。
这一点的重要性：因为状态见证是自包含且可验证的，任何验证者都可以在不预先了解分片历史的情况下检查任何分片，这为频繁、无缝的分片重新分配打开了大门。
分片验证者 vs. 分片生产者
NEAR 中的 Chunk validators（分块验证者）是负责验证单个分片分块（即每个区块的分片级部分）的节点。在无状态验证模式下，分块验证者不存储或维护本地分片状态。它们从分块生产者（Chunk producer）接收状态见证（State witness），并利用其来验证分块中的交易是否正确应用于见证状态。
区块生产者是有状态的对应方。区块生产者维护其分配的分片状态的本地完整跟单，通过执行针对该状态的交易来构建区块，生成状态见证，并将区块和见证广播给区块验证者。由于其状态存储的义务，区块生产者需要更高的硬件要求。这是使网络的其余部分能够无状态运行的有状态层。
块生产者是第三种独立角色：它们将所有分片中经过验证的数据块聚合到最终区块中。不要混淆这三种角色；它们拥有不同的功能、状态需求和硬件配置。
| 维度 | Chunk 验证者 | Chunk 生产者 |
|---|---|---|
| 角色 | 验证 Chunk 交易是否符合状态见证 | 构建 Chunk，执行交易，生成状态见证 |
| 状态存储 | 无需 | 本地维护完整的 Shard 状态 |
| 状态见证 | 接收并验证 | 生成并广播 |
| 硬件等级 | 较低 (无持久状态存储) | 较高 (状态存储 I/O 是主要成本) |
| Shard 分配 | 每个 Epoch 轮换；无状态验证下无缝 | 分配到 Shard；维护状态连续性 |
NEAR 使用一个纪元（NEAR 的时间单位，大约 12 小时，在其结束时验证者分片分配将进行轮换）来管理验证者轮换。在每个纪元边界，块验证者会被重新分配到分片。在之前有状态模型下，这种轮换需要下载并同步新分片的完整状态，这项昂贵的操作减缓了验证者重新分配并集中了验证者集合。在无状态验证下，被重新分配到新分片的验证者只需开始接收该分片区块的状态见证，并立即开始验证。质押奖励在纪元边界计算和分发。(NEAR validator documentation,) NEAR epoch documentation)))
这对验证者意味着： 纪元边界的分片轮转不再需要状态下载。如果您的验证者在下一个纪元从分片 A 被重新分配到分片 B，您将开始接收分片 B 分块 (Chunk) 的状态见证，并能在新纪元开启后的几秒钟内开始验证。
为什么这很重要：无缝的分片轮换使得更大规模的验证者群体能够参与，因为在无状态模型下，重新分配的运营成本几乎为零。
为什么无状态验证至关重要
无状态验证通过取消分片验证者存储分片状态的要求，提升了 NEAR 的去中心化程度。由于对存储和硬件的要求降低，意味着更多参与者可以运行验证者节点，从而扩大活跃验证者集，并将网络安全分散给更广泛的运营商群体。
该机制链条非常直接：状态见证者（state witnesses）消除了区块片段验证者（chunk validators）存储分片状态的需求，从而去除了验证角色最主要的硬件成本。随着硬件门槛的降低，更广泛的运营商群体可以更经济地运行区块片段验证者。一个规模更大、地理分布更广的验证者池降低了集中风险，并增强了网络抵御协同干扰的能力。
无状态验证本身并不会改变 NEAR 的矿工费模型；交易费用仍由计算复杂度和网络需求决定。然而，通过为第三阶段动态分片创建架构先决条件，无状态验证为随着交易量增长而产生的费用稳定性奠定了基础：更多的分片意味着更多的处理能力，并且该容量可以扩展而不会导致费用不成比例地增加。关于动态分片如何在此基础上进行构建，请参阅 动态分片：无状态验证之后是什么。
NEAR 的无状态验证升级通过将状态存储与状态验证分离，从而强化了其技术基础。这一结构性变化影响着验证者经济模型、网络去中心化，以及弹性吞吐量扩展的可行性。
--- ## 动态重分片：无状态验证之后是什么
动态分片 (Dynamic resharding) 是 NEAR 计划的第三阶段升级，旨在根据实时交易需求，允许网络自动分割或合并分片，从而实现吞吐量的动态调整，而无需验证者停机或手动重新配置。
无状态验证与动态分片之间的先决关系是架构性的。在有状态验证下，将验证器轮换到一个新分片需要同步该分片的全部状态，这个过程耗时数小时。动态添加新分片将需要分配给它的所有验证器完成此同步，然后才能开始任何验证。这种操作瓶颈使得即时分片拆分变得不切实际。
无状态验证消除了那个瓶颈。因为分片验证者不再预先加载分片状态，所以他们可以被即时分配到新的分片、已拆分的分片或已合并的分片配置中，并立即开始验证；状态见证器为每个分片提供了他们所需的一切。阶段 3 旨在利用这一特性，允许协议在单个分片接近满载时自动增加分片数量，并在需求下降时减少分片数量。
第 3 阶段的动态重分片 (Dynamic Resharding) 尚未上线。NEAR 的路线图将其描述为一项计划中的升级。协议路线图可能会有所变动；请查看 near.org 以了解最新的开发状态。
为什么这很重要：无状态验证的直接影响是降低了分块验证者的硬件要求。其后续的重大意义在于，它从架构上让弹性吞吐量扩展变得可行，而这在第二阶段之前是不可能实现的。
NEAR 对比 以太坊和 Solana
NEAR 与以太坊在三个可衡量的方面有所不同：NEAR 使用 Nightshade 分片技术跨并行分片处理交易，而以太坊则作为单一执行链运行；NEAR 已将无状态验证作为现有的协议功能部署，而以太坊的等效提案 (EIP-4762) 截至 2025 年仍处于研发阶段；此外，NEAR 的智能合约编译为 WebAssembly，并可以使用 Rust 或 JavaScript 编写，而以太坊的主要智能合约环境是以太坊虚拟机 (EVM) 上的 Solidity。
| 维度 | NEAR 协议 | 以太坊 | Solana |
|---|---|---|---|
| 共识机制 | 阈值权益质押证明 | 权益质押证明 (LMD-GHOST/Casper) | 历史证明 + 权益质押证明 |
| 分片方案 | Nightshade 分片（多分片，已上线） | 单一执行链（无分片） | 单一全局状态（无分片） |
| 无状态验证 | 已上线（Nightshade 第 2 阶段） | 提案中（EIP-4762，开发中） | 不适用 |
| 智能合约语言 | Rust、JavaScript（编译为 Wasm） | Solidity (EVM) | Rust、C、C++ |
| 验证者硬件配置 | 第 2 阶段下的区块分片验证者要求较低 | 中等 | 高（CPU、内存、NVMe SSD） |
以太坊（Ethereum）的无状态客户端提议： 以太坊对无状态客户端的研究与 NEAR 的第 2 阶段升级有着相同的概念目标，即允许节点在不存储完整状态的情况下验证区块。以太坊在 EIP-4762, 中提出的方案要求将底层状态结构从 Merkle Patricia Tries 转换为 Verkle Trees。这是一项为期多年的协议迁移，截至 2025 年仍处于研发阶段。NEAR 已经将其无状态验证实现部署为正式的协议功能；而以太坊的对应方案虽已提议但尚未部署。这些是处于不同开发阶段、追求相似架构目标的独特实现。
Solana 的架构权衡：Solana 通过单一分片架构实现高交易吞吐量，在该架构中，所有验证者都会处理所有交易，并对完整的全局状态进行操作。这种方法提供了高性能，但要求验证者维护大量的硬件（高端 CPU、大内存分配、快速 NVMe SSD），这导致验证者参与的集中化，集中在拥有大量基础设施资源的运营商手中。NEAR 的分片加无状态方法旨在实现可比的吞吐量能力，同时允许分片验证者以较低的硬件要求运行。NEAR 也与其他 Layer-1 平台市场竞争，如 Avalanche 和 Move 链（如 Aptos 和 Sui），尽管这些架构与 NEAR 的分片方法大相径庭。
NEAR：当前的优势与局限性
优势：
- Nightshade 分片已上线，并正在跨并行分片处理交易
- 无状态验证（第二阶段）已部署，降低了区块片段（chunk）验证者的硬件门槛
- WebAssembly 运行时支持 Rust 和 JavaScript，与仅限 Solidity 的环境相比，降低了开发者的学习门槛
- 设计上交易费用低廉，其费率模型旨在通过分片实现扩展
- 开发者可通过 NEAR 基金会申请资助
["NEAR 的生态系统在锁仓总量和开发者活跃度方面小于以太坊","第3阶段动态分片尚未上线","开发者社区规模小于 Solana"]
NEAR 生态系统
NEAR 基金会是一家总部位于瑞士的非营利组织，负责监督 NEAR 协议的生态系统发展、开发者资助金、合作伙伴关系以及协议治理。它有别于负责协议开发的核心工程团队。该基金会管理在 NEAR 基础设施上构建的项目的资助金，并支持开发者入驻。
NEAR Protocol 支持多种应用程序类别，包括 DeFi 协议、NFT 平台、游戏应用以及社交媒体平台。NEAR 的开发者工具专为易用性而设计：支持 Rust 和 JavaScript（均为核心主流语言）、人类可读的账户名称，并提供文档支持：docs.near.org。
Aurora 是一个兼容以太坊虚拟机 (EVM) 的执行层，构建在 NEAR 基础设施之上，允许开发者无需重写代码即可在 NEAR 上部署 Solidity 智能合约。Aurora 是一个独立的生态系统项目，并非 NEAR Protocol 的功能。Rainbow Bridge 实现了无需信任的资产转移，专门在 NEAR 和 Ethereum 之间进行，允许用户在两个网络之间转移 ETH 和 ERC-20 代币。NEAR 还提供数据可用性服务 (NEAR DA)，供寻求低成本、高吞吐量数据可用性层的以太坊 Rollup 和 Layer-2 网络使用。
各位开发者在考虑将 NEAR 作为平台时：Wasm 运行时对 Rust 和 JavaScript 的支持，相较于仅支持 EVM 的环境，降低了学习门槛；而 Aurora 生态系统项目为现有的 Solidity 代码库提供了迁移途径。
NEAR 代币、质押和验证者经济模型
NEAR 代币在协议中具有四项功能：
["交易费用 (Gas): NEAR 支付网络上的计算费用；一部分会被销毁，一部分则分配给验证者。","质押: 验证者和委托人锁定 NEAR 以保障网络安全，并赚取质押奖励。","治理: NEAR 代币持有者参与协议治理决策。","生态系统资助: NEAR 基金会分发 NEAR 代币作为资助，以促进生态系统发展。"]
NEAR 代币持有者可以通过直接运行验证者节点，或通过 NEAR 钱包将质押委托给现有验证者来参与网络安全。委托无需运行任何基础设施；持有者只需选择一名验证者并委托其质押即可。有关质押的详细说明，请参阅 docs.near.org/validator/staking-overview.
无状态验证对质押动态的影响是结构性的：通过降低区块分片验证者的硬件要求，该升级旨在随着时间的推移，扩大具有经济可行性的验证者运营商池。更大规模的验证者池意味着质押更加分散，这对网络的去中心化具有积极意义。质押收益会根据网络总参与度和活跃验证者的数量而有所不同；随着验证者池的扩大，这些动态可能会发生变化。
本文仅供参考和教育目的。本文中的任何内容均不构成财务、投资或法律建议。加密货币和区块链资产带有重大风险。在做出投资决策前，请务必自行进行研究。
无状态验证对验证者的意义
在无状态验证下，区块分片验证者的运行模式在五个具体方面发生了变化：
- 无需分片状态存储： 块验证者不再维护其分配的分片状态的本地副本。
- 状态见证取代状态同步： 块验证者随同每个块接收一个状态见证，其中包含验证所需的所有状态数据。
- 无缝分片轮换： 当在纪元边界被分配到一个新分片时，验证者将立即开始接收该分片的状态见证，无需下载状态。
- 降低存储硬件要求： 之前代表块验证角色最大硬件成本的存储义务已被移除。
- 块生产者保留完整状态： 块生产者角色仍需要维护完整的分片状态和更高的硬件配置，而这一区别对于基础设施规划很重要。
Chunk 验证者是否仍需存储分片状态？ 不需要。Chunk 验证者不再需要存储本地分片状态。每当他们验证 Chunk 时，都会从 Chunk 生产者处接收到状态见证 (state witness)。Chunk 生产者（负责构建 Chunk 并生成状态见证的节点）仍需维护完整的分片状态，并保留较高的存储要求。
在无状态验证下，块验证者不需要为分片状态准备大容量 SSD 存储。先前的模型将此存储视为验证角色的主要硬件成本；该要求现已取消。块生产者维护完整的分片状态，并需要与其分片状态大小成比例的存储硬件；计划运行块生产者的操作员应将此考虑在内。两种角色的官方硬件规格发布于 docs.near.org/concepts/basics/validators.
分片分配大约以12小时为一个纪元周期。在每个纪元边界，NEAR 的验证者选择机制会将区块验证者重新分配到不同分片。在无状态验证下，这种重新分配是无缝的：新被分配的验证者会从区块生产者那里接收其新分片区块的状态见证，并立即开始验证。之前的模型需要数小时的状态同步；这一成本已对区块验证者消除。纪元机制和奖励分配详情记录在 docs.near.org/concepts/basics/epoch.)
这对验证者的意义： 如果您运营 Chunk 验证者节点，您的存储分配模型已发生变化。您不再需要为 Chunk 验证者硬件分配大容量 SSD 以存储分片状态。在 Epoch 边界的分片轮换，其运维影响现在已微乎其微。如果您正在运营或考虑担任 Chunk 生成者角色，有状态的要求依然存在：在该层级仍需提供完整的分片状态存储。
常见问题解答
NEAR Protocol 是什么？
NEAR Protocol 是一种第 1 层权益证明区块链，它利用 Nightshade 分片技术在并行分片中处理交易。它已部署无状态验证（Stateless Validation）作为其第 2 阶段升级，允许区块分片验证者在不本地存储分片状态的情况下验证交易。NEAR Protocol 使用 NEAR 代币来支付交易手续费、进行质押和参与治理。如需全面了解，请参阅：什么是 NEAR Protocol？
谁创建了 NEAR Protocol？
NEAR 协议由 Illia Polosukhin 和 Alex Skidanov 联合创立。Polosukhin 是 2017 年《Attention Is All You Need》论文的共同作者，该论文引入了现代大语言模型基础的 Transformer 架构；Skidanov 曾任微软软件工程师，也是 Nightshade 分片设计的共同架构师。两位创始人带来的独特技术背景，塑造了 NEAR 以研究为先的架构。如需全面了解，请参阅：什么是 NEAR 协议？
什么是区块链中的无状态验证？
无状态验证是一种区块链架构模型，验证者无需维护本地网络状态副本即可验证交易。验证者不存储状态，而是接收状态见证，这是一种加密证明，仅包含验证特定区块或区块碎片所需的状态数据。NEAR 已通过 Nightshade Phase 2 部署了无状态验证；这是首个在生产环境中实施此模型的主要 Layer-1。如需全面了解，请参阅：NEAR 无状态验证是什么？。### NEAR 的分片工作原理？
NEAR 的 Nightshade 分片技术将区块链拆分为称为“分片”的并行处理通道。每个分片同时处理一部分交易，并生成称为“Chunk”的分片级区块段。验证者在每个 Epoch 会被分配到特定的分片，而区块生产者则将来自所有分片的所有 Chunk 聚合为一个最终区块。如需全面了解，请参阅：NEAR 的运作原理：Nightshade 分片详解
什么是 NEAR 中的状态见证人 (State Witness)？
NEAR 中的状态见证者（State Witness）是由 Chunk 生产者生成的紧凑加密证明，包含 Chunk 验证者验证特定 Chunk 所需的所有分片状态数据。它包括该 Chunk 交易所涉及的状态 Trie 条目，以及这些条目包含在分片状态 Trie 中的 Merkle 证明。状态见证者是基于 Merkle 证明的鉴证；它们并非零知识证明。如需了解详尽内容，请参阅：什么是状态见证者？
NEAR 中的 Chunk 验证者是什么？
NEAR 中的分片验证者 (Chunk validators) 是负责验证单个分片数据块 (shard chunks) 的节点，即每个区块中属于分片层级的部分。在无状态验证 (stateless validation) 机制下，它们不存储本地分片状态；它们从分片生产者 (chunk producer) 处接收状态证人 (state witness)，并验证分片内的交易是否正确应用于所见证的状态。分片验证者不同于分片生产者（负责构建分片并维护状态）以及区块生产者 (block producers)（负责组装最终区块）。欲了解全面信息，请参阅：分片验证者对比分片生产者
NEAR 是否使用权益质押证明 (Proof of Stake)？
NEAR 使用阈值权益证明（Thresholded Proof of Stake），这是一种验证者根据最低质押阈值进行选择的变体，而非根据质押规模进行严格的前N排名。NEAR 每个时期大约有 100 名活跃验证者。NEAR 代币持有者无需运行自己的基础设施，即可将质押委托给验证者。如需完整了解，请参阅：什么是 NEAR 协议？
无状态验证如何改善去中心化？
无状态验证通过移除切片验证者对分片状态存储的要求来提高去中心化程度。更低的硬件要求降低了运行验证者节点的经济门槛。随着越来越多的参与者能够负担得起运行验证者，验证者集合将扩大，将网络安全分布到更大且地理位置更多样化的运营商集合上。欲了解详情，请参阅：无状态验证的重要性
什么是动态分片？
动态分片（Dynamic resharding）是 NEAR 计划中的第三阶段升级，旨在允许网络根据实时交易需求自动拆分或合并分片，从而在无需验证者停机或手动重新配置的情况下，灵活调整吞吐量。该功能尚未正式上线。无状态验证（Stateless validation）是实现动态分片的技术前提，因为无状态验证者可以被即时分配到新分片或重新配置的分片中，而无需进行状态同步操作。如需了解完整详情，请参阅：动态分片：无状态验证之后是什么
无状态验证后，NEAR 验证者的硬件要求是什么？
在无状态验证下，Chunk 验证者不再需要为分片状态配置高容量 SSD 存储；Chunk 验证角色的主要硬件成本已不复存在。Chunk 生产者仍然需要完整的全分片状态存储，并有更高的硬件要求。两种角色的具体硬件规格已发布在 NEAR 验证者文档.) 中。有关操作背景，请参阅：无状态验证对验证者的意义
结论
NEAR 协议的无状态验证 (stateless validation) 升级将分片块验证与状态存储分离，降低了分片块验证者的硬件门槛，并为第三阶段动态再分片奠定了技术基础。分片块验证者现在为每个分片块接收一个状态证明 (state witness)，而无需维护本地分片状态数据库。在 Epoch 边界的分片轮换变得顺畅无阻。验证者池的设计旨在随着分片块验证硬件门槛的降低而不断扩大。
Nightshade 路线图将其定位为一个顺序构建的过程：第一阶段（Phase 1）建立了跨分片拥塞控制，第二阶段（Phase 2）实现了无状态验证，而第三阶段（Phase 3）的目标是在无状态验证者模型使即时分片重新分配在操作上变得可行后，增加动态重分片功能。
开发者和验证者的下一步：
- NEAR 开发者文档 用于完整的协议规范、SDK 指南和验证器设置
- NEAR Rust SDK) 用于使用 Rust 构建智能合约
- NEAR JavaScript SDK) 用于使用 JavaScript 构建智能合约
- NEAR 验证器质押概述) 用于质押设置和委托
- NEAR 基金会补助金 用于生态系统项目资助