作者：Georgios Konstantopoulos，Paradigm研究合伙人&CTO；翻译：xiaozou 我们于2022年开始构建Reth，为以太坊L1提供弹性的同时解决L2上的执行层扩展问题。 今天，我们很高兴与大家分享2024年Reth计划如何实现L2每秒1GB gas吞吐量的，以及我们如何超越这一目标的长期路线图。 我们邀请整个生态系统与我们一起，共同推动加密领域的性能前沿和严格的基准测试。 1、我们是否已实现规模化扩展？ 加密货币要想达到全球规模，避免投机行为（成为主要用例），有一个非常简单的途径：交易一定要低价且快速。 1.1 如何衡量性能？每秒gas量指的是什么？ 性能通常以“每秒交易数”（TPS）来衡量。特别是对于以太坊和其他EVM区块链而言，一个更微妙、也许更准确的衡量标准就是“每秒gas量”。该指标反映了网络每秒可以处理的计算工作量，其中“gas”是衡量执行交易或智能合约等操作所需的计算工作量的单位。 将每秒gas量作为性能指标进行标准化，可以更清楚地了解区块链的容量和效率。它还有助于评估系统的成本影响，防止潜在的拒绝服务（DOS）攻击，这些攻击可能会利用不太精细的测量方法。该指标有助于比较不同以太坊虚拟机（EVM）兼容链的性能。 我们建议EVM社区采用每秒gas量作为标准指标，同时结合其他gas定价维度来创建一个综合的性能标准。 1.2 我们如今的发展阶段 每秒gas量是通过将各区块的目标gas使用量除以区块时间来确定的。下表，我们展示了不同EVM链L1和L2的当前每秒gas吞吐量和延迟（并不详尽）： 我们强调每秒gas量，用其来全面评估EVM网络性能，同时捕获计算和存储成本。Solana、Sui或Aptos等网络由于其独特的成本模式而不包括在内。我们鼓励努力协调所有区块链网络的成本模型，以实现全面和公平的比较。 我们正在为Reth开发一套无间断基准测试工具，以复制真实的工作负载。我们对节点的要求是符合TPC基准。 2、Reth如何达到每秒1GB gas？甚至更高？ 我们2022年创建Reth的动机有一部分是因为我们迫切需要一个专为web rollup而构建的客户端。我们认为我们的前进道路充满希望。 在实时同步期间，Reth已经达到每秒100-200MB gas（包括发送方恢复，执行交易和计算各区块的trie）；所以，要实现我们每秒1GB gas的短期目标，需要再扩展10倍。 随着Reth的发展，我们的扩展计划必须在可扩展性和效率之间寻找平衡： 垂直扩展：我们的目标是最大限度地利用每个“box”，充分发挥其潜力。通过优化各单个系统处理交易和数据的方式，我们可以极大提高整体性能，同时也使各节点运营商的效率更高。 水平扩展：尽管进行了优化，但web规模的绝对交易量超过了任何一台服务器的处理容量。要应对这种情况，我们考虑部署一个水平扩展架构，这个架构类似于区块链节点的Kubernetes模型。这意味着跨多系统分散工作负载，以确保没有哪一个节点可以成为瓶颈。 我们在这里探讨的优化不会涉及状态增长解决方案，这部分内容是我们将在其他文章单独探讨的。下面是我们实现这一目标的计划概况： 在整个技术栈中，我们还使用actor模型对IO和CPU进行了优化，支持堆栈的各部分都可以作为一项服务而部署，并对其运用进行精细控制。最后，我们正在积极评估备选数据库，但尚未确定。 2.1 Reth的垂直扩展路线图 我们垂直扩展的目标是最大化运行Reth的服务器或笔记本电脑的性能和效率。 （1）即使（Just-In-Time）EVM和提前（Ahead-of-Time）EVM 在像以太坊虚拟机(EVM)这样的区块链环境中，字节码的执行通过解释器（interpreter）进行，解释器按顺序处理指令。这种方法会带来一定开销，因为并不是直接执行原生汇编指令，而是通过VM层进行的操作。 即时（JIT）编译通过在执行前将字节码转换为原生机器码来解决这个问题，从而通过绕过VM的解释过程来提高性能。这种技术可以提前将合约编译成优化后的机器码，在Java和WebAssembly等其他虚拟机中已经得到了很好的应用。 但是，JIT可能容易遭受恶意代码攻击，恶意代码旨在利用JIT进程漏洞，或者在执行期间因速度太慢而无法实时运行。Reth将提前（AOT）编译需求最高的合约并将它们存储在磁盘上，避免在实时执行期间有不受信字节码试图滥用我们的原生代码编译过程。 我们一直在为Revm开发JIT/AOT编译器，目前正在与Reth集成。我们将在未来几周在完成基准测试后立即将其开源。平均而言，大约50%的执行时间花在了EVM解释器上，因此应该需要约2倍的EVM执行改进，但在一些计算需求更大的情况下，影响可能会更大。在接下来的几周内，我们将在Reth中分享我们的基准测试并集成我们自己的JIT EVM。 （2）并行EVM 并行以太坊虚拟机（Parallel EVM）的概念支持同时处理多个交易，与传统的EVM串行执行模型不同。我们有以下两条路径： 历史同步：历史同步可以让我们通过分析历史交易和识别所有历史状态冲突来计算可能的最佳并行调度。 实时同步：针对实时同步，我们可以使用类似Block STM的技术来推测执行，而不需要任何额外信息（如访问列表）。该算法在状态竞争严重期间性能较差，因此我们希望根据工作负载状况来探索串行和并行执行之间的切换，以及静态预测将访问哪些存储slot以提高并行质量。 根据我们的历史分析，大约有80%的以太坊存储slot是独立访问的，这意味着并行可以使EVM执行效率提高5倍。 （3）优化状态承诺 在Reth模型中，计算状态根是一个独立于执行交易的过程，允许使用无需获取trie信息的标准KV存储。这目前需要>75%的端到端时间来密封（seal）一个区块，这是一个非常令人兴奋的优化领域。 我们确定了以下两个“轻松取胜”的途径，可以在不做任何协议更改的情况下将状态根性能提高2-3倍： 完全并行化状态根：现在我们只重新并行计算已更改帐户的存储树，但是我们可以更进一步，当存储根作业在后台完成时并行计算帐户树。 Pipelined状态根：在执行过程中，通过通知状态根服务所涉存储slot和帐户，从磁盘预取中间trie节点。 除此之外，我们还可以偏离以太坊L1状态根活动探索一些前进路径： 更低频的状态根计算：不在每个区块上计算状态根，而是每T个区块计算一次。这减少了整个系统中投入状态根的总时间占比，这可能是最简单最有效的解决方案。 跟踪状态根：与其在同一个区块上计算状态根，不如让它落后几个区块。这样就可以在不阻塞状态根计算的情况下推进执行。 替换RLP编码器& Keccak256：相比使用RLP编码，直接合并字节并使用更快的哈希函数（如Blake3）可能成本更低。 更宽的Trie：增加树的N-arity子节点，以减少由于trie的logN深度而导致的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 高性能排序器可能在单个链上有很多需求，它们需要扩展，一台机器并不能满足其需求。这在如今的单节点部署的情况下是不可能的。 我们希望可以支持运行云原生Reth节点，将其作为一个服务栈部署，可以根据计算需求自动扩展，并使用看似无限的云对象存储来实现持久存储。这是无服务器数据库项目（如NeonDB、CockroachDB或Amazon Aurora）中常见的架构。 3、未来前景 我们希望逐步向所有Reth用户推出这一路线图。我们的使命是让所有人都能获取每秒1GB gas甚至更高的速度。我们将在Reth AlphaNet上进行优化测试，我们希望人们将Reth用作SDK来构建优化的高性能节点。 有些问题我们还没有找到答案。 Reth如何帮助提高整个L2生态的性能？ 我们如何适当衡量在一般情况下，我们的一些优化可能出现的最坏情况？ 我们如何处理L1和L2之间的潜在分歧？ 这些问题中很多我们都还没有答案，但我们有很多前景光明的最初设想，可足够让我们忙上一段时间了，我们希望看到这些努力在未来几个月结出硕果。