从 geth 迁移至 reth：X Layer 执行客户端的演进
X Layer 是 OKX 推出的基于 OP Stack 的 EVM 兼容 Layer 2 网络。自上线以来，X Layer 经历了两次关键的架构演进：先从 Polygon CDK（zkEVM Validium）整体迁移至 OP Stack，再将执行客户端从 geth 升级至 reth。本文聚焦于后者，介绍这次升级的技术动因，以及为适配 X Layer 生产环境所完成的关键工程实现。
一、技术选型背景
OP Stack 生态的执行客户端长期以 geth 为主流——geth 是 go-ethereum 的 OP Stack 分支，稳定性经过充分验证。然而随着链上交易量的持续增长，go-ethereum 在架构层面的两个局限性愈发突出。其一是存储开销。归档节点的磁盘占用随链历史线性增长，在 L2 的高吞吐场景下，增速相当可观，长期运营的成本压力不可忽视。其二是延迟稳定性。Go 语言的垃圾回收机制在持续高负载下会引入不确定性停顿，LevelDB/PebbleDB 的后台压缩也会周期性阻塞出块流程，最终体现为用户可感知的尾延迟抖动。reth 由 Paradigm 以 Rust 重写，从架构层面解决了上述问题。Rust 的所有权模型在编译期完成内存管理，彻底消除了运行时 GC 开销；reth 采用 MDBX 存储引擎与阶段式同步架构，在磁盘效率和延迟一致性上均有质的提升。可扩展性是另一个关键考量。reth 提供了完整的 Node Builder API——通过预定义的框架钩子，可以在不触碰上游源码的前提下，将自定义逻辑注入节点生命周期的各个阶段。对于需要深度定制的 L2 执行客户端，这套机制意味着更小的 diff、更低的升级成本，以及更清晰的自定义逻辑边界。
二、整体架构设计
xlayer-reth 采用三层依赖结构：
xlayer-reth ← X Layer customization layer
└── op-reth ← OP Stack execution layer (maintained by Optimism)
└── paradigmxyz/reth ← core Rust Ethereum execution engine所有 X Layer 特有的代码均收敛于顶层，通过 reth 的框架钩子接入；中间两层直接引用各自上游仓库的代码，不引入任何私有改动。这一结构保证了上游的安全修复与性能优化可以低成本地持续合入，合并时无需处理核心逻辑的分叉冲突。代码组织上，各功能模块以独立 crate 形式拆分，包括 Chainspec、历史 RPC 路由、Flashblocks、自定义 RPC 等。每个 crate 独立演化与测试，主二进制仅负责将它们组合装配。
三、核心功能实现
非零起始块号支持
X Layer 从 Polygon zkEVM 迁移至 OP Stack 时，旧链在主网第 42,810,021 号区块终止，OP Stack 新链从该高度接续出块。这一连续的区块号对区块浏览器、链上索引服务，以及任何依赖历史区块号的应用而言都至关重要。然而 reth 最初在初始化创世块时固定使用区块号 0，genesis JSON 中的 number 字段被静默忽略。X Layer 团队为此向 reth 社区提交了 Issue #19874，并以 PR #19877 的形式将非零创世块号支持合入了官方 reth，而非在私有 fork 中维护补丁。该 PR 已合并，其他有类似迁移场景的链可以直接使用。
历史数据透明路由
迁移高度（第 42,810,021 号区块）以下的历史状态仅存储于旧 Polygon zkEVM 节点（基于 erigon），新 reth 节点本地不持有这部分数据。若不加处理，针对迁移前区块的 RPC 查询将返回空结果。xlayer-reth 在 jsonrpsee RPC 服务栈中引入了一个 Tower 中间件路由器。请求到达 reth 之前，路由器依据所查区块号与迁移高度的关系进行判断：低于阈值的请求透明转发至旧节点，其余由本地 reth 处理。对调用方而言，整个过程无感知——同一个 RPC 端点覆盖了完整的区块范围。涉及区块范围的查询需要额外处理。以eth_getLogs 为例，当查询范围横跨迁移前后时，路由器会将其拆分为两个并发子请求，分别发往新旧节点，结果合并后统一返回，无需客户端做任何特殊处理。
硬分叉与链参数配置（Chainspec）
xlayer-reth 内置了 X Layer 三个网络（主网链 ID 196、测试网、开发网）的完整链参数，涵盖链 ID、创世区块配置及所有硬分叉的激活时间表。从以太坊 Frontier 到 OP Stack Isthmus，所有历史硬分叉均在 X Layer 创世时即激活。节点无需回放历史协议演进，从第一个区块起便运行于当前的完整 EVM 执行环境。这避免了节点启动时逐一回放历史分叉规则的复杂性。此外，X Layer 还定义了自定义硬分叉 Jovian，对应 OP Stack 第 17 次网络升级。Jovian 已于 2025 年 12 月在主网激活，与 OP 主网的升级节奏保持同步。
Flashblocks
OP Stack 的标准出块间隔约为 2 秒。Flashblocks 是一种预确认机制，可将用户感知到的交易确认延迟降低约 10 倍：sequencer 每隔约 250 毫秒向外发布一个 flashblock（区块执行的中间状态），客户端无需等待完整区块上链即可获取交易执行结果。在节点侧，RPC 节点通过 WebSocket 实时订阅上游 sequencer 推送的 flashblock 流，在本地完整执行后将状态写入内存缓存。22 个标准以太坊 RPC 方法（包括 eth_getBlockByNumber、eth_getBalance、eth_call 等）被覆写，当查询 latest 或 pending 状态时直接从该缓存返回预确认结果。为减少重复执行，引擎验证器与 Flashblocks 处理器共享同一套执行状态缓存。flashblock 阶段已执行的交易，在引擎验证完整 payload 时可直接复用。
自定义 RPC 扩展
xlayer-reth 在标准以太坊 JSON-RPC 基础上新增了两个 X Layer 专有接口：
eth_flashblocksEnabled：查询节点的 Flashblocks 服务是否处于活跃状态，并正常接收 sequencer 数据。
eth_flashblocksPeerStatus：返回 sequencer 节点上 Flashblocks P2P 层各 peer 的连接状态，供运维监控使用。
两个接口通过 reth 的 RPC 扩展机制注册，与标准接口共存，不影响任何现有方法的行为。
四、工程实践原则
xlayer-reth 的开发遵循两条核心原则。优先通过框架钩子注册，不修改上游代码：凡是能通过 reth 已有的框架钩子实现的功能——中间件注册、引擎验证器注入、RPC 模块替换——均以此方式接入，不修改上游源码。定制逻辑收敛于顶层 crate，便于独立审计与迭代，上游更新的合并成本极低。具有通用价值的修改贡献至上游：若某项功能确实需要改动 reth 内部逻辑，优先以 PR 形式合入官方仓库，而非在私有 fork 中积压补丁。非零创世块号支持（PR #19877）是这一原则的落地案例：该能力现已成为 reth 的原生特性，其他有同类需求的链可直接使用，无需各自维护分叉。
五、总结
将执行客户端从 geth 迁移至 reth，核心驱动力是性能——更低的区块构建延迟、更小的存储开销、更快的节点同步速度。要在生产环境中兑现这些收益，需要系统性地解决 X Layer 特有的工程问题：来自旧链的非零创世区块、仅存于旧节点的历史状态、跨越两套协议架构的链参数配置、改变客户端交互模式的预确认机制，以及配套的运维监控能力。以成熟开源框架为基础进行扩展、而非 fork 核心基础设施，并将通用改进回馈给社区，是 X Layer 技术演进的一贯路径，也是 L2 生态中可持续的工程协作模式。 代码仓库：okx/xlayer-reth
