Monad 联创:坎昆之后,Rollup 的性能瓶颈是什么?

IP归属:广东

撰文: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限制

最近,Base 由于其gas费用的激增而引发了较大关注,一笔普通的交易在该网络上的费用已上涨到了几美元。

为什么坎昆升级之后,Base 网络只降低了一段时间,现在又回到甚至超过了升级之前的水准呢?这是因为Base上的区块存在一个 gas 总额限制,该限制系通过其代码中的一个参数来执行。

Base目前所采用的 gas 参数与Optimism相同,即每个 Layer2 区块(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 相对便宜(一个高质量的 2TB SSD 大约也就 200 美元),而在近 10 年的历史中,以太坊的全状态「仅」有大约 200 GB。单纯从储存角度来看,仍有很大的增长空间。

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

综合而言,状态增长的隐患归根结底其实就是状态访问效率的问题,因此加速状态访问是使状态增长更具可持续性的关键。

为什么仅仅优化硬件并没有用?

Layer2 目前仍处于相对中心化的状态,即网络仍依赖于单一的排序器来维护状态并产出区块。有人可能会问,那为什么不让排序器运行在具备极高 RAM(随机存取存储器)的硬件上,以便让所有状态都能存储于内存中呢?

这也有两个原因。

其一,这并不会解决以太坊主网所存在的数据可用性瓶颈问题,尽管就目前 Base 的情况来看,该网络 gas 的飙升并不是因为主网数据可用性能力不足而导致,但从长远来看这终将会成为限制 Rollup 的一大瓶颈。

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

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

Rollups 仍属于区块链,而区块链之所以有趣,是因为它们能够通过共享的全球状态实现全球协调。对所有区块链而言,性能强大的软件是必要的,仅仅优化硬件并不足以解决问题。

社区互动

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

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

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

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

本文来源:陀螺科技 文章作者:Odaily星球日报
收藏
举报
Odaily星球日报
累计发布内容268篇 累计总热度10万+

陀螺科技现已开放专栏入驻,详情请见入驻指南: https://www.tuoluo.cn/article/detail-27547.html

Odaily星球日报专栏: https://www.tuoluo.cn/columns/author118261/

本文网址: https://www.tuoluo.cn/article/detail-10111909.html

免责声明:
1、本文版权归原作者所有,仅代表作者本人观点,不代表陀螺科技观点或立场。
2、如发现文章、图片等侵权行为,侵权责任将由作者本人承担。

相关文章