NEAR 无状态验证是 NEAR Protocol 的 Nightshade 分片框架的第二阶段升级，在此阶段，区块验证者不再维护分片状态的本地跟单。相反，区块生产者会将所有必需的状态数据打包成状态见证（一种加密数据结构，包含执行特定区块所需的每笔账户余额、合约存储条目和访问密钥），并将其与区块一同发送给验证者。此设计将验证者的硬件要求与网络状态大小分离开来，从而允许 NEAR 通过添加更多分片来实现水平扩展，而无需对其验证者集合施加成比例的存储成本增长。

这篇文章涵盖了什么是 NEAR Protocol、Nightshade 分片的工作原理、无状态验证的精确机制（包括状态见证者生命周期和验证者角色层级）、去中心化和可扩展性的优势、与以太坊无状态路线图的直接对比，以及对验证者、质押者、开发者和任何评估 NEAR 以进行 dApp 部署的人员的影响。

什么是 NEAR Protocol？

NEAR Protocol 是一种第 1 层权益证明区块链，它利用 Nightshade 分片技术（NEAR 专有的分片框架）将交易处理分散到多个并行分片中，从而在极低的交易费用下实现高吞吐量。NEAR 旨在实现去中心化应用程序的大规模部署，其开发者工具和共识架构均基于分片数量将随时间增长的假设而构建。

NEAR 的核心架构

NEAR 运行为一个权益证明网络，验证者通过质押 NEAR 代币来参与共识，并且会在每个时期（一个固定的时间段，大约相当于半天）被随机分配到分片。NEAR Protocol 由 Illia Polosukhin（机器学习里程碑论文《Attention Is All You Need》的合著者）和 Alexander Skidanov 共同创立；NEAR 基金会负责监督协议的持续开发和生态系统资助。

NEAR 代币主要有两个功能：支付交易和合约执行的 Gas 费用，以及作为验证者的抵押品进行质押，以获得参与共识的权利。NEAR 智能合约编译为 WebAssembly (WASM)，这是一种可移植的二进制格式，允许用 Rust 或 JavaScript 编写的合约在确定性运行时中执行。NEAR 上的交易处理遵循分块模型，其中每个分片在每个区块间隔内生成一个分片（并行处理的分片级别区块），然后所有分片被聚合到单一的规范区块中。

NEAR 与其他 L1 区块链有何不同？

NEAR 之所以能在众多 Layer-1 区块链中脱颖而出，主要通过其执行分片模型，该模型将状态（state）和交易处理（transaction processing）分散到各个分片（shards）中，而非将所有执行都集中在单一链上。主要区别包括：

• Nightshade 执行分片： NEAR 对状态和计算都进行分片，而不只是数据可用性。这与以太坊的 Danksharding 方案 (EIP-4844) 不同，后者针对的是 Layer 2 Rollup 的数据可用性分片，而非执行分片。
• 无状态验证（第 2 阶段）： 区块验证者在没有本地状态存储的情况下运行，这一设计选择直接影响了去中心化和分片的可扩展性，本文将深入探讨。
• WASM 智能合约运行环境： 合约在 WASM 沙箱中运行，支持 Rust 和 JavaScript 作为主要开发语言。
• 易读的账户名称： NEAR 账户使用命名标识符，而不是原始的公钥哈希。
• 存储质押模型： 合约通过质押 NEAR 代币来支付链上存储费用，将存储成本与质押的抵押品挂钩，而非按字节收费。
• 近乎零的交易手续费： NEAR 的费用结构旨在确保即使在网络负荷适中的情况下也能保持低廉。

Solana 通过其 Sealevel 运行时利用单链并行机制实现扩容；NEAR 则通过跨独立并行分片的分片技术进行扩容。这些是针对同一吞吐量问题的不同架构方案。关于以太坊的对比，本文稍后将进行专门的探讨。

什么是无状态验证？

无状态验证是一种区块链验证模型，在该模型中，验证者处理交易时无需维护网络状态的持久性本地副本，而是接收作为其验证的每个区块或分片的一部分的所需所有状态数据。“无状态”一词指的是验证者与状态存储的关系，而不是区块链状态本身，后者会继续存在并增长。从验证者的角度来看，每项验证任务都在送达时预先打包好了完成任务所需的一切。

有状态验证 vs. 无状态验证：关键区别

有状态验证与无状态验证的区别在于，在执行过程中，状态数据是与验证器相关联，还是与待处理的工作项相关联。

在有状态验证中，验证者是状态的保管者：它拥有相关分片数据的副本，并在每次交易中对其进行查询。在无状态验证中，状态数据随工作一同传输。验证者接收其所需的一切，使用它，然后丢弃它。

NEAR 为何需要无状态验证

在 NEAR 原有的有状态架构下，分配给分片的每个区块验证者都必须维护该分片状态的完整本地跟单，且随着 NEAR 分片数量的增加，网络中每个验证者的存储硬件需求也随之增长。每个新增的分片都为其对应的验证者增加了成比例的存储义务。这导致 NEAR 的扩容目标与验证者参与的硬件成本门槛之间形成了直接耦合。随着网络通过增加分片来提升吞吐量，它同时也抬高了成为验证者的成本，使参与权集中在拥有大型存储基础设施的运营商手中。

无状态验证打破了这种耦合。区块片段验证者不再存储任何分片状态。它仅接收验证其所负责的每个区块片段所需的状态数据，针对该数据执行交易，并随后将其丢弃。增加更多分片可以提高网络吞吐量，而不会增加每个验证者的存储需求。这解决了区块链可扩展性三难困境中的一个核心矛盾：NEAR 可以通过增加分片来扩展吞吐量，而无需迫使硬件中心化，同时状态见证的密码学完整性保障了安全性。

深入了解分片：NEAR 可扩展性的基石

NEAR 的无状态验证在 Nightshade 分片架构中运行，该架构将网络的全局状态和交易处理分配到多个并行分片中。理解这一架构是后续机制解释的前提，因为无状态验证是针对验证者参与 Nightshade 结构方式的一次特定升级。

Nightshade 分片在 NEAR 上是如何运作的

Nightshade 是 NEAR Protocol 的分片框架，在该框架中，区块链的全局状态被划分到多个分片中，每个分片在每个区块间隔内生成一个分片（一个分片级区块）。多个分片会跨所有活动分片并行生成，并由该间隔的区块生产者聚合为一个单一的规范区块。

Nightshade 的核心设计原则是，所有分片都被视为一个逻辑区块链的组成部分，而不是独立的链。每个 NEAR 区块包含每个活跃分片的一个分块。这意味着，即使交易处理是分布式进行的，全局账本也保持统一。跨分片交易通过一个异步收据机制来处理，该机制用于在分片之间传递消息。

验证者在每个纪元会被随机分配到分片，这降低了任何单一分片的验证者集合被选择性攻击或控制的风险。验证者并不永久拥有分片分配；它会随着每个纪元进行轮换，从而在整个网络中分散责任和风险。

Nightshade 的完整实施分三个阶段进行。阶段 1 确立了带有区块片段 (chunk) 处理的基础分片，在此阶段验证者保留了完整的本地状态副本。阶段 2 是无状态验证，也是本文的主题。阶段 3 是动态重新分片，它使 NEAR 能够根据实时网络需求自动调整其分片数量。有关 NEAR 分片模型的完整技术文档，请参阅 docs.near.org/concepts/advanced/sharding.

NEAR 无状态验证的工作原理

NEAR 无状态验证之所以能正常工作，是因为验证一个分片所需的状态数据会随分片本身一起传输，由分片生产者打包成状态见证。分片验证者将分片及其状态见证一起接收，仅使用见证数据执行所有交易，并且从不查询本地状态数据库。其结果是，NEAR 网络中数量最多的验证者群体能够以接近零的状态存储要求来运行。

什么是状态见证？

状态见证是由分块生产者生成的一种加密数据结构，其中包含执行特定分块中交易所需的所有状态数据，包括受影响的账户余额、合约存储条目、访问密钥以及合约代码。

你可以将‘状态见证者’（state witness）类比为法庭书记员在聆讯前准备的案件卷宗：它包含了法官作出裁决所需的所有文件，并且是提前整理好的，以便法官在审理过程中无需搜索法庭存档。在NEAR的架构中，状态见证者就如同这个案件卷宗。区块验证者（chunk validator）收到状态见证者和区块（chunk）后，将仅使用状态见证者中的内容来执行所有交易，而无需查询本地状态存储。

状态见证人的生命周期涵盖五个不同的阶段：

1. 内容： 状态见证包含交易批次中涉及的每个账户的账户余额、合约存储条目、访问密钥以及合约代码。仅包含执行期间实际读取或写入的状态；不打包整个分片状态。

2. **生成：**区块生产者，即负责构建区块的验证者角色，从其本地分片状态跟单中读取相关的状态条目，并将它们打包成状态见证。区块生产者保留其本地状态，因为它必须能够为未来的区块生成见证。

3. 传输：块生产者将该块及其状态见证一同广播给当前区块间隔内随机分配到该分片的块验证者。

4. 执行： 各个分块验证者仅使用状态见证数据来执行分块交易。在任何环节都不会进行本地状态查询。执行完成后，分块验证者将生成一份证明，以确认该分块的有效性。

5. 丢弃： 验证完成后，区块分片验证者（chunk validator）将丢弃状态见证人（state witness）。该见证人不会被保留、存储，也不会用于更新任何本地状态数据库。

状态见证结构在 NEAR 增强提案 (NEP) 中有正式的规范。有关精确的规范和当前的 NEP 编号，请参阅 GitHub 上的 NEAR NEPs 存储库.)。有关核心协议客户端的实现细节，请参阅 GitHub 上的 nearcore 存储库.)

分块验证者与块生产者的作用

NEAR 在无状态验证下的验证器架构涉及三种不同的角色：区块生产者、区块验证者和块生产者，每种角色都有不同的职责和不同的状态存储需求。

关键的结构性见解是，区块验证者是网络中最庞大的群体，并且在无状态验证下，它们不再需要昂贵的存储硬件。只有区块生产者，一个数量少得多的群体，仍需存储状态，因为它们必须读取本地状态来为每个区块生成见证。这种不对称性使得验证者群体能够增长，而无需按比例增加整个网络的总存储成本。

无状态验证下的验证流程

以下步骤描述了从新区块间隔开始，到已验证区块在 NEAR 上最终确定的过程。

1. 分片区块生产： 分配给每个活跃分片的区块生产者（chunk producer）会构建一个分片区块（chunk），即一个分片级别的区块，其中包含将在本区块区间内处理的待处理交易。

2. 状态见证生成： 分片区块生产者（Chunk Producer）从其本地分片状态跟单中读取相关的状态条目，并将其打包成状态见证（State Witness）。该见证包含了该分片区块中交易所触及的每一个账户余额、合约存储条目和访问密钥。

3. 发送至分片验证者： 分片生产者将该分片及其状态见证广播给在此区块区间内被随机分配到该分片的分片验证者。

4. 无状态执行： 每个分片验证器仅使用状态见证数据来执行分片的交易，且在任何时候都不进行本地状态查找。执行后，分片验证器将证明分片的有效性并丢弃状态见证。

5. 区块组装： 本轮的区块生产者收集所有活跃分片已证明的区块片段，将它们聚合成为一个单一的规范区块，并将其广播到网络以供最终确定。

在步骤 3 和 4 的任何阶段，分片验证者都不需要本地状态存储。状态见证提供了验证操作期间所需的所有状态访问。

NEAR 无状态验证的优势

无状态验证为 NEAR 网络带来了三类改进：它降低了数量最多的验证者类别的硬件要求；它消除了有状态验证对分片数量和吞吐量造成的扩展上限；同时，它还改善了在网络上构建去中心化应用程序的开发人员的基础设施条件。

更低的硬件要求和更高程度的去中心化

NEAR 的无状态验证对其验证者集合最直接的后果是，消除了分片状态存储作为块验证者的硬件要求。在有状态验证下，块验证者的存储需求会随着分片状态规模的增长而不断增加，随着网络处理更多交易和积累更多状态，其存储规模从数百 GB 扩展到 TB 级别。这造成了累积性的硬件成本门槛。

无状态验证完全消除了分块验证者的这一负担。该角色的状态相关基础设施存储要求降至几乎为零，仅剩下在区块时间限制内执行交易和传输见证所需的计算和网络带宽要求。

去中心化效应直接源于这一硬件变更。更低的存储成本降低了运行区块验证器的总运营成本，从而降低了实际的经济参与门槛。这使得验证器集合更大且地理上更多样化，进而减少了验证器集中的风险。一个其大多数验证器可在通用硬件上运行的网络，在结构上比那些验证器资格要求在存储基础设施方面有重大资本支出的网络更能抵抗中心化。在无状态验证下，目前区块验证器的硬件要求规范维护在 docs.near.org/validator; 请查阅该文档了解最新数据。

可扩展性而不牺牲安全性

无状态验证将 NEAR 的分片数量与其验证者硬件要求解耦，从而消除了有状态验证曾施加在网络吞吐量上的扩展上限。在之前有状态模型下，将分片数量翻倍会要求分配到新分片的每个验证者提供同等比例的额外存储，从而导致大量分片在经济上成本高昂。无状态验证打破了这种关系：增加分片会提高网络容量，而无需增加每个验证者的存储义务。

NEAR 的网络吞吐量与分片数量大致成正比。更多活跃分片意味着每个区块间隔内可以并行处理更多的 Chunk，从而增加了网络每秒可确认的交易数量。无状态验证是 NEAR 实现大规模更高分片数量的前提条件。NEAR 基金会的文档提供了随更新而变化的最新吞吐量数据；欲了解与特定分片配置相关的当前 TPS 数据，请参阅 docs.near.org。

这直接解决了区块链可扩展性不可能三角中的可扩展性问题。分片网络中可扩展性与去中心化之间的历史性矛盾，源于增加容量通常会提高验证节点的硬件成本，进而削弱去中心化程度。无状态验证消除了导致这种权衡的机制，使 NEAR 能够在不产生相应集权压力的情况下追求分片数量的增加。该可扩展性模型在第三阶段（动态重分片）达到了最终形态，届时 NEAR 将具备根据实时网络需求自动调整分片数量的能力，且无需任何人工协调。

这对在 NEAR 上构建的开发者意味着什么

如果您正在评估NEAR作为部署平台，无状态验证会影响您在基础设施层面的应用程序，而不是在合约层面。在您做出架构决策之前，有四项实际影响值得了解：

无需更改合约。 无状态验证是一项协议层面的变更。您的智能合约无需任何修改即可从中受益。已部署在 NEAR 上的合约将自动在升级后、更具扩展性的网络上运行。无需迁移步骤，无需重新部署，也没有 API 变更。

随着分片数量的增长，吞吐量更高。随着 NEAR 通过无状态验证（stateless validation）增加更多分片，网络的总交易处理能力会随之提升。对您的 dApp 而言，这意味着在高需求时期，网络拥堵的概率会降低，并且随着网络扩展，交易成本将更加稳定且可预测。

更具韧性的基础设施。通过降低硬件门槛以鼓励更多验证者参与，一个更加去中心化的验证者集合，能够降低与中心化相关的网络中断风险。生产中的 dApp（去中心化应用程序）将受益于一个验证者网络，该网络不易因运营商集中或少数资源充足的验证者出现硬件故障而中断。

以太坊开发者路径。NEAR 支持 Aurora，一个 EVM 兼容的执行环境，允许以太坊开发者在 NEAR 上部署 Solidity 合约，而无需将其重写为 Rust 或 JavaScript。这些合约运行在相同的底层网络上，并受益于相同的无状态验证基础设施的改进。

NEAR 无状态验证 对比 以太坊的无状态路线图

熟悉以太坊无状态客户端路线图的开发者会发现 NEAR 的无状态验证解决了同样的根本性问题：将验证者和节点硬件与网络状态大小解耦。这两种方法在不同的架构层面和通过不同的机制运行，这受到两个网络根本不同结构的影响。它们不是竞争性设计，而是对区块链状态增长带来的硬件负担的并行响应。

这两种方法都将验证者或客户端所需的状态数据与待验证的区块或分片一起打包，因此执行方永远不需要本地状态数据库。结构上的区别在于，NEAR 的无状态验证应用于分片系统中，针对的是构成其网络大部分的分片级别验证者。以太坊的无状态路线图则针对的是单体执行层上的全节点，在那里，整个链的状态最终必须通过 Verkle 树见证（witnesses）而非本地状态尝试（trie）来寻址。

在分片维度上，NEAR 的 Nightshade 框架是一种执行分片设计，将状态和计算分散到各个分片中。以太坊的 Danksharding 提案针对 Layer 2 Rollup 数据可用性分片，并非执行分片设计。这些在架构上是不同的目标，服务于不同的网络结构，直接比较 Nightshade 和 Danksharding 需要承认它们解决的是不同的问题。

无状态验证在 NEAR 的路线图中扮演什么角色？

Nightshade 的第二阶段即为无状态验证。这一点等同之处值得明确说明，因为 NEAR 的文档和社区讨论有时会将“第二阶段”与“无状态验证”混用，而了解当前所处的阶段则能说明网络扩容架构的状态。

Nightshade 的三个阶段详解

Nightshade 的完整实现分三个独立阶段进行，每个阶段都在前一个阶段的基础上推进，并为下一个阶段创造先决条件。

第一阶段：基础分片（已完成）

NEAR将其网络状态划分为多个分片，每个分片并行处理交易。验证者维护其分配的分片状态的完整本地副本。块生产者将来自所有分片的数据块（chunks）聚合到单个规范块中。第一阶段确立了Nightshade基于数据块的架构，但将硬件要求与分片状态大小直接挂钩，从而造成了第二阶段旨在解决的扩展瓶颈。

第二阶段：无状态验证 (当前阶段)

区块分片验证者（Chunk validators）不再维护本地分片状态。区块分片生产者（Chunk producers）负责生成状态见证（state witnesses）并将其与分片一起交付。这使验证者的硬件要求与分片状态大小脱钩，并使网络能够在不按比例增加验证者硬件成本的情况下扩展至更多分片。截至本文撰写时，第二阶段已在 NEAR 主网激活；欲了解准确的激活日期和当前网络状态，请参阅 NEAR 基金会博客) 和 docs.near.org，因为协议阶段是逐步激活的，文档也会相应更新。

第三阶段：动态分片 (计划中)

NEAR 将能够根据实时网络需求自动增加或减少其分片数量，而无需手动协调或验证者硬件升级。无状态验证是动态重分片的直接前提条件：若未启用第二阶段，增加分片将导致验证者的存储成本按比例增加，使自动分片调整在经济上变得不切实际。第三阶段是使 NEAR 在理论上实现无限水平扩展的架构步骤。

这三个阶段共同代表了 NEAR 从一个具有固定分片分配和有状态验证者的分片区块链，演进为一个动态可扩展网络，该网络可以在不要求其验证者集硬件成本成比例增加的情况下，调整自身的处理能力。

NEAR 无状态验证：对验证者和质押者的影响

对于区块验证者而言，无状态验证移除了 NEAR 先前架构中最大的单一硬件成本驱动因素：即维护分片状态本地完整副本的要求。这直接影响了验证者操作的经济性以及验证者参与的实际可及性。

此前，分块验证者所需的存储容量与其分配的分片状态大小成正比。随着网络累积更多账户、合约数据和交易历史，这一需求也随之增长。分块验证者的运营成本不仅包括计算和带宽，还涉及随网络增长而扩展的持续性存储基础设施。

运行无状态验证的块验证者不再为状态存储预留资源。其硬件需求转向计算能力，用于交易执行，以及网络带宽，用于在区块时间内接收状态见证人和传输证明。这是一个根本上不同的成本模型：稳定而非增长，并且在任何给定分片数量下都比之前的模型成本更低。

无状态验证改变了区块验证者的硬件要求，但并未改变基础的质押合约机制。验证者仍然质押 NEAR 代币达到座位门槛以上以参与共识，并且他们仍然会因验证者不当行为而被罚没。对于区块验证者而言，满足该参与要求的硬件成本降低了，这在方向上扩大了能够以经济上可行的运营成本运行区块验证者节点的参与者池子。有关当前的硬件规格和质押座位门槛，请参阅 docs.near.org/validator.

请注意，块生产者仍需要完整的本地分片状态来生成状态见证。硬件要求的降低适用于块验证者，这是网络中数量最多的角色。尽管块生产者在验证者总数中所占比例较小，但他们仍保留了原有的状态存储需求。

要成为 NEAR 的验证者，参与者需质押超过当前席位门槛的 NEAR 代币并运行验证者软件。有关完整的设置说明以及反映无状态验证要求的最新硬件规格，请直接参阅 docs.near.org/validator)。

常见问题解答

NEAR Protocol 用于什么？

NEAR Protocol 是一个第 1 层区块链，旨在部署去中心化应用程序，包括 DeFi 协议、NFT 平台、游戏应用程序和开发者工具。它利用 Nightshade 分片技术在多个并行分片上处理交易，从而以接近零的交易费用实现高吞吐量。NEAR 代币用于支付交易和合约执行的 Gas 费用，验证者则质押 NEAR 代币作为抵押品以参与共识。

NEAR Protocol 是如何运作的？

从核心来看，NEAR 作为一个权益质押区块链运作，被划分为多个分片，每个分片并行处理交易。每个分片在每个区块间隔产生一个 chunk（分片级区块）；区块生产者将这些 chunk 聚合成一个单一的规范区块。验证者在每个纪元（epoch）被随机分配到分片，负责执行并证明其所属分片 chunk 中的交易，无状态验证使 chunk 验证者无需维护本地分片状态即可履行这一职责。

什么是 Nightshade 分片？

Nightshade 是 NEAR Protocol 的分片框架，网络全局状态和交易处理被分散到多个并行分片中。与将每个分片视为独立区块链的设计不同，Nightshade 将所有分片视为一个逻辑区块链的组成部分，每个区块包含每个活跃分片的一个数据块。Nightshade 分三个阶段实现：基础分片（第一阶段）、无状态验证（第二阶段）和动态重分片（第三阶段）。

什么是区块链中的状态见证？

状态见证（State Witness）是一种加密数据结构，包含验证特定区块或分片（Chunk）所需的所有状态数据，它被打包并发送给验证者，以便他们在执行期间无需访问本地状态数据库。在 NEAR 协议中，分片的状态见证包括受该分片中交易影响的账户余额、合约存储项以及访问密钥。分片生产者（Chunk Producer）生成状态见证并将其随分片一同传输给分片验证者（Chunk Validator），验证者利用见证数据执行交易，并在生成其证明（Attestation）后将其丢弃。

NEAR 验证者是如何工作的？

NEAR 验证者在无状态验证下扮演三种截然不同的角色：分片生产者、分片验证者和区块生产者。分片生产者构建分片（分片级区块），并通过读取其本地分片状态副本中的相关状态来生成状态见证。分片验证者接收分片和状态见证，仅使用见证数据执行交易，无需本地状态存储，并对分片的有效性进行确认，然后丢弃见证。区块生产者将来自所有活跃分片中已确认分片聚合到一个单一的规范区块中。验证者需要质押符合门槛的 NEAR 代币才能参与共识，并会在每个 epoch 被随机分配到不同的分片。### 无状态验证如何提高可扩展性？

无状态验证通过将分片数量与验证者硬件要求解耦来提高可扩展性。在有状态验证下，增加更多分片要求分配到每个新分片的验证者保持与其成比例的本地存储，这造成了网络实际能够支持的分片数量的硬件上限。借助无状态验证，分片验证者接收每个分片所需的全部状态数据作为状态见证，并在使用后丢弃，因此增加分片不会增加每个验证者的存储要求，从而使 NEAR 能够通过增加分片数量来水平扩展，以并行处理更多交易。

NEAR 对开发者来说是一个好的区块链吗？

NEAR Protocol 为开发者提供基于 WASM 的智能合约，可用 Rust 或 JavaScript 编写；其存储质押模型将合约存储成本与质押的 NEAR 代币挂钩；Aurora EVM 兼容性则方便以太坊开发者部署 Solidity 合约，并支持易于人类阅读的账户名。无状态验证（Stateless validation）是一项协议级的底层架构改进，可自动惠及所有已部署的合约，无需进行任何代码更改。随着分片数量的增加，网络吞吐能力也会随之增长，合约将从拥堵缓解中获益。正在评估 NEAR 以部署生产级 dApp 的开发者，应参阅 docs.near.org 以获取最新的 SDK 规范和工具文档。

NEAR 无状态验证上线了吗？

Nightshade 的第 2 阶段（即无状态验证）已在 NEAR 主网上激活。协议阶段是逐步推出的，NEAR 基金会将在每个阶段达到完全激活时更新相关文档。有关最新的部署状态，包括准确的激活日期和任何阶段特定的说明，请参阅 NEAR 基金会博客) 和官方 NEAR 协议文档。