Solana 验证者要求：质押、硬件与运营成本

验证者与 RPC 节点：不同角色，不同要求

Solana 验证者通过对分叉投票参与共识。它维护身份密钥对、投票账户和质押账户，并且必须持续在线以避免漏投。相比之下，RPC 节点提供读取流量，例如 getAccountInfo 或 getSlot，但不投票。这两种配置经常被混为一谈，但它们的规模配置和运维优先级差异很大。

由于验证者的职责是投票，其性能以投票积分、跳过率和 delinquent 状态来衡量，而不是每秒查询数。一个不提供任何 RPC 流量的验证者，只要在每个 slot 都投票，仍然可以是健康的。反过来，一个吞吐量极佳的 RPC 节点如果缺乏质押或漏投，也可能是个糟糕的验证者。

Solana 验证者要求文档将硬件描述为参与共识的基线，而提供 RPC 服务的节点通常需要额外的内存和存储来应对查询负载。如果你要配置的是 RPC 节点，请参阅 Solana RPC 节点要求。

• 验证者：对分叉投票，需要身份密钥和投票密钥，以投票积分和正常运行时间评判。
• RPC 节点：提供读取流量，不投票，以查询吞吐量和可用性评判。
• 一台机器可以同时运行两种角色，但资源画像和故障模式不同。

身份账户与投票账户设置

验证者需要两个不同的密钥对：一个是在网络上标识节点的身份密钥对，另一个是控制投票和奖励领取的投票账户密钥对。身份密钥对签署共识消息；投票账户保存验证者的投票积分和佣金配置。将两者分开是安全要求，而非便利之举。

创建投票账户需要交易手续费和免租金存款。具体成本取决于当前租金率和账户大小，因此任何数字都应视为快照而非常量。Solana 投票账户文档描述了账户结构和 solana create-vote-account 工作流程。

投票账户还存储佣金百分比，这决定了验证者在将剩余部分分配给委托者之前保留多少质押奖励。佣金是商业决策，但也是竞争信号：委托者在选择质押对象时会比较各验证者的佣金。

• 身份密钥对：标识节点，签署共识消息。
• 投票账户密钥对：控制投票、积分和佣金。
• 投票账户创建：交易手续费加免租金存款，两者都取决于网络。
• 佣金：验证者在质押奖励中的分成，按投票账户设置。

质押：进入活跃集的经济门槛

验证者需要委托质押才能进入活跃集并赚取奖励。没有足够的质押，验证者可能不会被选中投票，其投票积分也无法转化为有意义的奖励。这使得“要求”既是技术性的，也是经济性的：仅靠硬件并不能让验证者盈利。

自质押是一种常见的启动方式。运营者向质押账户注资，将其委托给自己的投票账户，并以此进入活跃集。然而，自质押在长期通常不够，因为奖励份额随总质押量增长，而较大的验证者通过性能和佣金吸引委托者。因此，许多运营者专注于委托，而不是依赖自质押。

进入活跃集的最低质押不是一个固定数字；它取决于网络中的总质押量和活跃验证者数量。你可以使用本文后面描述的 RPC 方法检查当前质押分布，也可以在 Solana 质押账户委托 RPC 读取 中了解更多关于委托机制的内容。

• 活跃集成员资格取决于总委托质押量，而不仅仅是自质押。
• 自质押是启动手段；委托是长期增长路径。
• 佣金和投票表现影响委托者的选择。
• 质押门槛随网络条件和验证者数量而漂移。

硬件配置：CPU、内存、存储和网络

Solana 文档发布了验证者的硬件基线，但这是一个移动目标。随着网络负载上升，基线也随之上升，每个版本都可能修订建议。请将任何硬件表视为起点，在购买前必须对照当前文档重新核对。

CPU 要求由交易摄取、执行和签名验证驱动。单线程性能很重要，因为某些阶段并非完全并行，而核心数对并发执行和网络也很重要。内存必须容纳账户状态和账本工作集；内存不足会导致交换和漏投。

存储应使用高耐久度的 NVMe SSD，因为账本持续写入，磨损是真实成本。网络要求高带宽和低延迟；无法快速接收和传播区块的验证者会漏投。有关节点角色的更广泛比较，请参阅 归档节点与全节点。

• CPU：强大的单线程性能，加上足够的核心用于摄取和执行。
• 内存：根据账户状态和账本工作集配置；避免交换。
• 存储：用于账本的高耐久度 NVMe SSD；规划磨损。
• 网络：高带宽、低延迟、稳定连接。

运维：监控投票积分、跳过率和 delinquent 状态

验证者是一项始终在线的运维承诺。关键健康信号是投票积分、跳过率、delinquent 状态和 slot 滞后。投票积分应稳步增加；停滞表明漏投。跳过率衡量验证者在有资格投票的 slot 上未能投票的频率。delinquent 状态意味着验证者已经落后且没有投票。

监控应自动化，告警应在验证者变为 delinquent 之前触发。漏投的常见原因包括 CPU 饱和、磁盘 I/O 停顿、网络延迟和时钟漂移。故障转移规划很重要：如果主节点故障，具有相同身份和投票密钥的备用节点可以接管，但前提是密钥可用且切换经过协调以避免双重投票。

你可以检查 epoch 和 slot 边界，以了解投票积分何时结算；请参阅 Solana epoch 时间表与 slot 边界。

• 投票积分：每个 epoch 都应增加；停滞表明漏投。
• 跳过率：有资格投票的 slot 中未投票的比例。
• delinquent 标志：验证者落后且未投票。
• slot 滞后：与当前 slot 的距离；滞后上升先于 delinquent。
• 故障转移：具有相同密钥的备用节点，经过协调以避免双重投票。

正确解读官方硬件表

官方硬件表是基线，不是保证。它随网络发展而更新，推荐的 CPU、内存和存储可能在不同版本之间变化。如果你按旧表配置，可能会配置不足并在负载下漏投。

阅读表格时，注意日期及其对应的版本。对照当前的 Solana 验证者要求页面和任何发行说明进行交叉核对。如果你的提供商发布了自己的指南，请将其视为提供商特定内容，并对照官方来源进行验证。

一种实用方法是在 CPU 和存储方面配置高于基线，因为这些最难快速升级。内存和网络有时可以更弹性地扩展，但一个发生交换或丢包的验证者无论质押多少都会漏投。

• 将表格视为移动基线，而非固定规格。
• 每个版本以及重大网络升级前都要重新核对。
• 为 CPU 和存储预留余量；它们最难快速更改。
• 提供商特定指南因提供商而异；对照官方来源验证。

计算真实的成本图景

验证者经济模型由质押而非硬件主导。真实的成本图景包括自质押机会成本、硬件购买或租赁、带宽和运维投入。与此相对，你要比较预期奖励份额，这取决于总质押量、佣金和投票表现。

自质押机会成本是你将资本锁定在质押账户中而非部署到其他地方所放弃的回报。硬件和带宽是经常性成本。运维投入包括监控、升级、事件响应以及维护备用节点的成本。

由于奖励份额随质押量增长，质押量适中的验证者即使正常运行时间完美也可能无法覆盖成本。这就是为什么许多运营者委托质押而不是依赖自质押，也是为什么有些人选择运行 RPC 基础设施。有关服务选项，请参阅 RPC 定价 和 API 服务。

• 自质押机会成本：锁定资本所放弃的回报。
• 硬件和带宽：经常性成本，对网络增长敏感。
• 运维投入：监控、升级、事件响应、备用节点。
• 奖励份额：由总质押量、佣金和投票表现驱动。

可运行示例：通过 RPC 检查验证者和投票账户状态

你可以使用 Solana JSON-RPC 从链上衡量验证者的健康度。以下 Node.js 脚本调用 getVoteAccounts 列出当前和 delinquent 验证者，然后打印给定投票账户的投票积分、佣金和 delinquent 标志。将端点和投票账户公钥替换为你自己的。

Solana JSON-RPC API 记录了 getVoteAccounts 及相关方法。此脚本是只读的，可以安全地对任何端点运行，包括公共端点，尽管公共端点可能会限流。

定期运行并记录输出。投票积分上升、佣金稳定且没有 delinquent 标志，就是基线健康状态。

const https = require('https');

const ENDPOINT = 'https://api.mainnet-beta.solana.com';
const VOTE_ACCOUNT = 'YOUR_VOTE_ACCOUNT_PUBKEY';

function rpc(method, params) {
  return new Promise((resolve, reject) => {
    const body = JSON.stringify({ jsonrpc: '2.0', id: 1, method, params });
    const req = https.request(ENDPOINT, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' }
    }, (res) => {
      let data = '';
      res.on('data', (chunk) => data += chunk);
      res.on('end', () => resolve(JSON.parse(data)));
    });
    req.on('error', reject);
    req.write(body);
    req.end();
  });
}

(async () => {
  const result = await rpc('getVoteAccounts', [{ commitment: 'finalized' }]);
  const all = [...result.result.current, ...result.result.delinquent];
  const match = all.find(v => v.votePubkey === VOTE_ACCOUNT);
  if (!match) {
    console.log('Vote account not found in current or delinquent set.');
    return;
  }
  console.log({
    votePubkey: match.votePubkey,
    nodePubkey: match.nodePubkey,
    activatedStake: match.activatedStake,
    commission: match.commission,
    epochVoteAccount: match.epochVoteAccount,
    epochCredits: match.epochCredits,
    lastVote: match.lastVote,
    delinquent: result.result.delinquent.some(v => v.votePubkey === VOTE_ACCOUNT)
  });
})();

为你自己的验证者准备可复现结果表

使用下表记录你从自己的端点观察到的结果，并与文档基线进行比较。从 RPC 输出填写“观察值”列，从官方硬件和投票账户文档填写“文档基线”列，并根据你自己的阈值填写“结论”和“行动”列。

此方法由读者验证：数字来自你的端点和你的验证者，而非供应商基准。在每个版本之后以及任何硬件变更之后重新运行。

• 维度：每 epoch 投票积分 | 观察值： | 文档基线：每个 epoch 增加 | 结论： | 行动：
• 维度：跳过率 | 观察值： | 文档基线：接近零 | 结论： | 行动：
• 维度：delinquent 标志 | 观察值： | 文档基线：false | 结论： | 行动：
• 维度：slot 滞后 | 观察值： | 文档基线：小且稳定 | 结论： | 行动：
• 维度：CPU 利用率 | 观察值： | 文档基线：低于饱和 | 结论： | 行动：
• 维度：内存使用和交换 | 观察值： | 文档基线：无交换 | 结论： | 行动：
• 维度：磁盘 I/O 延迟 | 观察值： | 文档基线：低且稳定 | 结论： | 行动：
• 维度：到集群的网络延迟 | 观察值： | 文档基线：低 | 结论： | 行动：

排查常见验证者健康问题

漏投是最常见的症状。如果投票积分停滞，首先检查 CPU 饱和、磁盘 I/O 停顿和网络延迟。一个正在交换或等待磁盘的验证者即使质押充足也会漏投。

delinquent 状态通常意味着验证者已经落后于集群。检查节点是否同步、身份和投票密钥是否正确，以及节点能否访问集群。如果你运行备用节点，请确认同一时间只有一个节点使用相同投票账户投票。

佣金和质押变化也会影响奖励。如果你的佣金相对于同行较高，委托者可能会离开，从而减少你的质押和奖励份额。同时监控质押账户委托和投票账户佣金。

• 投票积分停滞：检查 CPU、磁盘 I/O、网络延迟。
• delinquent：验证同步、密钥和集群连接。
• 双重投票风险：确保每个投票账户只有一个节点投票。
• 奖励下降：检查佣金和委托质押变化。

局限性、权衡与后续步骤

验证者经济模型由质押而非硬件主导。配置完美的节点如果质押很少，也不会赚取有意义的奖励。硬件指南随版本漂移，因此任何规模决策都应定期重新审视。运行验证者是一项始终在线的运维承诺，验证者要求绝不应与 RPC 节点规模配置混为一谈。

如果你的目标是提供读取流量而非投票，请考虑 RPC 节点或托管服务。OnFinality 提供 Solana RPC 端点 和网络信息，请访问 Solana 网络。如需更广泛的学习路径，请从 OnFinality Learn 中心 开始。

后续步骤：针对你的端点运行上面的 RPC 脚本，填写结果表，并与官方 Solana 验证者要求 和 投票账户 文档进行比较。每个版本后重新核对，并随着网络条件变化重新审视你的质押和佣金策略。

• 质押主导经济模型；硬件是必要条件但非充分条件。
• 硬件基线会漂移；每个版本都要重新核对。
• 验证者始终在线；规划监控和故障转移。
• 不要将验证者规模配置与 RPC 节点规模配置混为一谈。
• 下一步：用 RPC 测量，填写表格，与官方文档比较。