【英文】通往 1 GB/s 之路：详解以太坊客户端 Reth 的扩展路线图

我们在 2022 年构建 Reth 的部分动机是迫切需要专门为网络规模的 Rollups 构建客户端。Reth 在实时同步期间已达到 100-200 mgas/s， 从这里开始 10 倍可以让我们达到 1 gigagas/s 的短期目标。随着 Reth 开发的推进，我们的扩展计划必须在可扩展性与效率之间取得平衡：1）垂直扩展：通过优化每个系统处理交易和数据的方式，我们可以大大提高整体性能；2）水平扩展：我们希望实现一个水平扩展的架构，类似于区块链节点的 Kubernetes 模型。这意味着将工作负载分散到多个系统上，以确保没有单个节点成为瓶颈。我们在这里探索的优化不涉及解决状态增长，我们正在单独研究。 Reth 的垂直扩展路线图：1）实时和提前 EVM：实时（JIT）编译通过在执行前将字节码转换为本机代码从而绕过 VM 的解释过程来提高性能。Reth 将提前（AOT）编译需求最高的合约并将其存储在磁盘上，以避免不受信任的字节码在实时执行过程中滥用本地代码编译步骤；2）并行 EVM：历史同步：在历史同步中，我们可以通过分析过去的事务并识别所有历史状态冲突，计算出最佳的并行化时间表。实时同步：我们可以使用类似于 Block STM 的技术来推测执行，而无需访问列表等任何额外信息；3）改进状态确认：以下两个方向能在不改变任何协议的情况下，将状态根性能提高 2-3 倍：完全并行化的状态根、管道化状态根。 Reth 的水平扩展路线图：我们认为这里有两条前进的道路：1）多重 Rollup Reth：我们希望在与 Reth 相同的过程中启动 Rollup，并将运行数千个 Rollup 的运营成本降至几乎为零；2）云原生 Reth：我们希望允许运行云原生 Reth 节点，将其部署为一个服务堆栈，可以根据计算需求自动扩展，并使用看似无限的云对象存储实现持久性。这是 NeonDB、CockroachDB 和 Amazon Aurora 等无服务器数据库项目的常见架构。【原文为英文】\n原文链接