内容

1. 我们已经实现规模化扩展了吗？
   1. 如何衡量性能？每秒Gas量是指什么？
   2. 我们如今处于哪个发展阶段？
2. Reth 如何达到每秒 1 GB Gas？甚至更高？
   1. Reth的纵向扩展路线图
      1. 即时（Just-In-Time）EVM 和提前（Ahead-of-Time）EVM
      2. 并行EVM
      3. 优化状态承诺
   2. Reth的横向扩展路线图
      1. 多Rollup Reth
      2. 云原生Reth
3. 展望未来

我们于 2022 年开始构建 Reth，为以太坊 L1 提供复原能力，并解决 L2 上的执行层扩展问题。

今天，我们很高兴与大家分享 Reth 在 2024 年如何实现 L2 每秒 1 GB Gas，以及我们超越这一目标的长期路线图。

我们邀请生态系统与我们合作，推动加密领域的性能和严格基准测试的前沿发展。

我们已经实现规模化扩展了吗？

加密货币要达到全球规模并避免投机成为主要用例，有一条非常简单的途径，即让交易变得便宜且快速。

如何衡量性能？每秒Gas量是指什么？

性能通常通过“每秒事务数”(TPS) 指标来衡量。特别是对于以太坊和其他 EVM 区块链来说，更细致、或许更准确的衡量标准是“每秒的 Gas 量”。该指标反映了网络每秒可以处理的计算工作量，其中“gas”是衡量执行交易或智能合约等操作所需的计算工作量的单位。

将每秒Gas量作为性能指标进行标准化可以让我们更清楚地了解区块链的容量和效率。它还有助于评估对系统的成本影响，防止可能利用不太细致的测量的潜在拒绝服务 (DOS) 攻击。该指标有助于比较不同以太坊虚拟机（EVM）兼容链的性能。

我们建议 EVM 社区采用每秒 Gas 作为标准指标，同时纳入Gas定价的其他方面，制定综合性能标准。

我们如今处于哪个发展阶段？

每秒的 Gas 量是通过将每个区块的目标 Gas 使用量除以区块时间来确定的。在这里，我们展示了各种 EVM 链 L1 和 L2 的当前每秒 Gas 吞吐量和延迟（并非详尽无遗）：

我们强调每秒 Gas 来全面评估 EVM 网络性能，捕获计算和存储成本。 Solana、Sui 或 Aptos 等网络由于其独特的成本模型而未包括在内。我们鼓励努力协调所有区块链网络的成本模型，以实现全面和公平的比较。

我们正在开发一个用于 Reth 复制真实工作负载的连续基准测试套件，如果您想就此进行合作，请联系我们。我们需要一个用于节点的TPC 基准。

Reth 如何达到每秒 1 GB Gas？甚至更高？

2022年，我们构建 Reth 的部分出于迫切需要专门为网络规模的汇总构建客户端的原因。我们认为我们的前进道路充满希望。

Reth 在实时同步期间已达到 100-200mgas/s（包括发送方恢复、执行交易以及计算每个块上的 trie）；所以，需要再扩展 10 倍才能实现我们每秒 1GB gas 的短期目标。

随着我们推进 Reth 的开发，我们的扩展计划必须在可扩展性与效率之间取得平衡：

• 纵向扩展： 我们的目标是最大限度地利用每个“盒子”的全部潜力。通过优化每个系统处理交易和数据的方式，我们可以大大提高整体性能，同时也使单个节点运营商更加高效。
• 横向扩展： 尽管进行了优化，但网络规模的交易量仍然超出了任何单个服务器的处理能力。为了解决这个问题，我们希望实现一个横向扩展的架构，类似于区块链节点的 Kubernetes 模型。这意味着将工作负载分散到多个系统上，以确保没有单个节点成为瓶颈。

我们在这里探索的优化不涉及解决状态增长，我们正在单独研究这一点。

以下是我们打算如何实现这一目标的总体计划：

在整个堆栈中，我们还使用参与者模型针对 IO 和 CPU 进行优化，以允许将堆栈的每个部分部署为服务，并对其利用率进行精细控制。最后，我们正在积极评估替代数据库，但尚未确定候选数据库。

Reth的纵向扩展路线图

我们的目标是最大限度地提高运行 Reth 的单个服务器或笔记本电脑的性能和效率。

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

在以太坊虚拟机（EVM）等区块链环境中，字节码执行通过解释器进行，解释器顺序处理指令。此方法会带来开销，因为它不直接执行本机汇编指令，而是通过 VM 层进行操作。

即时（JIT）编译通过在执行之前将字节码转换为本机机器代码来解决这个问题，从而绕过了虚拟机的解释过程，提高了性能。这种技术提前将合约编译成优化的机器代码，在 Java 和 WebAssembly 等其他虚拟机中得到了广泛应用。

然而，JIT 可能容易受到旨在利用 JIT 进程的恶意代码的攻击，或者可能在执行过程中速度太慢而无法实时运行。Reth 将提前（AOT）编译需求最高的合约并将其存储在磁盘上，以避免不受信任的字节码试图在实时执行期间滥用我们的本机代码编译步骤。

我们一直在为 Revm 开发 JIT/AOT 编译器，目前正在与 Reth 集成。完成基准测试后，我们将在未来几周内将其开源。平均大约 50% 的执行时间花在 EVM 解释器上，因此这应该会提供大约 2 倍的 EVM 执行优化，尽管在一些计算量较大的情况下，它可能会产生更大的影响。未来几周，我们将在 Reth 中分享我们自己的 JIT EVM 的基准测试和集成。

并行EVM

并行以太坊虚拟机（并行 EVM）的概念可以实现同步事务处理，这与 EVM 的传统串行执行模型不同。我们有两条实施道路：

1. 历史同步： 在历史同步中，我们可以通过分析过去的事务并识别所有历史状态冲突来计算最佳的并行化调度。请参阅我们在Github对旧分支中早期尝试。
2. 实时同步： 对于实时同步，我们可以使用类似于区块STM推测执行的技术，无需任何附加信息（如访问列表）。该算法在状态竞争严重时性能较差，因此我们希望根据工作负载的形状探索串行和并行执行之间的切换，以及静态预测将访问哪些存储槽以提高并行性的质量。查看此处由第 3 方团队提供的一个 PoC。

根据我们的历史分析，约 80% 的以太坊存储插槽是独立访问的，这意味着并行性可以使 EVM 执行速度提高高达5倍。

优化状态承诺

我们最近写了关于状态根对性能的影响以及 Reth 数据库模型与其他客户端之间的差异，以及它的重要性。

在Reth模型中，计算状态根是与执行交易不同的过程（查看我们的代码），允许使用标准 KV 存储，而无需了解有关 trie 的任何信息。目前，这需要>75%的端到端时间来密封一个区块，并且是一个非常令人期待的优化领域。

我们确定了以下 2 个“易于完成的任务”，它们可以使我们的状态根性能提高 2-3 倍，而无需更改任何协议：

1. 完全并行化状态根： 目前，我们仅并行重新计算已更改帐户的存储树，但我们可以更进一步，在存储根作业在后台完成时并行计算帐户树。
2. 管道状态根： 通过通知状态根服务有关所触及的存储插槽和帐户的信息，在执行期间从磁盘预取中间 trie 节点。

除此之外，我们还看到了一些与以太坊 L1 状态根行为不同的前进路径：

1. 更低频的状态根： 不是在每个块上计算状态根，而是每 T 个块计算一次。这减少了整个系统中状态根所花费的总时间百分比，并且可能是最简单且最有效的解决方案。
2. 尾随状态根： 不必在同一块计算状态根，而是让它落后几个块。这允许执行继续进行而不会阻塞状态根计算。
3. 替换 RLP 编码器和 Keccak256： 与使用 RLP 编码不同，直接连接字节并使用更快的哈希函数（如 Blake3）可能会更便宜。
4. 更宽的Trie： 增加树的 N-arity 子节点，以减少由于 trie 的 logN 深度而导致的 IO 增大。

这里有几个问题：

1. 上述变化对轻客户端、L2、桥、协处理器和其他依赖频繁帐户和存储证明的协议的次级影响是什么？
2. 我们能否同时优化 SNARK 证明和原声执行速度的状态承诺？
3. 利用我们现有的工具，我们可以获得的最宽的状态承诺是什么？见证人规模有哪些次级效应？

Reth的横向扩展路线图

我们将在 2024 年全年执行上述多项要点，并实现 1gigagas/秒的目标。

然而，纵向扩展最终会遇到物理和实际的限制。没有任何一台机器能够满足全世界的计算需求。我们认为这里有两条路可以让我们随着更多负载的到来而引入更多的“盒子”来进行扩展：

多Rollup Reth

如今的 L2 堆栈需要运行多个服务来遵循该链：L1 CL、L1 EL、L1 -> L2 派生函数（可能与 L2 EL 捆绑在一起）和 L2 EL。虽然这非常适合模块化，但在运行多个节点堆栈时这会变得复杂。想象一下必须运行 100 次汇总会怎样！

我们希望允许在与 Reth 相同的流程中启动汇总，并将运行数千个汇总的运营成本降低到几乎为零。

我们已经与我们执行扩展项目 ([1],[2]）一起着手进行这项工作，未来几周将有更多内容。

云原生Reth

高性能排序器可能对单个链有足够的需求，需要扩展到单个机器之外。这在当今的整体节点实现中是不可能的。

我们希望允许运行云原生 Reth 节点，将其部署为服务堆栈，可以根据计算需求自动扩展，并使用看似无限的云对象存储来实现持久性。这是 NeonDB、CockroachDB 或 Amazon Aurora 等无服务器数据库项目中的常见架构。

早起我们团队分享了关于解决这些问题的想法。

展望未来

我们打算逐步向所有 Reth 用户推出此路线图。我们的使命是让每个人都能享受 1 gigagas/s 及以上的访问速度。我们将在 Reth AlphaNet 上测试我们的优化，我们希望人们使用 Reth 作为 SDK 来构建优化后的高性能节点。

有些问题我们还没有找到答案。

• Reth 如何帮助提高整个 L2 生态系统的性能？
• 当我们的一些优化可能适用于平均情况时，我们如何适当地衡量最坏的情况？
• 我们如何应对 L1 和 L2 之间潜在的分歧状况？

对其中许多问题，我们都没有答案，但我们有足够多的有希望的线索，这能让我们探索一段时间，并希望在未来几个月看到这些努力能取得成果。

声明：

1. 本文转载自[paradigm]，著作权归属原作者[Georgios Konstantopoulos]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. 文章其他语言版本由Gate Learn团队翻译， 在未提及Gate.io的情况下不得复制、传播或抄袭经翻译文章。