Skip to main content

什么是验证者

注意：本文档是英文原版的自动翻译。

什么是验证者

**验证者（validator）**是验证交易、提议新区块并帮助维护区块链完整性的网络参与者。在权益证明（PoS）及相关共识机制中，验证者锁定（质押）代币作为抵押品以参与区块生产和验证。如果一个验证者诚实行事，它会赚取奖励；如果它恶意行事或未能履行职责，其质押可能通过 slashing 被削减。

**简而言之：**验证者是一个质押代币以参与保护区块链的节点运营者，通过验证交易和产出区块来实现。诚实的验证者赚取奖励；不诚实或疏忽的验证者损失质押。

验证者如何运作

验证者在一个共识机制的语境中运作——这是区块链参与者借以就哪些交易有效以及它们以何种顺序被添加到链上达成一致的协议。在权益证明系统中，过程遵循一个一般模式：

  1. 质押。 验证者在一个质押合约中锁定所需数量的区块链原生代币。这一质押充当抵押品——它展示了验证者对诚实行为的财务承诺。
  2. 区块提议。 共识协议选择一个验证者来提议下一个区块。选择方法各异：它可能是随机的、按质押规模加权的，或基于轮询计划。被选中的验证者将待处理交易组装成一个区块。
  3. 证明 / 投票。 其他验证者验证被提议的区块——检查交易是否有效、区块是否遵循协议规则，以及它是否正确地连接到前一个区块。它们通过签署（证明）该区块来表示同意。
  4. 最终确定。 一旦足够多的验证者证明了该区块（通常是绝对多数，例如验证者集合的三分之二），该区块即被视为最终确定并被永久添加到链上。
  5. 奖励。 提议区块并正确证明的验证者获得奖励，通常以链的原生代币计价。奖励补偿验证者运行硬件的运营成本和锁定资本的机会成本。

验证者的职责

验证者的职责不止于偶尔提议区块：

  • 持续可用。 验证者必须 24/7 运行其节点软件。错过证明职责或在被选中提议区块时离线会导致错失奖励，并在一些协议中招致轻微惩罚。
  • 正确行为。 验证者必须遵循协议规则。签署两个相互冲突的区块（双重签名）、为无效交易做证明，或试图重组链，都是触发 slashing 的违规行为。
  • 软件维护。 验证者必须使其节点软件保持最新、应用安全补丁并参与网络升级。
  • 基础设施管理。 运行一个验证者需要可靠的硬件、网络连接和运营监控。

Proof of Stake 与验证者经济学

在权益证明（PoS）系统中，验证者取代了工作量证明（PoW）系统中的矿工。验证者不是竞相解决计算难题（这消耗能源），而是根据它们所承诺的质押金额被选中来产出区块。

委托与提名变体

许多 PoS 系统允许不想自己运行验证者节点的代币持有者将其代币委托给一个现有的验证者。验证者运营节点；委托者贡献质押。奖励在验证者（收取一笔佣金）和委托者之间分享。

涉及验证者的常见 PoS 变体：

变体 验证者如何被选择 示例
纯 PoS 按质押加权；任何符合条件的质押者都可以验证 Ethereum（合并后）
委托 PoS（DPoS） 代币持有者为一组有限的验证者投票 EOS、Tron
Proof of Staked Authority (PoSA) 验证者被质押并被授权；将 PoS 与权威选择结合 BNB Chain
提名 PoS（NPoS） 提名者用其质押支持验证者；算法选择 Polkadot、Kusama

验证者集合的规模差异巨大：从几十个（在 DPoS 或 PoSA 系统中）到数千个（在 Ethereum 的 PoS 中）。

Slashing 与问责

Slashing 是验证者因协议违规而损失其部分或全部质押代币作为惩罚的机制。slashing 通过经济惩罚而非通过权威或声誉来强制诚实行为。

常见的可被 slash 的违规行为包括：

  • 双重签名。 在同一高度提议或证明两个相互冲突的区块。这是最严重的违规，因为它威胁链的一致性。
  • 环绕投票。 以与之前证明相矛盾的方式做证明，制造对链历史的冲突看法。
  • 长时间停机。 在一些协议中，长时间不可用导致质押逐步削减（有时称为"非活跃泄漏"而非 slashing）。

slashing 的严重程度因协议和违规而异。轻微违规可能导致小额惩罚；双重签名通常导致质押的相当一部分被销毁。

加密 AI 中的验证者

在加密 AI 语境中，验证者以两种不同的角色出现：

区块链验证者

标准的区块链验证者保护一个加密 AI 项目所构建于其上的底层链。每个基于 PoS 的加密 AI 项目都依赖验证者来处理其交易、执行其智能合约并最终确定其状态变更。验证者基础设施是项目信任基础的一部分。

AI 专属验证者

一些加密 AI 项目在其自身网络中引入专门的验证者角色。这些验证者不仅仅验证区块链交易——它们验证 AI 相关的工作：

  • 推理验证者。 通过检查证明（ZK 证明、TEE 认证）或比较来自多个提供者的结果，来验证 AI 推理是否被正确执行。
  • 计算验证者。 验证 GPU 提供者是否如声称那样完成了计算任务，通常通过重新执行计算的一个子集或检查工作量的密码学证明。
  • 数据验证者。 验证提交给 AI 数据市场或训练流程的数据的质量、真实性或完整性。
  • 预言机验证者。 验证 AI 模型消费的外部数据馈送，确保数据在进入 AI 流程之前未被篡改。

这些 AI 专属的验证者角色往往带有它们自己的质押和 slashing 机制，与基础层区块链共识分开。

验证者 vs 节点

一个常见的混淆是验证者与节点之间的混淆。所有验证者都运行节点，但并非所有节点都是验证者：

角色 它做什么 是否需要质押
全节点 下载并验证整个区块链；强制执行共识规则 否
归档节点 同时存储所有历史状态的全节点 否
轻节点 在不下载完整链的情况下验证区块头 否
验证者节点 额外提议和证明区块的全节点 是（在 PoS 系统中）

运行一个非验证的全节点为网络的去中心化和数据可用性做出贡献，但不赚取区块奖励，也不需要质押。

它在 DecAIHub 项目卡片中出现的位置

与验证者相关的信息在项目卡片中以若干语境出现：

  • 链基础设施。 项目底层区块链的共识机制和验证者模型是运营语境的一部分。
  • AI component。 当一个项目使用专门的验证者进行 AI 相关验证（推理验证、计算验证）时，这会出现在 AI component 字段中。
  • Token model。 质押代币以运行一个验证者是代币效用最常见且最具体的形式之一。它将代币所有权直接与网络安全挂钩。
  • Evidence table。 对于拥有自己验证者网络的项目，Tier-1 物证包括活跃验证者数量、质押参数、slashing 事件和正常运行时间指标。

仅凭验证者无法证明什么

  • 运行验证者并不证明一个项目拥有真实的 AI。验证者保护区块链层；AI 层需要独立的证据。
  • 大量的验证者数量并不证明去中心化。如果少数实体控制大部分验证者（通过委托或多个验证者节点），网络在实践中可能是中心化的。
  • 验证者质押并不证明代币对 AI 组件的必要性。该代币可能对区块链共识是必需的，但对 AI 流程不是。
  • 高质押奖励并不证明可持续性。奖励率取决于代币发行，而代币发行可能随时间稀释代币价值。
  • 将一个角色称为"验证者"并不意味着它在共识意义上进行验证。一些项目将该术语宽泛地用于任何执行检查或验证的节点。

请勿混淆

  • 节点——任何运行区块链软件并维护链副本的参与者。验证者是一种特定类型的节点，具有额外的职责（区块生产、证明）和要求（质押）。
  • 矿工——在工作量证明系统中，矿工解决计算难题来提议区块。验证者在权益证明系统中扮演类似角色，但通过质押而非计算。
  • 委托者——一个将其代币与验证者一起质押但不运行节点基础设施的代币持有者。委托者信任验证者诚实行事并分享奖励。
  • 共识机制——定义验证者如何协调的协议。验证者是共识机制内的参与者，而非机制本身。
  • 预言机（Oracle）——一个向智能合约馈送信息的外部数据提供者。一些项目将验证者和预言机角色结合，但它们是不同的功能。

常见问题

运行一个验证者我需要什么？

要求因区块链而异。常见要求包括：最低质押（可以从适度到大量的原生代币不等）、具有充足 CPU、RAM、存储和带宽的专用服务器硬件（或云实例）、具有高正常运行时间的可靠互联网连接，以及安装、配置和维护节点软件的技术知识。一些链还要求验证者通过治理或申请流程。许多代币持有者选择将其质押委托给现有验证者，而非运行自己的验证者。

如果一个验证者离线会发生什么？

后果取决于协议。在大多数 PoS 系统中，离线的验证者会错失其不可用期间的奖励。一些协议施加额外惩罚：例如 Ethereum 会施加一个渐进的"非活跃泄漏"，在网络参与度低的时期缓慢减少离线验证者的质押。这比 slashing（针对恶意行为）轻，但仍为维持高正常运行时间创造了财务激励。

验证者和委托者有什么区别？

验证者运行实际的节点基础设施——硬件、软件、网络连接——并履行提议和证明区块的职责。委托者向一个验证者的质押贡献代币，而不运行任何基础设施。验证者做工作；委托者提供额外的经济安全。奖励在两者之间分配，验证者通常收取一笔佣金。委托者分担 slashing 风险：如果他们委托的验证者被 slash，委托者会损失其委托质押中成比例的金额。

一个验证者会被不公平地 slash 吗？

slashing 被设计用来惩罚明确定义的协议违规，而非主观判断。例如，双重签名要求验证者产出冲突消息的密码学证据——这是客观可验证的。然而，运营风险确实存在：软件 bug、错误配置的故障转移系统意外运行同一验证者的两个实例，或导致冲突证明的基础设施故障，都可能在没有恶意意图的情况下触发 slashing。验证者通过精心的基础设施设计、监控并避免运行可能双重签名的冗余实例来缓解这些风险。

外部参考

另请参阅

No comments to display

Back to top