特别感谢 Georgios Konstantopoulos、Karl Floersch 和 Starkware 团队的反馈和审查。
在 Layer 2 扩容讨论中经常再度浮现的一个话题是 “Layer 3” 的概念。如果我们可以构建一个Layer 2 协议锚定到 Layer 1，以实现其安全性以及增加其可扩展性为主要目的，那么我们当然可以通过构建一个“锚定到 Layer 2 以实现安全性，并在其之上增加更多可扩展性”的 Layer 3 协议来扩大其规模?
这个想法的一个简单版本是：如果你有一个方案，可以让你实现二次方增长，你能把这个方案堆迭在其自身之上并获得指数级增长吗？类似的想法包括我2015 年的可扩展性论文以及在Plasma 论文中提到的的 multi-layer 扩展等。不幸的是，如此简单的 Layer 3 概念却没那么容易形成可行方案。由于数据可用性的限制、对紧急提取的 Layer 1 带宽的依赖或许多其他问题，设计中总有一些东西是不可堆迭的，并且只能给你一次可扩展性的提升。
围绕 Layer 3 的较新想法，如Starkware 提出的框架，更加复杂：它们不仅仅是将相同的东西堆迭在自身之上，它们还为 Layer 2 和 Layer 3 分配了不同的用途。如果它以正确的方式完成，这种方法的潜在形式可能行得通 。这篇文章将详细介绍在三层架构中哪些可能有意义，哪些可能没有意义。
为什么你不能通过在 Rollups 之上堆叠 Rollups 来不断扩容？
Rollups 是一种扩展技术，它结合了不同的技术来解决运行区块链的两个主要扩展瓶颈：计算和数据。计算已由“欺诈证明”或SNARK等方式解决了，它们依赖于极少数参与者来处理和验证每个块，要求其他人只执行少量计算来检查证明过程是否正确完成。这些方案，尤其是 SNARK，几乎可以无限制地扩展；我们可以继续制作“许多 SNARK 的 SNARK”，以将更多计算缩减为单个证明。
数据不一样。Rollups 使用一系列压缩技巧来减少交易需要在链上存储的数据量：简单的货币转账从 约100 字节减少到 约16 字节，在 EVM 兼容链中的 ERC20 转账从约180 字节减少到 约23 个字节，一个保护隐私的 ZK-SNARK 交易可以从 约600 字节压缩到 约80 个字节。在所有情况下大约有 8 倍压缩。但是 Rollup 仍然需要在保证用户能够访问和验证的介质中使数据在链上可用，以便用户可以独立计算 Rollup 的状态，并在现有证明者离线时作为证明者加入。数据可以压缩一次，但不能再次压缩 - - - 如果可以，那么通常有一种方法可以将第二个压缩器的逻辑放入第一个压缩器中，并通过压缩一次获得相同的好处。因此，“在 Rollups 之上的 Rollups ”实际上并不能在可扩展性方面提供巨大的收益，但是，正如我们将在下面看到的，这种模式可以用于其他目的。
那么 Layer 3 的 “sane” 版本是什么？
好吧，让我们看看 Starkware 在他们关于 Layer 3 的帖子中所提倡的有什么。Starkware 由非常聪明的密码学家组建，他们是理智的，所以如果他们提倡 layer 3s，他们的版本将比“如果 Rollups 压缩数据 8 倍，那么显然 Rollups 之上的 Rollups 将压缩数据 64 倍”要复杂得多。
这是 Starkware 帖子中的图：
引用几句：
上图描绘了这种生态系统的一个示例。它的 L3 包括：
1、具有 Validium 数据可用性的 StarkNet，如，常用于对定价极其敏感的应用程序中。
2、为获得更好的应用程序性能而定制的特定于应用程序的 StarkNet 系统，例如，通过采用指定的存储结构或数据可用性压缩来实现。
3、StarkEx 系统（例如服务于 dYdX、Sorare、Immutable 和 DeversiFi 的系统）具有 Validium 或 Rollup 数据可用性，立即为 StarkNet 带来久经考验的可扩展性优势。
4、隐私 StarkNet 实例（在此示例中也作为 L4）允许隐私保护类型的交易存在，而不将它们包含在公共 StarkNet 中。
我们可以将文章压缩为“L3”的三个愿景：
-
L2 用于扩容，L3 用于定制功能，例如隐私。在这个愿景中，没有尝试提供“可扩展性二次方增长”；相反，堆栈中有一层可以帮助应用程序扩展，然后有独立的层来满足不同用例的定制功能需求。
-
L2 用于通用扩容，L3 用于可定制化扩容。可定制化扩容可能有不同的形式：使用除 EVM 之外的其他东西进行计算的专用应用程序，数据压缩针对特定应用程序的数据格式进行优化的rollups（包括每个块中将“数据”与“证明”分开，并用单个SNARK替换证明）等。
-
L2 用于无信任扩展（Rollups），L3 用于弱信任扩展（Validiums）。Validium是使用 SNARK 来验证计算的系统，但将数据可用性留给受信任的第三方或委员会。在我看来，Validium 被严重低估了：特别是，许多“企业区块链”应用程序实际上可能最好由运行 validium 的证明者提供服务，并定期将哈希提交到链的集中式服务器来提供最佳服务。Validium 的安全等级低于rollups，但可以便宜得多。
在我看来，所有这三个愿景基本上都是合理的。专用数据压缩需要自己的平台的想法可能是最薄弱的主张 - - - 设计具有通用基础层压缩方案的 L2 非常容易，用户可以使用特定于应用程序的子压缩器自动扩展，但除此之外，这些使用案例都是合理的。但这仍然留下一个大问题：三层结构是实现这些目标的正确方法吗？将验证、隐私系统和定制环境锚定到 L2 而不是仅仅锚定到 L1 有什么意义？事实证明，这个问题的答案相当复杂。
在 L2 的子集树中，存款和取款是否变得更便宜、更容易？
三层模型优于两层模型的一个可能论点是：三层模型允许整个子生态系统存在于单个rollup中，这允许该生态系统内的跨域操作可以非常便宜地发生，而无需通过昂贵的L1完成。
但事实证明，即使在两个L2s 甚至L3s之间，存款与取款也可以非常便宜。这其中的关键是代币和其他资产不必在根链中发行。也就是说，您可以在 Arbitrum 上拥有 ERC20 代币，在 Optimism 上创建它的包装器，并在两者之间来回移动而无需任何 L1 交易！
让我们来看看这样一个系统是如何工作的。有两种智能合约：Arbitrum 上的基础合约和 Optimism 上的封装代币合约。要从 Arbitrum 转移到 Optimism，您需要将代币发送到基础合约，这将生成收据。一旦 Arbitrum 最终确定，您可以获取该收据的 Merkle 证明并植根于 L1 状态，然后将其发送到 Optimism 上的包装代币合约中，该合约对其进行验证并向您发放一个包装代币。要将令牌移回，您可以反向执行相同的操作。
尽管在证明 Arbitrum 上的存款所需的 Merkle 路径要通过 L1 状态，Optimism 只需要读取 L1 状态根来处理存款 - - - 不需要 L1 交易。请注意，由于rollups数据是最稀缺的资源，因此这种方案的实际实现将使用 SNARK 或 KZG 证明，而不是直接使用 Merkle 证明，以节省空间。
与基于 L1 的代币相比，这种方案有一个致命弱点（至少在optimistic rullups上是这样）：存款还需要等待防欺诈窗口。如果代币植根于 L1，从 Arbitrum 或 Optimism 撤回到 L1 需要一周的延迟，但存款是即时的。然而，在这个方案中，存款和取款都需要一周的延迟。也就是说，尚不清楚理想的rollups上的三层架构是否更好：要确保在本身运行在防欺诈游戏上的系统内部发生的防欺诈游戏是安全的，存在很多技术复杂性。
幸运的是，这些问题都不会成为 ZK Rollups的问题。出于安全原因，ZK Rollups 不需要长达一周的等待窗口，但由于其他两个原因，它们仍然需要更短的窗口（第一代技术可能需要 12 小时）。首先，特别是更复杂的通用 ZK-EVM Rollups 需要更长的时间来覆盖区块的不可并行（non-parallelizable）计算时间。其次，出于经济考虑，需要很少提交证明以最小化与证明交易相关的固定成本。包括专用硬件在内的下一代ZK-EVM 技术将解决第一个问题，而架构更好的批量验证可以解决第二个问题。我们接下来要讨论的正是优化和批量提交证明的问题。
Rollups 和 Validiums 有一个确认时间与固定成本的权衡。L3 可以帮助解决这个问题，但还有什么也可以做到这些呢？
每个事务的 Rollups 成本很便宜：它只是 16-60 字节的数据，具体取决于应用程序。但是 Rollups 每次提交一批交易到链上时也必须支付高昂的固定成本：Optimistic Rollups 每批需要21000 L1 gas，ZK Rollups 则超过 400,000 Gas（如果你想只用 STARKS 提供量子安全的东西，则需要数百万 Gas）。
当然，Rollup 可以简单地选择等到有 1000 万 Gas 价值的 L2 交易来提交整批(交易)，但这会给他们带来非常长的批次间隔，迫使用户等待更长的时间以获得高安全性确认。因此，它们需要权衡：较长的批次间隔和最佳成本，或者较短的批次间隔和大大增加的成本。
为了给我们一些具体的数字，让我们考虑一个每批成本为 600,000 Gas ZK Rollup 并处理每笔交易成本为 368 Gas 的完全优化的 ERC20 传输（23 字节）。假设此 Rollups 处于采用的早期到中期，TPS 为 5。我们可以计算每笔交易与批次间隔的gas：
如果我们进入一个拥有大量定制验证和特定应用环境的世界，那么其中许多每秒处理量将远低于 5TPS。因此，确认时间和成本之间的权衡开始变得非常重要。事实上，“L3”范式确实解决了这个问题！ZK Rollup 中的 ZK Rollup，即使是简单的实现，也只有大约 8,000 Layer-1 Gas 的固定成本（500 字节用于证明）。这会将上表更改为：
问题基本解决了，所以 L3 是不是很好？也许是的。但需要注意的是，解决这一问题还有一个方法受到了ERC4337聚合验证的启发。
策略如下。今天，如果每个 ZK Rollup 或 Validium 收到证明，则证明Snew= STF(Sold,D): 新的 state root 必须是在旧状态根之上正确处理交易数据或状态增量的结果。在这个新方案中，ZK Rollup 将接受来自批量验证者合约的消息，该消息说它已经验证了一批语句的证明，其中每个语句的形式为Snew = STF(Sold,D)。这种批量证明可以通过递归 SNARK 方案或Halo聚合来构建。
这将是一个开放的协议：任何 ZK-Rollup 都可以加入，并且任何批量证明者都可以从任何兼容的 ZK-Rollup 聚合证明，并从聚合器获得交易费用的补偿。批处理程序合约将验证一次证明，然后将一条消息传递给每个 Rollup, 并带有该sollups的(Sold,Snew,D)triple.Triple 来自批处理程序合同的事实会被作为证据来证明转换是有效的。
如果优化得当，此方案中每次汇总的成本可能接近 8000，其中 5000 用于添加新更新的状态写入，1280 用于旧根和新根，以及额外的 1720 用于杂项数据处理。因此，它会给我们同样的节省。Starkware 实际上已经有了类似的东西，称为SHARP，尽管它（还）不是一个无需许可的开放协议。
对这种方法的一种回应可能是：但这实际上不正是另一种第 3 层方案吗？我们将有base layer <- batch mechanism <- rollup或validium来替代base layer <- rollup <- validium。从某种哲学架构的角度来看，这可能是真的。但是有一个重要的区别：中间层不是一个复杂的完整 EVM 系统，而是一个简化的和高度专业化的对象，因此它更可能是安全的，它更有可能在没有另一个专门的代币的情况下构建，它更有可能被最低限度的治理，并且不会随着时间的推移而改变。
结论：到底什么是“Layer”？
由在其自身之上堆迭相同的缩放方案组成的三层缩放架构通常不能很好地工作。在 Rollups 之上的 Rollups（其中两层 Rollups 使用相同的技术）的形式也不尽人意。但是，L2 和 L3 具有不同目的的三层架构可以行得通。Rollups 之上的 Validiums 确实有意义，即使它们不能确定是长期的最佳做事方式。
然而，一旦我们开始深入了解哪种架构有意义的细节，我们就会进入哲学问题：什么是“层”，什么不是？base layer <- batch mechanism <- rollup 或 validium和base layer <- rollup <- rollup or validium做着相同的工作，但就其工作方式而言，证明聚合层看起来更像 ERC-4337，而不是rollups。通常，我们不会将 ERC-4337 称为“layer 2”。同样，我们不会将 Tornado Cash 称为 “Layer 2”，因此，如果我们要保持一致，我们不会将位于第L2之上的以隐私为中心的子系统称为L3. 因此，关于什么应该首先被称为“Layer”，存在一个未解决的语义争论。
在这方面有许多可能的思想流派。我个人的偏好是将术语“Layer 2”限制为具有以下属性的事物：
1、他们的目的是提高可扩展性
2、他们遵循“区块链中的区块链”模式：他们有自己的交易处理机制和自己的内部状态
3、他们继承了以太坊链的全部安全性
因此，理想的 Rollups 和 ZK Rollups 是 L2，但验证、证明聚合方案、ERC 4337、链上隐私系统和 Solidity 是另一回事。将其中一些称为 L3 可能有意义，但可能不是全部；无论如何，现在确定定义似乎还为时过早，而多汇总生态系统的架构远非一成不变，大多数讨论仅在理论上进行。
也就是说，语言上的争论不如哪个结构实际上最有意义的技术问题重要。显然，服务于隐私等非扩展需求的某些“Layers”可以发挥重要作用，并且需要以某种方式填充证明聚合的重要功能，最好是通过开放协议来填充。但与此同时，我们有充分的技术理由使链接面向用户环境和 L1 的中间层尽可能简单；在许多情况下，作为 EVM 汇总的“粘合层”可能不是正确的方法。我猜想，随着 L2 扩展生态系统的成熟，本文中描述的更复杂（和更简单）的结构将开始发挥更大的作用。
原文链接：
https://vitalik.ca/general/2022/09/17/layer_3.html
