轻节点：专门化你的Op-Node节点舰队 - Optimism

===== 开始 MARKDOWN 内容 ===== TL;DR

• 我们推荐一种专门的 op-node 拓扑结构：一个由少数源节点组成的小层级负责 L1 派生，其余节点作为轻节点运行，通过 -l2.follow.source 跟随这些源节点。

• 运营方将获得更低的 L1 RPC 开销、独立扩展的读取能力、更快的排序器，以及每次未来协议升级时更小的爆炸半径。

• 迁移只需为每个节点添加一个标记。原有的同质化设置仍可正常工作，并且你可以逐个节点进行迁移。

• 现在进行专门化还为未来的互操作性以及其他派生的变更提供了更清晰的运行轨道。

源节点派生一次。轻节点跟随。整个节点集群运行更精简。

轻量级、角色专门的节点设计一直是整个生态系统中长期研究的领域。通过此次发布，OP Labs 将这一理念转化为生产就绪的版本，专门针对大规模运行 OP Stack 链的实际运营需求。这是我们持续改进 op-node 和 kona-node 的最新一步，也是我们期望随着堆栈成熟而不断发展的面向运营方的基元。

为什么：专门化的理由

随着节点集群的增长，四个优势会相互叠加。

从今天起降低 L1 成本。 轻节点停止运行 L1 派生流水线。它们仍会为 op-node 所需的其他功能保持 L1 RPC 连接，但每个节点上繁重的派生流量将从轻节点层消失。如果你运行十个节点，就不再需要为十份派生流量付费。无论轻节点层之后扩展出多少个节点，派生工作仅在源节点层进行一次。对于按调用向 L1 提供商付费的运营方来说，这种变更在上线当天就能收回成本。

每层专注于自己的任务。 轻节点将资源用于推进不安全链和服务 RPC。源节点专注于派生。我们已经看到这在排序器上产生了效果，基准测试显示，在区块生产过程中，移除派生消除了真正的瓶颈。

非对称扩展。 RPC 容量和派生容量成为独立变量。需要在大规模发布前吸收更多读取请求？增加轻节点，L1 负载不会变化。需要更多派生冗余？单独调整源节点层的大小，遵循自己的服务等级目标。

未来升级的更小爆炸半径。 未来的协议变更，包括互操作性，将需要更复杂的派生逻辑。将派生集中在少数源节点层，缩小了受这些升级影响的运营表面积。需要了解派生工作方式的节点越少，每次未来部署的成本就越低。

最后一个优势最为隐蔽，但长期来看却最为重要。

如何实现：源节点和轻节点

新的拓扑结构将节点集群分为两个角色。

源节点是传统的 op-node。它像以前一样从 L1 派生完整的链。通常你会运行一组小型冗余的源节点，其规模由派生吞吐量和故障切换需求决定，而不是由读取流量决定。

轻节点是一个使用新标记 --l2.follow.source=<源 op-node RPC> 启动的 op-node。设置此标记后，它停止运行自己的派生流水线，而是从其指定的源接收安全链。节点的其他一切保持不变：它仍然服务 RPC，仍然参与 gossip，仍然驱动其连接的执行客户端。

有几件事值得明确说明：

op-node 并未弃用。经典的同质化设置也不会被移除。专门化节点集群是一项推荐的运营升级。现有的部署仍可正常工作，你可以逐个节点进行迁移，也可以同样轻松地回滚。

轻节点模式也可在 Kona（op-node 的 Rust 实现）中使用，供希望在该路径上测试的运营方使用。

生产环境参考架构

对于生产环境，我们推荐一个三层架构，将新设计与具有共识意识的（consensus-aware）proxyd 相结合：

派生层位于后端：一组小型冗余的、启用派生的 op-node（你的源节点），位于配置了 consensus_aware_consensus_layer 路由策略的 proxyd 后面。proxyd 将多个源节点聚合成一个高可用端点，并向下游隐藏单个节点的故障或重组。

轻节点层位于派生层之前：一个可水平扩展的轻 op-node 池，指向派生层的 proxyd。你可以根据读取流量上下扩展它，而派生层不会感知到变化。

边缘层位于最前端：面向用户的 API 网关或 proxyd，前端连接轻节点层，处理外部 RPC、限流和路由。

这种形态具有通用性。如果你的堆栈已经运行在另一个负载均衡器或服务网格后面，可以应用相同的理念：一个最小化、定义清晰的派生层，前面是可扩展的轻节点集合。

如何迁移

迁移是增量且低风险的。

1. 指定你的源节点。 选择一个或多个现有的 op-node 继续运行完整的 L1 派生。根据派生吞吐量调整其规模，并确保具备故障切换冗余。这些节点现在成为你节点集群中最重要的节点，因此在仪表板和告警中应当如此对待。

2. 将其他节点转换为轻节点，一次一个，通过设置 -l2.follow.source 指向源 op-node 的 RPC 端点。确保每个轻节点到其源节点具有可靠、低延迟的网络路径。

3. 验证。 确认每个转换后的轻节点正确跟踪了相对于其源节点的安全链，然后再将生产流量切换到它。

4. 更新监控。 源节点层现在是轻节点层的硬依赖，应作为一个整体进行告警。

完整的标记列表很短：

bash

# 在轻节点上：
OP_NODE_L2_FOLLOW_SOURCE=https://your-source-op-node.example/rpc
OP_NODE_L2_FOLLOW_SOURCE_RPC_TIMEOUT=10s # 默认值

对于链运营方，同样的指导原则适用，我们特别建议也将排序器（sequencer）op-node 通过 --l2.follow.source 指向一个源节点。排序器的工作是扩展不安全链，而卸载派生可以消除区块生产中的一个真正瓶颈。

哪些发生了变化，哪些没有变化

变化的内容

• L1 派生仅在源节点层运行。轻节点层不再承担该负载。
• RPC 和派生成为独立的扩展轴。
• 未来涉及派生的升级将落在源节点层，而不是每个节点。

未变化的内容

• 轻节点仍然服务 RPC，仍然参与 gossip，并且仍然像以前一样驱动其 EL。
• 轻节点仍然为非派生需求保持 L1 RPC 连接。它们只是不再为了派生流水线而频繁调用它。
• 现有的同质化部署仍可正常工作。迁移是自愿选择且可逆的。

专门化节点集群是运营规范的一个层面，而非终点。排序器安全性、监控、冗余规划以及其他生产清单事项仍然重要。

这对未来意味着什么

现在专门化节点集群，可为接下来的发展做好准备。随着 OP Stack 的演进，op-node 本身可能不足以作为未来所有特性的派生源，源节点角色可能会扩展到包含与之协同运行的额外软件。早期进行专门化的运营方只需在派生层吸收这些变化，而不是在集群中的每个节点上。

这种设置未来将变成运行 OP Mainnet 和 Unichain 节点的运营方的必选要求。目前，它是一个强烈推荐的选择。早期专门化的运营方立即获得成本优势，并且在每次后续升级时，节点集群已经为此做好了准备。

完成标准

当满足以下所有条件时，你的节点集群即达到标准：

• 一个或多个 op-node 实例被指定为源节点，根据派生吞吐量调整规模并具备故障切换。
• 每个其他 op-node 都使用 -l2.follow.source 指向源节点层启动。
• 轻节点正确跟踪相对于其源节点的安全链。
• 在生产环境中，派生层位于具有共识意识的 proxyd 之后，轻节点层在其前面独立扩展。
• 排序器 op-node 使用 -l2.follow.source 卸载派生。
• 仪表板和告警将源节点层作为轻节点层的硬依赖进行处理。

如果任何一项未满足，你仍在为不需要的派生工作付费。

参考资料

• 采用轻节点的专门化 op-node 拓扑 — 完整通知，包括参考架构图和确切的标记定义。
• 具有共识意识的（consensus-aware）proxyd — 生产架构必读材料。
• Kona — op-node 的 Rust 实现。轻节点模式也在此提供，供希望在 Rust 路径上测试的运营方使用。 ===== 结束 MARKDOWN 内容 =====

• 原文链接： optimism.io/blog/light-n...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～