Layer3 或是加密世界的下一层

从经典定义来看，Layer 2 的往往被定义为依赖于以太坊主网进行结算，具备可扩容性的网络；以此类推，Layer 3 的定义则是依赖于 Layer 2 进行结算，更具可扩容性的网络。

在 Layer 2 的环境下，所谓的「依赖以太坊进行结算」，在技术层面上的实现机制为：将 Layer 2 的大量交易数据打包并压缩，继而同步至以太坊网络，并通过 Calldate（早期方案）或 Blob（当前方案）的数据空间进行存储。

理想情况下，假如 Layer 2 的这套结算逻辑可行，那么 Layer 3 依赖于 Layer 2 进行结算的逻辑似乎也应该成立，其技术层面上的实现机制理应为：将 Layer 3 的大量交易数据打包并压缩，继而同步至 Layer 2 网络……

到这一步时，问题就要开始出现了。

由于 Layer 2 本身并不负责网络「最终性」的确认，而是依赖于以太坊进行，那么理论上 Layer 3 的数据最终也应该提交至以太坊，由以太坊「一锤定音」。

对于已提交至 Layer 2 的 Layer 3 压缩数据而言，这时有两种潜在的提交模式（继续压缩 or 不再压缩），但可惜的是无论哪种模式暂时都存在一定问题。

Vitalik 在 2022 年时曾写过一篇关于 Layer 3 的分析文章《什么样的 Layer 3 才有意义》，文中曾解释了为什么我们不能对交易数据进行多次压缩：

Rollup 使用了一系列压缩方案来减少交易储存的数据量，一笔简单的转账可大约 100 字节压缩至约 16 字节，一笔 EVM 兼容链上的 ERC 20 转账可从约 180 字节压缩至约 23 字节，一笔 ZK-SNARK 交易可从约 600 字节压缩至约 80 字节。所有上述案例大约都可以实现 8 倍左右的压缩效率……然而，由于 Rollup 依然需要在链上保持数据可用性，保证用户可访问并验证的所有数据，比如独立计算 Rollup 的状态，或是在现有验证节点离线时作为新的验证节点加入……数据可以被压缩一次，但不可以被重复压缩，如果可以的话，通常意味着我们可以将第二个压缩器的逻辑放入第一个中，但这也意味着我们本可利用一次压缩就能获得同样的效果。因此，「Rollup 上再套一个 Rollup」并不具备真正的扩容效果的解决方案。

简单来说，出于数据可用性考虑，对交易数据进行压缩本就存在一定的限制。

在这一前提下，如果我们可以通过将第二次压缩的逻辑集成至第一次压缩过程中，来实现 Layer 3 数据的多重压缩，这也就意味着我们也可以对 Layer 2 数据直接进行多重压缩，进而在 Layer 2 层面就可以达成同样的扩容效果，那为什么我们还需要 Layer 3 呢？

究其原因，压缩算法本质上就是在某种程度上移除数据冗余，使得数据变得更加紧凑，可一旦这些冗余被移除，对已经压缩过的数据再次进行压缩就变得更难，因为可被去除的冗余只会越来越少。因此，数据压缩并不是一个可以无限重复的过程，压缩的收益也是递减的。

接着我们看第二种潜在的提交模式，即不再对 Layer 3 数据进行压缩，而是直接与其他 Layer 2 交易一起提交至以太坊主网。

这同样让人觉得有些莫名其妙，因为整体来看，当下限制了以太坊生态扩容效果的最主要瓶颈并不在于 Layer 2 （包括 Layer 3）上的区块空间不足，而是主网的数据可用性承载能力有限 ——即用以存储 Layer 2 数据的 Blob 存储空间依然有限。

Monad 联合创始人 Keone Hon 此前曾发文表示，当前 Blob 的容量状况大概是每个区块（12 秒）产出 3 个 125 kb 的 Blob，即每秒 31.25 kb，鉴于一笔交易的数量约为 100 字节（相较 Vitalik 给出的数字略高），这意味着所有 Layer 2 的共享 TPS 大概是 300 左右。