原文作者：Monad 联合创始人 Keone Hon
编译：Odaily 星球日报 Azuma
编者按：北京时间 3 月 26 日上午，Monad 联合创始人 Keone Hon 于个人 X 发布了一篇关于 Rollup 性能状况的深度长文。文中，Keone 详述了坎昆升级之后 Rollup 的理论 TPS 上限该如何计算，并解释了为何升级之后部分 Layer 2 （Base）的单笔交易费用仍高达数美元，此外 Keone 还概述了 Rollup 所面临的一些瓶颈限制以及潜在的改进方向。
以下为 Keone 的原文内容，由 Odaily 星球日报编译，为了方便读者阅读，译者在原文基础上做了一定补充。
最近市场上有一些关于 Rollup 执行瓶颈和 Gas 限制的讨论，这不仅涉及 Layer 1 ，也包括了 Layer 2 。我将在下文中讨论这些瓶颈问题。
数据可用性（DA）
随着 Blob 数据结构（EIP-4844）在坎昆升级中被引入，以太坊的数据可用性（DA）已得到了大幅改进，Layer 2 的数据同步交易已无需再与普通 Layer 1 交易在同一个费用市场中竞价。
当前，Blob 的容量状况大概是每个区块（12 秒）产出 3 个 125 kb 的 Blob，即每秒 31.25 kb，鉴于一笔交易的大小大概是 100 字节，这意味着所有 Rollup 的共享 TPS 大概是 300 左右。
当然了，这里有一些信息需要特别备注。
一是如果 Rollup 采用了更好的交易数据压缩技术，可缩减单笔交易大小的话，TPS 便可实现增长。
二是理论上 Rollup 除了可以采用 Blob 同步数据之外，还可继续采用 calldata 同步数据（即坎昆升级之前的旧方案），尽管这样做会带来额外的复杂性。
三是不同 ZK-rollup 发布状态的方式存在差异（尤其是 zkSync Era 和 Starknet），因此对于这些 Rollup 来说，计算方式及结果也会有所不同。
Rollup 的 gas 限制
最近，Base 由于其 gas 费用的激增而引发了较大关注，一笔普通的交易在该网络上的费用已上涨到了几美元。
为什么坎昆升级之后，Base 网络只降低了一段时间，现在又回到甚至超过了升级之前的水准呢？这是因为 Base 上的区块存在一个 gas 总额限制，该限制系通过其代码中的一个参数来执行。
Base 目前所采用的 gas 参数与 Optimism 相同，即每个 Layer 2 区块（2 秒）存在 500 万 gas 的总额限制，当该网络之上的需求（交易总数）超过供应（区块空间）之时，价格结算便会采取按需执行的机制，从而导致该网络 gas 的飙升。
为什么 Base 不去提高这一 gas 总额限制呢？或者换句话说，为什么 Rollup 需要设置一个 gas 总额限制呢？
除了前文提到的数据可用性存在 TPS 上限之外，这里其实还有另外两大原因，分别是执行吞吐量的瓶颈以及状态增长的隐患。
问题一：执行吞吐量的瓶颈
一般而言，EVM Rollup 运行的都是一个 fork 自 Geth 的 EVM，这意味着它们与 Geth 客户端有着相似的性能特征。
Geth 的客户端是单线程的（即一次只能处理一个任务），它使用了 LevelDB/PebbleDB 编码，在 merkle patricia trie（MPT）中存储其状态。这是一种通用数据库，使用着另一种树结构（LSM 树）作为底层在固态硬盘（SSD）上存储数据。
对于 Rollup 而言，“状态访问”（从 merkle trie 读取数值）和“状态更新”（在每个区块结束时更新 merkle trie）是执行过程中成本最高的环节。之所以如此，是因为从固态硬盘上单次读取的成本是 40-100 微秒，且由于 merkle trie 数据结构被嵌入到另一个数据结构（LSM 树）中，导致需要进行许多非必要的额外查找。
这个环节可以想象为在一个复杂的文件系统中查找特定文件的过程。你需要从根目录（trie 根节点）一直找到目标文件（叶节点）。在查找每个文件时，都需要查找数据库 LevelDB 中的特定键，而在 LevelDB 内部又必须通过另一个名为 LSM 树的数据结构来执行实际的数据存储操作，这样的过程造成了许多额外的查找步骤。这些额外的步骤让整个数据读取和更新变得相当慢且低效。
在 Monad 的设计中，我们通过 MonadDb 解决了这一问题。MonadDb 是一个自定义数据库，支持直接在磁盘上存储 merkle trie，避免了 LevelDb 的开销；支持异步 IO，允许多个读取并行处理；绕过了文件系统。
此外，Monad 采用的“乐观并行执行”（optimistic parallel execution）机制允许多笔交易并行进行，且能够从 MonadDb 中并行地提取其状态。
然而，Rollup 没有这些优化，因此在执行吞吐量上存在瓶颈。
需要注明的是，Erigon/Reth 客户端对于数据库的效率有过一定优化，且一些 Rollup 的客户端也是基于这些客户端构建的（比如 OP-Reth）。Erigon/Reth 使用了一种扁平的数据结构，这在一定程度上减少了读取时的查询成本；然而，它们并不支持异步读取或多线程处理。此外，每个区块之后都需要重新计算 merkle root，这也是一个相当缓慢的过程。
问题二：状态增长的隐患
与其他区块链一样，Rollup 也会限制它们的吞吐量，以防止其活动状态增长过快。
市场上存在的一个常见论点是，状态增长速度之所以令人担忧，是因为如果状态数据大幅增长，对固态硬盘（SSD）的设备需求也将不得不上调。然而，我认为这有点不准确，SSD 相对便宜（一个高质量的 2 TB SSD 大约也就 200 美元），而在近 10 年的历史中，以太坊的全状态“仅”有大约 200 GB。单纯从储存角度来看，仍有很大的增长空间。
更大的隐患其实在于，随着状态持续增长，查询指定状态片段的时间会变得更长。这是因为当前 merkle patricia trie 会在满足“节点只有一个子节点”的条件时使用“快捷方式”，这可减少 trie 的有效深度，从而加速查询过程，可如果 merkle trie 的状态越来越满，可用的“快捷方式”也就会越来越少。
综合而言，状态增长的隐患归根结底其实就是状态访问效率的问题，因此加速状态访问是使状态增长更具可持续性的关键。
为什么仅仅优化硬件并没有用？
Layer 2 目前仍处于相对中心化的状态，即网络仍依赖于单一的排序器来维护状态并产出区块。有人可能会问，那为什么不让排序器运行在具备极高 RAM（随机存取存储器）的硬件上，以便让所有状态都能存储于内存中呢？
这也有两个原因。
其一，这并不会解决以太坊主网所存在的数据可用性瓶颈问题，尽管就目前 Base 的情况来看，该网络 gas 的飙升并不是因为主网数据可用性能力不足而导致，但从长远来看这终将会成为限制 Rollup 的一大瓶颈。
其二则是去中心化的问题，尽管排序器仍处于高度中心化状况，但参与网络运行的其他角色也很重要，他们也需要能独立运行节点，重放相同的交易历史并维护相同的状态。
Layer 1 之上的原始交易数据和状态提交并不足以解开完整的状态。任何对完整状态存在访问需求的角色（例如商家、交易所或自动交易者）都应该运行一个完整的 Layer 2 节点来处理交易，并拥有一个最新的状态副本。
Rollups 仍属于区块链，而区块链之所以有趣，是因为它们能够通过共享的全球状态实现全球协调。对所有区块链而言，性能强大的软件是必要的，仅仅优化硬件并不足以解决问题。
社区互动
在 Keone 发完此文后，多个头部 Layer 2 项目的关键人员均在该动态下方进行了互动。
zkSync 联合创始人 Alex Gluchowski 针对文中“每个区块之后都需要重新计算 merkle root”的内容询问 Monad 在这方面有何不同？”
Keone 的回复是会有一种用于在每个区块后计算 merkle root 的优化算法。
Base 负责人 Jesse Pollak 亦借此解释了为何 Base 在坎昆升级之后 gas 费用不降反增，其表示 EIP-4844 已大幅降低了 Layer 1 层面的 DA 成本，gas 费用本该降低，但由于网络交易需求增长了 5 倍有余，且 Base 网络之上的区块存在 250 gas/s 的限制，需求大于供给使得 gas 费用出现了上涨。
