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