Vitalik 新文:什么样的 layer 3 有意义?

Vitalik热度: 32780

三层结构是实现这些目标的正确方法吗?将验证、隐私系统和定制环境锚定到L2而不是仅仅锚定到L1有什么意义?事实证明,这个问题的答案相当复杂。

原文标题:What kind of layer 3s make sense?

原文作者:Vitalik

原文来源:Vitalik.ca

编译:MarsBit

特别感谢 Georgios Konstantopoulos、Karl Floersch 和 Starkware 团队的反馈和审查。

在layer 2扩展讨论中经常重新出现的一个主题是“layer 3”的概念。如果我们可以构建一个layer 2协议,该协议锚定到layer 1以实现安全性并在顶部增加可扩展性,那么我们当然可以通过构建一个锚定到layer 2以实现安全性并在其之上增加更多可扩展性的layer 3协议来实现扩展?

这个想法的一个简单版本是:如果你有一个可以给你二次扩展的方案,你能把这个方案堆叠在自身之上并获得指数级扩展吗?这样的想法包括我 2015 年的可扩展性论文Plasma 论文中的多层扩展想法等等。不幸的是,如此简单的layer 3概念很少能如此容易地解决。设计中总有一些东西是不可堆叠的,并且只能给你一次可扩展性的提升——数据可用性的限制、对紧急提取的 L1 带宽的依赖或许多其他问题。

围绕layer 3的较新想法,例如由 Starkware 提出的框架,更加复杂:它们不仅仅是将相同的东西堆叠在自身之上,它们为layer 2layer 3分配了不同的用途。如果它以正确的方式完成,这种方法的某种形式可能是一个好主意。这篇文章将详细介绍在三层架构中哪些可能有意义,哪些可能没有意义。

为什么你不能通过在Rollup之上堆叠Rollup来保持缩放

Rollup(请参阅我在此处的较长文章)是一种扩展技术,它结合了不同的技术来解决运行区块链的两个主要扩展瓶颈:计算和数据。计算由欺诈证明或SNARK 解决,它们依赖于极少数参与者来处理和验证每个块,要求其他人只执行少量计算来检查证明过程是否正确完成。这些方案,尤其是 SNARK,几乎可以无限制地扩展;您真的可以继续制作“许多 SNARK 的 SNARK”,以将更多计算缩减为单个证明。

数据不一样。Rollups 使用一系列压缩技巧来减少交易需要在链上存储的数据量:简单的货币转账从 ~100 字节减少到 ~16 字节,在 EVM 兼容链中的 ERC20 转账从 ~180 字节减少到 ~ 23 字节,并且可以将保护隐私的 ZK-SNARK 交易从约 600 字节压缩到约 80 字节。在所有情况下大约 8 倍压缩。但是 rollup 仍然需要在保证用户能够访问和验证的介质中使数据在链上可用,以便用户可以独立计算 rollup 的状态,并在现有证明者离线时作为证明者加入。数据可以压缩一次,但不能再次压缩 - 如果可以,那么通常有一种方法可以将第二个压缩器的逻辑放入第一个压缩器中,并通过压缩一次获得相同的好处。因此,“在rollup之上的rollup”实际上并不能在可扩展性方面提供巨大的收益——尽管,正如我们将在下面看到的,这种模式可以用于其他目的。

那么layer 3的“健全”版本是什么?

好吧,让我们看看 Starkware 在他们关于 layer 3s 的帖子中所提倡的。Starkware 由非常聪明的密码学家组成,他们实际上是理智的,所以如果他们提倡layer 3,他们的版本将比“如果 rollups 压缩数据 8 倍,那么显然rollups 之上的 rollups 将压缩数据 64倍”要复杂得多。 .

这是 Starkware 帖子中的图表:

交易

引用几句:

图 1 描绘了这种生态系统的一个示例。它的 L3 包括:
  • 具有 Validium 数据可用性的 StarkNet,例如,供对定价极其敏感的应用程序普遍使用。
  • 为获得更好的应用程序性能而定制的特定于应用程序的 StarkNet 系统,例如,通过采用指定的存储结构或数据可用性压缩。
  • StarkEx 系统(例如服务于 dYdX、Sorare、Immutable 和 DeversiFi 的系统)具有 Validium 或 Rollup 数据可用性,立即为 StarkNet 带来久经考验的可扩展性优势。
  • 隐私 StarkNet 实例(在此示例中也作为 L4)允许隐私保护交易而不将它们包含在公共 StarkNet 中。

我们可以将文章总结为“L3s”的三个愿景:

  1. L2 用于扩展,L3 用于定制功能,例如隐私。在这个愿景中,没有尝试提供“可扩展性平方”;相反,堆栈中有一层可以帮助应用程序扩展,然后根据不同用例的定制功能需求分离层。
  2. L2 用于通用扩展,L3 用于自定义扩展。自定义扩展可能有不同的形式:使用除 EVM 之外的其他东西进行计算的专用应用程序,其数据压缩针对特定应用程序的数据格式进行优化的rollup(包括将“数据”与“证明”分开,并用单个数据替换证明) SNARK 完全每个块)等。
  3. L2 用于无信任扩展(rollup),L3 用于弱信任扩展(验证)Validium是使用 SNARK 来验证计算的系统,但将数据可用性留给受信任的第三方或委员会。在我看来,Validium 被严重低估了:特别是,许多“企业区块链”应用程序实际上可能最好由运行 validium 证明者并定期将哈希提交到链的集中式服务器来提供最佳服务。Validium 的安全等级低于rollup,但可以便宜得多。

在我看来,所有这三个愿景基本上都是合理的。专用数据压缩需要自己的平台的想法可能是最薄弱的主张 - 设计具有通用基础层压缩方案的L2非常容易,用户可以使用特定于应用程序的子压缩器自动扩展 - 但是否则用例都是合理的。但这仍然留下一个大问题:三层结构是实现这些目标的正确方法吗?将验证、隐私系统和定制环境锚定到L2而不是仅仅锚定到L1有什么意义?事实证明,这个问题的答案相当复杂。


交易


哪一个实际上更好?

L2的子树中,存款和取款是否变得更便宜、更容易?

三层模型优于两层模型的一个可能论点是:三层模型允许整个子生态系统存在于单个rollup中,这允许该生态系统内的跨域操作非常便宜地发生,而无需需要通过昂贵的L1

但事实证明,即使在承诺同一层 1 的两个L2(甚至L3)之间,您也可以廉价地进行存款和取款!关键实现是代币和其他资产不必在根链中发行。也就是说,您可以在 Arbitrum 上拥有 ERC20 代币,在 Optimism 上创建它的包装器,并在两者之间来回移动而无需任何 L1 交易!

让我们来看看这样一个系统是如何工作的。有两种智能合约:Arbitrum 上的基础合约和 Optimism 上的封装代币合约。要从 Arbitrum 转移到 Optimism,您需要将代币发送到基础合约,这将生成收据。一旦 Arbitrum 最终确定,您可以获取该收据的 Merkle 证明,植根于 L1 状态,并将其发送到 Optimism 上的包装代币合约中,该合约对其进行验证并向您发放一个包装代币。要将令牌移回,您可以反向执行相同的操作。


交易

即使证明 Arbitrum 上的存款所需的 Merkle 路径通过 L1 状态,Optimism 只需要读取 L1 状态根来处理存款 - 不需要 L1 交易。请注意,由于rollup数据是最稀缺的资源,因此这种方案的实际实现将使用 SNARK 或 KZG 证明,而不是直接使用 Merkle 证明,以节省空间。

与基于 L1 的代币相比,这种方案有一个关键弱点,至少在Optimism rollups上是这样:存款还需要等待防欺诈窗口。如果代币植根于 L1,从 Arbitrum 或 Optimism 撤回到 L1 需要一周的延迟,但存款是即时的。然而,在这个方案中,存款和取款都需要一周的延迟。也就是说,尚不清楚Optimism rollups上的三层架构是否更好:要确保在本身运行在防欺诈游戏上的系统内部发生的防欺诈游戏是安全的,存在很多技术复杂性。

幸运的是,这些问题都不会成为 ZK rollup的问题。出于安全原因,ZK 汇总不需要长达一周的等待窗口,但由于其他两个原因,它们仍然需要更短的窗口(第一代技术可能需要 12 小时)。首先,尤其是更复杂的通用ZK-EVM rollup需要更长的时间来覆盖证明块的不可并行计算时间。其次,出于经济考虑,需要很少提交证明以最小化与证明交易相关的固定成本。包括专用硬件在内的下一代 ZK-EVM 技术将解决第一个问题,而架构更好的批量验证可以解决第二个问题。我们接下来要讨论的正是优化和批量提交证明的问题。

Rollups 和 validiums 有一个确认时间与固定成本的权衡。L3可以帮助解决这个问题。但还有什么可以?

每个事务的rollup成本很便宜:它只是 16-60 字节的数据,具体取决于应用程序。但是 rollups每次提交一批交易到链上时也必须支付高昂的固定成本:Optimism rollups每批 21000 L1 gas,ZK rollups 超过 400,000 gas(如果你想要量子安全的东西,需要数百万 gas仅使用 STARKs)。

当然,rollup 可以简单地选择等到有 1000 万个 gas 价值的 L2 交易来提交批次,但这会给他们带来非常长的批次间隔,迫使用户等待更长的时间,直到他们获得高安全性确认。因此,它们需要权衡:较长的批次间隔和最佳成本,或者较短的批次间隔和大大增加的成本。

为了给我们一些具体的数字,让我们考虑一个 ZK rollup,每批成本为 600,000 gas,并处理完全优化的 ERC20 传输(23 字节),每笔交易成本为 368 gas。假设此rollup处于采用的早期到中期,平均为 5 TPS。我们可以计算每笔交易与批次间隔的气体:

批处理间隔每笔交易的Gas费(= 交易成本 + 批次成本 /(TPS * 批次间隔))12 秒(每个以太坊区块一个)103681分钟236810 分钟5681小时401

如果我们进入一个拥有大量定制验证和特定应用环境的世界,那么其中许多的 TPS 将远低于 5。因此,确认时间和成本之间的权衡开始变得非常重要。事实上,“L3”范式确实解决了这个问题!ZK rollup 中的 ZK rollup,即使是幼稚的实现,也只有大约 8,000 layer-1 gas 的固定成本(500 字节用于证明)。这会将上表更改为:

批处理间隔每笔交易的Gas费(= 交易成本 + 批次成本 /(TPS * 批次间隔))12 秒(每个以太坊区块一个)5011分钟39410 分钟3701小时368

问题基本解决。那么L3好吗?也许。但值得注意的是,在ERC 4337 聚合验证的启发下,有一种不同的方法可以解决这个问题。

策略如下。今天,如果每个 ZK rollup 或 validium 收到证明的证明,它就会接受一个状态根:新的状态根必须是正确处理交易的结果旧状态根之上的数据或状态增量。在这个新方案中,ZK rollup 将接受来自批量验证者合约的消息,该消息表明它已经验证了一批语句的证明,其中每个语句的形式为。这种批量证明可以通过递归 SNARK 方案或Halo聚合来构建。


交易


这将是一个开放的协议:任何 ZK-rollup 都可以加入,并且任何批量证明者都可以从任何兼容的 ZK-rollup 聚合证明,并从聚合器获得交易费用的补偿。批处理程序合约将验证一次证明,然后将消息传递给每个rollup,并使用该rollup的三元组;三元组来自批处理程序合同的事实将证明转换是有效的。

如果优化得当,此方案中每次rollup的成本可能接近 8000:5000 用于添加新更新的状态写入,1280 用于旧根和新根,以及额外的 1720 用于杂项数据处理。因此,它会给我们同样的节省。Starkware 实际上已经有了类似的东西,称为SHARP,尽管它(还)不是一个无需许可的开放协议。

对这种方法的一种回应可能是:但这实际上不只是另一种L3方案吗?而不是base layer <- rollup <- validium,你有base layer <- batch mechanism <- rollup or validium。从某种哲学建筑的角度来看,这可能是真的。但是有一个重要的区别:中间层不是一个复杂的完整 EVM 系统,而是一个简化的和高度专业化的对象,因此它更可能是安全的,它更有可能在没有的情况下构建需要另一个专门的代币,它更有可能被治理最小化,并且不会随着时间的推移而改变。

结论:什么是“层”?

由在其自身之上堆叠相同的缩放方案组成的三层缩放架构通常不能很好地工作。在rollup之上的rollup,其中两层rollup使用相同的技术,当然不会。但是,L2L3具有不同目的的三层架构可以工作。rollups 之上的 Validiums 确实有意义,即使它们不能确定是长期的最佳做事方式。

然而,一旦我们开始深入了解哪种架构有意义的细节,我们就会进入哲学问题:什么是“层”,什么不是?base layer <- batch mechanism <- rollup or validium模式的作用与模式相同base layer <- rollup <- rollup or validium。但就其工作方式而言,证明聚合层看起来更像ERC-4337,而不是rollup。通常,我们不会将 ERC-4337 称为“L2”。同样,我们不会将 Tornado Cash 称为“L2”——因此,如果我们要保持一致,我们不会将位于第 2 层之上的以隐私为中心的子系统称为第 3 层. 因此,关于什么应该首先被称为“层”,存在一个未解决的语义争论。

在这方面有许多可能的思想流派。我个人的偏好是将术语“L2”限制为具有以下属性的事物:

  • 他们的目的是提高可扩展性
  • 他们遵循“区块链中的区块链”模式:他们有自己的交易处理机制和自己的内部状态
  • 他们继承了以太坊链的全部安全性

因此,Optimism rollups和 ZK rollupsL2,但验证、证明聚合方案、ERC 4337、链上隐私系统和 Solidity 是另一回事。将其中一些称为L3可能有意义,但可能不是全部;无论如何,现在确定定义似乎还为时过早,而多汇总生态系统的架构远非一成不变,大多数讨论仅在理论上进行。

也就是说,语言辩论不如哪个结构实际上最有意义的技术问题重要。显然,服务于隐私等非扩展需求的某种“层”可以发挥重要作用,并且显然需要以某种方式填充证明聚合的重要功能,最好是通过开放协议来填充。但与此同时,有充分的技术理由使将面向用户的环境连接到L1的中间层尽可能简单;在许多情况下,作为 EVM rollup的“粘合层”可能不是正确的方法。我怀疑随着L2扩展生态系统的成熟,本文中描述的更复杂(和更简单)的结构将开始发挥更大的作用。

责任编辑:Felix

声明:本文为入驻“MarsBit 专栏”作者作品,不代表MarsBit官方立场。
转载请联系网页底部:内容合作栏目,邮件进行授权。授权后转载时请注明出处、作者和本文链接。未经许可擅自转载本站文章,将追究相关法律责任,侵权必究。
提示:投资有风险,入市须谨慎,本资讯不作为投资理财建议。
免责声明:本文不构成投资建议,用户应考虑本文中的任何意见、观点或结论是否符合其特定状况,及遵守所在国家和地区的相关法律法规。