一文解读以太坊Reth如何实现每秒1GB gas

以太坊 Reth 如何实现每秒 1GB gas？一文读懂性能扩展路线图

本文带你了解以太坊执行层客户端 Reth 的最新性能规划：如何在 L2 上达到每秒 1GB gas 的吞吐量，以及长期超越这一目标的路线图。适合对以太坊扩展、EVM 性能优化感兴趣的开发者与节点运营者阅读。

1. 我们是否已实现规模化扩展？

要实现加密货币的全球规模，避免投机成为主要用例，核心路径是：交易必须低价且快速。本节先回答性能度量标准与当前发展阶段。

1.1 如何衡量性能？每秒 gas 量指的是什么？

传统用“每秒交易数（TPS）”衡量性能，但对于以太坊等 EVM 区块链，更准确的指标是每秒 gas 量（gas per second）。gas 是衡量交易或智能合约执行所需计算工作量的单位。以每秒 gas 量作为标准，能更清晰反映区块链的容量与效率，同时防止拒绝服务（DOS）攻击。该指标也便于比较不同 EVM 兼容链的性能。建议 EVM 社区采用此标准，再结合其他 gas 定价维度构建综合性能基准。

1.2 我们如今的发展阶段

每秒 gas 量通过区块目标 gas 使用量除以区块时间得出。下表展示了部分 EVM L1 和 L2 链的当前吞吐量与延迟（非详尽）：

（注：原文表格未提供具体数值，此处保留说明）

我们强调每秒 gas 量以全面评估 EVM 网络性能，同时捕获计算与存储成本。Solana、Sui、Aptos 等因其独特成本模型未包含在内。我们也正为 Reth 开发无间断基准测试工具，复制真实工作负载，节点要求符合 TPC 基准。

2. Reth 如何达到每秒 1GB gas？甚至更高？

2022 年创建 Reth 的动机之一是迫切需要专为 web rollup 构建的客户端。目前 Reth 在实时同步期间已达到每秒 100-200MB gas（含发送方恢复、执行交易、计算各区块 trie），要实现 1GB gas 短期目标需再扩展 10 倍。

扩展计划需平衡可扩展性与效率：

• 垂直扩展
  ：最大化每个“box”的潜力，优化单系统处理交易与数据的方式，提高节点运营商效率。

• 水平扩展
  ：应对 web 规模的绝对交易量，部署类似 Kubernetes 的水平架构，跨多系统分散工作负载，避免单节点瓶颈。

以下优化不涉及状态增长解决方案（另文讨论）。计划概况如下（图片展示）：

（注：原文此处有图片，src 未提供，保留占位）

整个技术栈采用 actor 模型优化 IO 和 CPU，支持各部分作为服务部署并精细控制。同时正在积极评估备选数据库，尚未确定。

2.1 Reth 的垂直扩展路线图

垂直扩展目标：最大化运行 Reth 的服务器或笔记本的性能与效率。

（1）即使（Just-In-Time）EVM 和提前（Ahead-of-Time）EVM

EVM 字节码通常由解释器逐条执行，存在开销。即时编译（JIT）能在执行前将字节码转换为原生机器码，绕过 VM 解释层提高性能。但 JIT 可能受恶意代码攻击，且实时执行时速度可能不够。Reth 采用提前编译（AOT）将需求最高的合约编译为本地码并存储在磁盘，避免实时执行时受信字节码滥用原生编译过程。我们正为 Revm 开发 JIT/AOT 编译器，已完成基准测试并即将开源。约 50% 的执行时间花在 EVM 解释器上，EVM 执行改进预计达 2 倍，计算密集型场景影响更大。

（注：原文此处有图片，src 未提供）

（2）并行 EVM

并行 EVM 允许同时处理多个交易，与传统串行模型不同。我们两条路径：

• 历史同步
  ：分析历史交易与状态冲突，计算最佳并行调度。

• 实时同步
  ：使用类似 Block STM 的技术推测执行，无需额外信息（如访问列表）。算法在状态竞争严重时性能较差，因此会根据工作负载在串行与并行间切换，并静态预测存储 slot 以提高并行质量。

历史分析显示约 80% 的以太坊存储 slot 独立访问，并行可使 EVM 执行效率提升 5 倍。

（注：原文此处有图片，src 未提供）

（3）优化状态承诺

Reth 模型中，计算状态根独立于交易执行，允许使用标准 KV 存储。目前状态根需要 >75% 的端到端时间来密封（seal）区块，是重要优化领域。我们找到两个“轻松取胜”的途径（不做协议更改）：

• 完全并行化状态根
  ：现在只重新并行计算已更改账户的存储树，可进一步在后台完成存储根时并行计算帐户树。

• Pipelined 状态根
  ：执行过程中通知状态根服务所涉存储 slot 和账户，从磁盘预取中间 trie 节点。

此外，可偏离以太坊 L1 状态根规则探索以下路径：

• 更低频状态根计算：每 T 个区块计算一次，减少投入时间占比。
• 跟踪状态根：让状态根落后几个区块，不阻塞执行。
• 替换 RLP 编码器 & Keccak256：使用更快哈希函数（如 Blake3）。
• 更宽的 Trie：增加 N-arity 子节点以减少 IO。

需关注的问题：对轻客户端、L2、bridge、协处理器等协议的次级影响；能否同时优化 SNARK 证明与原生执行速度；最宽泛状态承诺对见证大小的效应。

2.2 Reth 的横向扩展路线图

2024 年将执行上述多项内容以实现 1GB gas 目标。但垂直扩展终有物理限制，一台机器无法处理全球计算需求。以下两条路径支持引入更多 box 扩展：

（1）多 Rollup Reth

当前 L2 堆栈需运行多个服务：L1 CL、L1 EL、L1→L2 派生函数（常与 L2 EL 绑定）、L2 EL。模块化很棒，但运行多个节点栈时复杂——想象运行 100 个 rollup 会怎样？Reth 将支持同步发布 rollup，将运行数千 rollup 的运营成本几乎降至零。已在执行扩展项目中开展工作，未来几周有更多进展。

（2）云原生 Reth

高性能排序器（Sequencer）在单链上需求高，单机无法满足。Reth 将支持云原生节点部署为服务栈，根据计算需求自动扩展，使用云对象存储实现持久存储（类似 NeonDB、CockroachDB、Amazon Aurora 的无服务器架构）。

3. 未来前景

我们计划逐步向所有 Reth 用户推出此路线图。使命是让所有人都能获取每秒 1GB gas 甚至更高的速度。优化测试将在 Reth AlphaNet 进行，希望开发者将 Reth 用作 SDK 构建高性能节点。

仍有一些问题未解：Reth 如何帮助提升整个 L2 生态性能？如何适当衡量优化可能产生的最坏情况？如何处理 L1 与 L2 之间的潜在分歧？虽然目前尚无全部答案，但前景光明的初步设想已足够推动努力，期待未来几个月结出硕果。