运行 Optimism 节点有哪些要求？

Optimism 是一个 OP Stack rollup，因此“运行节点”并非单个进程。你需要同时运行执行客户端（通常是 op-geth）和共识客户端（op-node），而 op-node 依赖与以太坊 L1 端点的连接来推导 rollup 状态。这种双客户端架构是 Optimism 节点要求与普通 EVM 链节点最大的区别。

本页提供实际数字、全节点与归档节点的决策依据，以及为更愿意使用端点而非运营整个技术栈的团队提供的清晰路径。

你应该运行 Optimism 节点还是使用托管端点？

在确定硬件规格之前，先决定自托管是否真的合适。运行整个技术栈让你完全控制数据，但也意味着你需要负责磁盘增长、L1 成本、客户端升级和监控。

一个有用的规则：如果你的团队核心价值是应用而非节点运营，那么托管的 RPC API 或 专用节点 通常消除的风险多于增加的风险。如果你的核心价值是独立验证或自定义数据管道，自托管值得付出运营成本。

你实际运行的两个客户端

一个 Optimism 节点由两个进程组成：

• op-geth — 执行客户端。它执行 L2 交易、维护状态并提供 JSON-RPC 服务。大部分 CPU、RAM 和磁盘压力都落在这里。
• op-node — rollup 共识客户端。它读取 L1 数据、推导规范的 L2 链并驱动 op-geth。它需要一个可靠的 L1 RPC 端点。

由于 op-node 跟随以太坊 L1，你的节点健康取决于两条链，而非一条。如果你的 L1 端点缓慢或受限，即使 L2 节点自身硬件没问题，也会落后。

硬件要求一览

以下数字是已同步节点的实际起点，而非供应商最低要求。实际使用量取决于同步模式、请求负载以及你保留历史数据的时间。

有两个注意事项比具体数字更重要。首先，磁盘是最让人意外的资源：链数据持续增长，因此要按未来一年而非当前需求来规划容量。其次，对于 RPC 工作负载，I/O 延迟比原始容量更重要——在查询负载下，大容量 SATA SSD 会比小容量 NVMe 驱动器感觉更慢。

全节点与归档节点

这是对你的账单影响最大的决策。

全节点保留近期状态，可以服务当前状态查询和近期日志。它是验证、跟随链头以及大多数应用后端的正确选择。

归档节点保留历史状态，因此你可以查询任意过去区块的余额、存储和状态。区块浏览器、分析工具以及任何重建历史的工具都需要它。归档节点需要显著更多的磁盘，同步时间也更长。

如果你只需要历史日志而非历史状态，在投入归档基础设施之前，请检查你的提供商的标准端点是否已支持你需要的日志范围。

同步模式及设置耗时

Optimism 节点通常通过从 L1 推导状态来同步，这比下载快照慢。预计初始同步需要相当长的时间，并且主要受 L1 数据可用性和磁盘速度影响。

缩短痛苦的实用技巧：

• 在同步期间使用具有充足请求限制的高速 L1 端点。
• 将链数据放在本地 NVMe 上，而非网络存储。
• 分别监控 op-node 和 op-geth 日志；op-node 停滞看起来像节点停滞。
• 基于快照的引导可以缩短同步时间，但请验证快照来源以及与客户端版本的兼容性。

连接并测试你的节点

一旦 op-geth 开始提供 RPC 服务，在将生产流量指向它之前，确认链身份和链头。快速检查：

curl -s http://localhost:8545 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

你应该得到 OP Mainnet 链 ID（0xa，即十进制的 10）。然后检查节点是否在跟随链头：

curl -s http://localhost:8545 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

如果你更愿意连接托管端点，公共 Optimism 端点是 https://optimism.api.onfinality.io/public，测试网等效端点是 https://optimism-sepolia.api.onfinality.io/public。对于生产流量，请使用经过身份验证的端点而非公共端点。

要将钱包或库指向 Optimism，网络参数如下：

在 JavaScript 中使用 viem，读取调用如下所示：

import { createPublicClient, http } from 'viem';
import { optimism } from 'viem/chains';

const client = createPublicClient({
  chain: optimism,
  transport: http('https://optimism.api.onfinality.io/public'),
});

const block = await client.getBlockNumber();
console.log('Optimism head:', block);

人们容易忽略的运营要求

硬件只是故事的一半。在投入之前，为以下事项做好预算：

• L1 端点成本和限制。 op-node 持续读取 L1。受速率限制的 L1 端点会降低你的 L2 节点性能。
• 客户端升级。 OP Stack 客户端发布频繁。你需要一个流程来测试和推出升级，同时避免长时间停机。
• 监控。 跟踪链头延迟、对等节点数量、磁盘使用率和 RPC 错误率。链头延迟是问题的最早信号。
• 备份和恢复。 了解重新同步需要多长时间，因为那是你最坏情况下的恢复时间。
• 安全。 仅向受信任的网络暴露 RPC；不要在公共 IP 上留下开放的管理接口。

常见故障模式及修复

何时托管端点是务实的选择

当独立验证或自定义数据访问是你的核心工作时，自托管是合理的。对于大多数应用团队来说，节点是依赖项，而非产品。在这种情况下，使用托管的 Optimism RPC 端点可以从你的路线图中移除磁盘增长、L1 成本和升级周期。

OnFinality 通过共享 RPC API 和专用节点选项提供 Optimism RPC，在支持的 RPC 网络中采用相同的端点模式。你可以在 RPC 定价 页面比较计划，如果你正在总体权衡提供商，提供商选择指南 会介绍评估标准。

关键要点

• Optimism 节点是两个客户端：op-geth（执行）和 op-node（共识），op-node 需要可靠的以太坊 L1 端点。
• 全节点起步约为 4–8 核、16 GB RAM 和 NVMe 存储，但磁盘持续增长——为未来规划容量。
• 归档节点需要数 TB 和更长的同步时间；仅在你需要历史状态时选择归档。
• 磁盘 I/O 和 L1 端点质量导致的生产事故比原始 CPU 更多。
• 如果你的应用就是产品，托管 RPC 端点或专用节点通常是风险更低的路径。

常见问题

我可以在不运行以太坊节点的情况下运行 Optimism 节点吗？ 可以。op-node 需要一个 L1 RPC 端点，但那可以是托管的以太坊端点，而非自托管的 L1 节点。

Optimism 全节点需要多少磁盘？ 计划数百 GB 并持续增长。归档节点需要数 TB。始终按至少未来一年的增长来规划容量。

eth_getLogs 需要归档节点吗？ 不一定。日志查询取决于区块范围和提供商的保留策略。在配置归档基础设施之前，先针对标准端点测试你的范围。

Optimism 的链 ID 是什么？ OP Mainnet 使用链 ID 10。Optimism Sepolia 使用 11155420。

专用节点比共享端点更好吗？ 取决于工作负载。共享端点适合大多数应用；当你需要可预测的资源、大量日志或 trace 查询，或与其他租户隔离时，专用节点更有帮助。

在哪里可以获得 Optimism RPC 端点？ OnFinality 通过其 RPC API 和 专用节点 选项提供 Optimism RPC。连接详情请参见 Optimism 网络页面。