Aptos 全节点要求、存储与 RPC 设置

Aptos 节点角色全景：验证者、全节点与提供 API 的全节点

Aptos 节点可以以多种配置运行，它们的要求差异很大。验证者节点参与共识，这意味着它必须管理身份密钥、满足社区和质押资格规则，并保持严格在线时间。全节点同步账本并可提供 REST API，但不对区块投票。Aptos 节点类型文档清楚地区分了这些角色，这种区分很重要，因为大多数基础设施团队并不需要验证者。

大多数团队真正想要的配置是运行 REST/JSON-RPC API 的全节点。该节点通过 HTTP 应答账户、区块、交易和事件查询。Aptos 全节点文档描述了设置路径，Aptos API 文档描述了节点暴露的 REST 接口。如果你的目标是为 dapp、索引器或钱包提供读流量，那么你是在规划全节点，而不是验证者。

• 验证者：参与共识、身份密钥、质押资格、严格在线时间。
• 全节点：同步账本、提供 REST API、不投票。
• 提供 API 的全节点：大多数读密集型团队需要的配置。
• 托管 RPC：当自托管开销超过控制收益时的替代方案。

决定 Aptos 节点规格的四个资源维度

Aptos 执行及其并行执行引擎受 CPU 限制，因此核心数和单线程速度同时决定同步进度和查询延迟。内存必须容纳内存中的状态和索引结构；如果放不下，节点就会交换并落后于链头。存储必须容纳账本和状态快照，它们持续增长，需要高耐久性的快速 NVMe。网络吞吐量对同步和 API 流量都很重要，因此带宽和低延迟对等连接也是规格规划的一部分。

Aptos 官方文档发布了硬件表，应将其视为不断变化的基线。它会随着网络负载和版本变化而上升，因此请始终根据当前文档而非缓存副本来核对你的计划。要更广泛地比较这些维度如何映射到其他链，请参阅 Solana RPC 节点要求与硬件规格。

• CPU：核心数和单线程速度影响执行与查询延迟。
• 内存：必须容纳内存状态和索引，避免交换。
• 存储：高耐久性的快速 NVMe；快照归档会成倍增加容量。
• 网络：同步和 API 流量所需的吞吐量与低延迟对等连接。

文档中的最低与推荐硬件基线

Aptos 文档将硬件指导分为最低和推荐两个层级。最低层级是基本运行的下限，而推荐层级面向生产 RPC 流量和更快的同步。由于网络会增长，推荐层级是一个不断变化的目标。请将发布的表格视为需要验证的基线，而不是永久规格。

在规划容量时，请根据当前文档中的值测量你自己的节点。下表是一个模板，你可以填入测量值以及当前 Aptos 文档中的最低和推荐值。这能让你的规格决策可复现、可审计。

• 最低：基本运行、同步较慢，不适合生产 RPC。
• 推荐：生产 RPC、同步更快、余量更高。
• 移动基线：每个版本都要根据当前 Aptos 文档核对。
• 测量你的节点：CPU、内存、存储 IOPS、网络吞吐量。

同步策略：状态快照与创世引导

Aptos 全节点可以从状态快照引导，这比从创世同步快得多。权衡在于信任：快照必须来自你信任的来源，其新鲜程度决定还需要额外同步多少。创世同步很慢，但从头验证完整链历史。Aptos 全节点文档描述了这两种路径。

对于生产 RPC，快照同步通常是务实的选择，因为它能让节点快速达到近期状态。但是，如果你的用例需要历史验证或归档级数据，请在确定同步策略之前查看归档节点与全节点和访问历史区块链数据。

• 快照同步：快速，需要可信来源，可能需要额外同步。
• 创世同步：缓慢，验证完整历史，时间成本高。
• 归档需求：历史查询可考虑归档节点模式。
• 新鲜度：开始同步前检查快照年龄。

暴露并验证 Aptos REST API

节点在其 HTTP 端口上提供 REST API。在路由流量之前，确认它能响应标准端点：节点信息或账本信息调用、账户查询和按高度查询区块。Aptos API 文档列出了可用端点，不过确切接口会因节点版本和配置而异。

验证应脚本化以便可重复。以下 curl 示例探测运行中的 Aptos 节点 REST API 的账本信息、账户资源和按高度查询区块。请将基础 URL 替换为你节点的 HTTP 端点。

#!/usr/bin/env bash
# Probe an Aptos full node REST API
BASE_URL="http://localhost:8080"

# 1. Ledger info: synced version and chain id
curl -s "$BASE_URL/v1" | jq '{chain_id, ledger_version, ledger_timestamp}'

# 2. Account resource (replace with a known account address)
curl -s "$BASE_URL/v1/accounts/0x1/resource/0x1::account::Account" | jq .

# 3. Block by height (replace with a recent height)
curl -s "$BASE_URL/v1/blocks/by_height/1000000?with_transactions=false" | jq '{block_height, block_hash}'

可运行的 Node.js 探针：检查 Aptos REST API 健康状态

Node.js 探针可以集成到监控中。下面的示例获取账本信息、账户资源和按高度查询区块，然后打印同步版本、链 ID 以及 API 是否应答。它使用现代 Node.js 内置的 fetch API。

针对你节点的 HTTP 端点运行此脚本。如果任何调用失败，节点可能仍在同步、端点可能配置错误，或者 API 接口可能因版本而异。使用输出决定是否路由流量。

// aptos-probe.js
const BASE_URL = process.env.APTOS_NODE_URL || 'http://localhost:8080';

async function probe() {
  const results = {};
  try {
    const ledgerRes = await fetch(`${BASE_URL}/v1`);
    const ledger = await ledgerRes.json();
    results.chainId = ledger.chain_id;
    results.syncedVersion = ledger.ledger_version;
    results.ledgerTimestamp = ledger.ledger_timestamp;
  } catch (e) {
    results.ledgerError = e.message;
  }

  try {
    const accountRes = await fetch(`${BASE_URL}/v1/accounts/0x1/resource/0x1::account::Account`);
    results.accountStatus = accountRes.status;
  } catch (e) {
    results.accountError = e.message;
  }

  try {
    const blockRes = await fetch(`${BASE_URL}/v1/blocks/by_height/1000000?with_transactions=false`);
    results.blockStatus = blockRes.status;
  } catch (e) {
    results.blockError = e.message;
  }

  console.log(JSON.stringify(results, null, 2));
  const answered = results.chainId !== undefined && results.accountStatus === 200;
  console.log(`API answered: ${answered}`);
}

probe();

用于节点规格和 API 探针的可复现结果表

使用以下表格记录你的测量值，并与文档中的值进行比较。第一个表涵盖资源维度；第二个表涵盖 API 探针。填入你自己的观察结果，形成可复现的记录。

对于规格表，测量你节点的 CPU 核心数、内存、存储 IOPS 和网络吞吐量。与当前 Aptos 文档中的最低和推荐值进行比较。结论列应说明你的节点是达到、超过还是低于基线。行动列应记录下一步，例如升级存储或增加内存。

• 维度：CPU、内存、存储、网络。
• 测量值：你观察到的指标。
• 文档最低值：来自当前 Aptos 文档。
• 文档推荐值：来自当前 Aptos 文档。
• 结论：达到、超过或低于。
• 行动：升级、监控或接受。

API 探针结果表模板

API 探针表可帮助你验证节点是否在提供预期端点。记录端点、预期响应、观察到的响应以及任何备注。这在比较节点版本或配置时很有用。

例如，账本信息端点应返回 chain_id 和 ledger_version。账户资源端点对已知账户应返回 200 状态。按高度查询区块端点应对近期高度返回区块。如果任何端点失败，请记录错误并检查节点日志。

• 端点：/v1、/v1/accounts/{address}/resource/{resource}、/v1/blocks/by_height/{height}。
• 预期：chain_id、ledger_version、200 状态、区块数据。
• 观察到的：你的实际响应。
• 备注：版本差异、同步状态、配置。

自托管 Aptos 全节点的局限与权衡

Aptos 硬件指导会随版本变化，因此请始终根据当前文档核对。从创世同步耗时很长，而快照同步更快，但必须信任其来源。REST API 接口和可用端点因节点版本和配置而异，因此在一个节点上可用的功能在另一个节点上可能不可用。

对于许多读密集型团队来说，托管 RPC 提供商仍然比自托管更具成本效益。如果你的工作负载主要是读取，请将总拥有成本与 RPC 定价和 Aptos RPC 端点（RPC Assistant）页面进行比较。自托管仍然需要持续升级、磁盘监控和 API 加固。对于需要控制数据本地性或自定义索引的团队，自托管可能仍然合理。

• 硬件指导随版本变化；请根据当前文档验证。
• 快照同步信任：来源必须可靠。
• API 接口因版本和配置而异。
• 对于读密集型工作负载，托管 RPC 通常更具成本效益。
• 自托管需要升级、磁盘监控、API 加固。

排查常见的 Aptos 全节点问题

如果节点未同步，请先检查磁盘空间。账本和状态快照持续增长，磁盘满会停止同步。接下来，验证网络连接和对等节点数量。如果节点正在同步但 REST API 无响应，请确认 HTTP 端口已打开且节点配置中启用了 API 服务。

如果 API 调用返回错误，请检查节点版本和端点路径。某些端点可能已弃用或重命名。如果节点落后于链头，ledger_version 会滞后。使用上面的探针脚本识别哪个组件失败。要了解更广泛的基础设施模式，请参阅 OnFinality Learn 中心和 API 服务概览。

• 磁盘满：扩展存储或在支持时进行修剪。
• 无对等节点：检查网络和防火墙规则。
• API 无响应：验证 HTTP 端口和服务配置。
• 版本不匹配：根据当前文档检查端点路径。
• ledger_version 滞后：节点仍在同步或资源不足。

后续步骤：从本地节点到生产 RPC

一旦节点同步且 REST API 验证通过，你就可以将流量路由到它。对于生产环境，考虑跨多个节点进行负载均衡、监控磁盘和 CPU，并自动化升级。如果你希望避免运维开销，请评估托管 RPC 提供商。Aptos RPC 端点（RPC Assistant）页面列出了提供商选项，RPC 定价有助于比较成本。

对于在 Aptos 上构建的团队，Aptos 网络页面提供了网络和可用服务的概览。如果你还运行其他链，Sui 全节点 RPC 端点设置指南遵循类似的模式。请始终让节点软件保持最新，并根据当前 Aptos 文档重新测量。

• 验证 API 健康后再路由流量。
• 为生产环境对多个节点进行负载均衡。
• 持续监控磁盘、CPU 和网络。
• 自动化升级以匹配网络版本。
• 比较托管 RPC 成本与自托管成本。