作者：Keone Hon，Monad 联合创始人

编译：Azuma，Odaily星球日报

编者按：北京时间 3 月 26 日上午，Monad 联合创始人 Keone Hon 于个人 X 发布了一篇关于 Rollup 性能状况的深度长文。文中，Keone 详细阐述了坎昆升级之后 Rollup 的理论 TPS 上限计算，并解释了为何升级之后部分 Layer2（Base）的单笔交易费用仍高达数美元，此外 Keone 还概述了 Rollup 所面临的一些瓶颈限制以及潜在的改进方向。

以下为Keone的译文内容，由Odaily星球日报编译，为了方便读者，译者在译文基础上做了一定的补充。

最近市场上有一些关于 Rollup 执行瓶颈和 Gas 限制的讨论，这不仅涉及 Layer1，也包括 Layer2。我将在下面中讨论这些瓶颈问题。

数据可用性（DA）

随着Blob数据结构（EIP-4844）在坎昆升级中的引入，以太坊的数据可用性（DA）已得到了大幅提升，Layer2的数据同步交易已不再需要与普通Layer1交易在同一个费用市场中进行竞价。

目前，Blob 的容量状况大概是每个区块（12 秒）总计 3 个 125kb 的 Blob，即每秒 31.25kb，由此笔交易的大小大概是 100 字节，这意味着 Rollup 的共享 TPS大概是300左右。

当然，这里有一些信息需要特别注意。

  • 一是如果 Rollup 采用了更好的交易压缩数据技术，可缩小单笔大小的话，TPS 交易将会面临增长。
  • 二是理论上Rollup除了可以采用Blob同步数据之外，外交部继续采用calldata同步数据（即坎昆升级之前的旧方案），尽管这样做会带来额外的复杂性。
  • 三是不同的ZK-rollup发布状态的方式存在差异（尤其是zkSync Era和Starknet），因此对于这些Rollup来说，计算方式及结果也有所不同。

Rollup 的 Gas 限制

最近，基地由于其天然气费用大幅上涨而引发了更大的关注，而该网络上的普通交易费用已上涨至几美元。

坎昆限制升级之后，基地网络只降低了一段时间，现在又回到甚至超过了升级之前的水平呢？这是因为基地上的区块存在为什么一个天然气国家，该限制系通过其代码中的一个参数来执行。

目前基地所采用的gas参数与Optimism相同，即每个Layer2区块（2秒）存在500万gas的南部限制，当该网络上方的需求（交易总数）超过供应（区块空间）之时，价格结算采取后续执行的机制，从而导致该网络燃气的高峰。

或者换句话说，为什么Rollup需要设置一个燃气限制呢？

除了前文提到的数据可用性存在TPS上限之外，这里其实还有另外的原因，分别是承载吞吐量的高峰以及状态增长的现状。

问题一：吞吐量的瓶颈

一般来说，EVM Rollup 运行的都是一个来自 Geth 的 EVM 的 fork，这意味着它们与 Geth 客户端具有类似的性能特征。

Geth 的客户端是单线程的（即一次只能处理一个任务），它使用了 LevelDB/PebbleDB 编码，在 merkle patricia trie（MPT）中存储其状态。这是一种通用数据库，使用着另一种树（LSM 树）作为架构在SSD硬盘（SSD）上存储数据。

对于 Rollup 而言，「状态访问」（从 merkle trie 读取数值）和「状态更新」（在区块结束时更新 merkle trie）是执行过程中成本的间隔。之所以如此，是因为从SSD硬盘上单次读取的时间为40-100微秒，且由于merkle trie数据结构被嵌入到另一个数据结构（LSM树）中，导致需要进行非必要的额外查找。

这个阶段可以想象为在一个复杂的文件系统中查找特定文件的过程。你需要从根目录（trie 根节点）一直找到目标文件（叶节点）。在查找每个文件时，都需要查找数据库 LevelDB 中的许多特定键，而在 LevelDB 内部又必须通过另一个名为 LSM 树的数据结构来执行实际的数据存储操作，这样的过程造成了额外的查找步骤。这些额外的步骤让整个数据读取和更新变得相当慢且低效率。

在 Monad 的设计中，我们通过 MonadDb 解决了这个问题。MonadDb 是一个自定义数据库，支持直接在磁盘上存储 merkle trie，避免了 LevelDb 的开销；支持异步 IO，允许多个读取疯子处理；¶读完了文件系统。

此外，Monad 采用的「乐观批量执行」（乐观并行执行）机制允许多笔交易任务进行，并且能够从 MonadDb 中支持地获取其状态。

然而，Rollup 没有这些优化，因此在吞吐量上存在瓶颈。

需要注意的是，Erigon/Reth 客户端对于数据库的效率有过一定的优化，并且一些 Rollup 的客户端也是基于这些客户端构建的（比如 OP-Reth）。Erigon/Reth 使用了一种纸张的数据结构上，这个编程减少了读取时的查询成本；然而，它们并不支持异步读取模板线程处理。另外，每次阻塞之后都需要重新计算merkle root，这也是一个相当缓慢的过程过程。

问题二：现状的肥胖

与其他区块限制链一样，汇总它们的货物，以防止其活动状态增长过快。

市场上存在的一个常见论点是，状态增长速度为何令人担忧，是因为如果状态数据大幅增长，对SSD硬盘（SSD）的设备需求也将不得不上调。不过，我认为这有点不准确， SSD相对便宜（一个高质量的2TB SSD大约大约200美元），而在近10年的历史中，以太坊的全状态「仅」大约有200 GB。简单从存储角度来看，相当于很大的增长空间。

更大的现状其实存在，随着状态持续增长，查询指定状态碎片的时间会变得更长。这是因为当前merkle patricia trie会在满足「节点只有一个子节点」的条件时使用「快捷方式」 ，这可以减少 trie 的有效深度，从而加速查询过程，可如果 merkle trie 的状态越来越满，可用的「快捷方式」也会越来越少。

综合来说，状态增长的回归根结到底其实就是状态访问效率的问题因此，加速状态访问是使状态增长越来越持续的关键。

为什么单纯优化硬件并没有用？

Layer2目前仍处于一个相对中心化的状态，即网络仍依赖于单一的排序器来维护会状态和总量区块。有人可能会问，那为什么不让排序器运行在拥有高达RAM（随机存取存储器） ）的硬件上，以便让所有状态存储在内存中呢？

这也有两个原因。

其一，这并不能解决以太坊主网所存在的数据可用性瓶颈问题，虽然就目前基地的情况来看，该网络燃气的峰值并不是因为主网数据可用性能力不足而导致的，但从长期来看这终将成为限制 Rollup 的一大障碍。

其第二个去中心化的问题，虽然排序器仍处于高度中心化状况，但参与网络运行的其他角色也很重要，他们也需要能独立运行节点，重放的交易历史并维护相同的状态。

Layer1之上的原始交易数据和状态提交并需解开完整的状态。任何对完整状态存在访问需求的角色（例如商家、交易所或自动交易者）都应该运行一个完整的Layer2节点来处理交易，并拥有一份最新的状态副本。

Rollups 仍然属于区块链，而区块链持续有趣，是因为它们能够通过共享的全球状态实现协调全球。对所有区块链而言，性能强大的软件是必要的，只是优化硬件并请求解决问题。

社区互动

在Keone发完此文后，多个头部Layer2项目的关键人员均在该动态下方进行了互动。

zkSync 联合创始人 Alex Gluchowski 针对文中「每个区块之后都需要重新计算 merkle root」的内容询问 Monad 在这方面有何不同？

Keone 的回复是会有一种用于在每个区块后计算 Merkle root 的优化算法。

坎昆升级之后，Rollups的性能瓶颈是什么？

Base负责人Jesse Pollak亦解释了为何Base在坎昆升级之后gas费用不降反增，其表示EIP-4844已大幅降低了Layer1厚度的DA成本，gas费用本该降低，但由于网络交易需求增长了5倍有余，且基础网络之上的区块存在250gas/s的限制，需求增大使得gas费用出现了增长。