VitalikButerin：Layer3的三个愿景，什么样的Layer3是有意义的？

原文：Vitalik Buterin，由 DeFi 之道翻译编辑。

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

在第 2 层（L2）扩展讨论中经常反复出现的一个主题是“第 3 层”（L3）的概念。如果我们可以构建一个 L2 协议，该协议锚定到 L1 以实现安全性并在顶部增加可扩展性，那么我们当然可以通过构建一个 L3 协议来进一步扩展，该协议锚定到 L2 以实现安全性并在顶部增加更多可扩展性？

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

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

为什么你不能通过在 rollup 之上堆叠 rollup 来保持扩展

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

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

那么 L3 的“健全”版本是什么？

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

这是 Starkware 帖子中的图表：

引用几点：

图 1 描绘了这种生态系统的一个示例。它的 L3 包括：

我们可以将这篇文章的要点提炼为“L3”的三个愿景：

1. L2 用于扩展，L3 用于定制功能，例如隐私。在这个愿景中，没有尝试提供“二次方级可扩展性”；相反，这个堆栈中有一层可以帮助应用程序扩展，然后根据不同用例的定制功能需求分离各层。

2. L2 用于通用扩展，L3 用于自定义扩展。自定义扩展可能有不同的形式：使用除 EVM 之外的其他东西进行计算的专用应用程序，其数据压缩针对特定应用程序的数据格式进行优化的 rollup（包括将“数据”与“证明”分开，并用每个区块的单个 SNARK 完全替换证明）等。

3. L2 用于无信任扩展（rollup），L3 用于弱信任扩展（validium）。Validium 是使用 SNARK 来验证计算的系统，但将数据可用性留给受信任的第三方或委员会。在我看来，Validium 被严重低估了：特别是，许多“企业区块链”应用程序实际上可能最好由运行 validium 证明者并定期将哈希提交到链的中心化服务器来提供最佳服务。Validium 的安全等级低于 rollup，但可以便宜得多。

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

哪一个实际上更好？

在 L2 的子树中，存款和取款是否变得更便宜、更容易？

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

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

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

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

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

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

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

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

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

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

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

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

策略如下。今天，如果每个 ZK rollup 或 validium 收到一个证明，用于证明

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

这将是一个开放的协议：任何 ZK-rollup 都可以加入，并且任何批量证明者都可以从任何兼容的 ZK-rollup 聚合证明，并从聚合器获得交易费用的补偿。批处理程序合约将验证一次证明，然后将消息传递给每个 rollup，并带有

triple ；这个 triple 来自批处理程序合约的事实将证明转换是有效的。

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

对这种方法的一种回应可能是：但这实际上不只是另一种 L3 方案吗？而不是基础层 <- rollup <- validium，您有基础层 <- 批处理机制 <- rollup 或 validium。从某种哲学建筑的角度来看，这可能是真的。但是有一个重要的区别：中间层不是一个复杂的完整 EVM 系统，而是一个简化且高度专业化的对象，因此它更有可能是安全的，它更有可能被构建在所有这些都不需要另一个专门的代币，而且它更有可能被治理最小化，并且不会随着时间的推移而改变。

结论：什么是“层”？

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

然而，一旦我们开始深入了解哪种架构有意义的细节，我们就会进入哲学问题：什么是“层”，什么不是？基础层 <- 批处理机制 <- rollup 或验证模式与基础层 <- rollup <- rollup 或验证模式执行相同的工作。但就其工作方式而言，证明聚合层看起来更像 ERC-4337，而不是 rollup。通常，我们不会将 ERC-4337 称为“Layer2”。同样，我们不会将 Tornado Cash 称为“Layer2”——因此，如果我们要保持一致，我们不会将位于 Layer2 之上的以隐私为中心的子系统称为 layer2. 因此，关于什么应该首先被称为“层”（layer），存在一个未解决的语义争论。

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

因此，optimistic rollup 和 ZK rollup 是第 2 层（L2），但 validiums、证明聚合方案、ERC 4337、链上隐私系统和 Solidity 是另一回事。将其中一些称为第 3 层（L3）可能有意义，但可能不是全部；无论如何，现在确定定义似乎还为时过早，而多 rollup 生态系统的架构远非一成不变，大多数讨论仅在理论上进行。

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