EN
Vitalik Buterin ：混合 Layer 2 协议的曙光
该中文版本编译由链闻提供。
当前以太坊 Layer 2 扩容解决方案 （主要是指 Plasma 和状态通道） 正从理论走向实践。但与此同时，我们越来越明显的看到这些技术存在内在挑战，离成熟的以太坊扩容技术还有一定距离。
在很大程度上，以太坊是成功的，因为以太坊的开发者体验很不错：编写程序、发布程序、任何人都可以与之交互。另一方面，设计一个状态通道或 Plasma 应用，依赖于很多关于激励和应用特定用例开发复杂性的明确推理。状态通道适用于特定用例，例如在两个交易者或两个游戏玩家之间发生的多笔重复支付 （在 Celer 中成功实施） ，但是更加通用的用例似乎依然存在一定难度。Plasma （尤其是 Plasma Cash） 可以用于支付场景，但想要实现通用用例存在一定程度的挑战：即使是部署一个去中心化交易所，也需要客户存储更多的历史数据，而且在 Plasma 上部署以太坊式通用智能合约似乎也非常困难。
但与此同时，一个被遗忘的「半 Layer 2 」的协议类别再次出现了——这一类型虽然无法提升可扩展性，但能实现更加泛化和安全的模型。
在 2014 年发布的一篇博客文章中，我介绍了「影子链」 （shadow chain） 的概念，它是一种在链上发布区块数据的架构，但在默认情况下并不会验证区块。相反，区块会被暂时接受，然后在一段时间 （比如两周左右） 之后才最终确认。在这两周内，临时被接受的区块可能会受到挑战，通过挑战验证区块，如果区块最终被证明是无效的，那么该区块所在的链将会被恢复，同时原始发布者的保证金会被扣除作为惩罚。合约不会追踪系统的完整状态，只会追踪状态根 （state root） ，用户自己也可以从头至尾处理提交给区块链的数据来计算状态。
而最近出现的一个叫做 ZK Rollup 的提案，通过使用 ZK-SNARKs 验证区块的有效性，虽然没有挑战期，但是可以达到同样的效果。
上图： 发布在链上的 ZK Rollup包剖析图 。影响ZK Rollup系统状态（即帐户余额）的数百笔“内部交易”被压缩成一个包，其中包含约占10个字节大小的每笔内部交易，以及用于证明相关转移过程全部有效性的（约100-300字节大小）SNARK，约 100-300 字节。
在上述情况下，主链用于验证数据可用性，但不会 （直接） 验证区块有效性或执行任何重要的计算 （除非有挑战被提出） 。因此，这种技术在扩容上并没有什么关键优势，因为链上数据负载最终会成为瓶颈，但不可否认，它依然是一个非常重要的手段。数据比计算更便宜，而且市场上也有很多大幅压缩交易数据的方法——主要是因为交易中绝大部分数据都是签名数据，而且很多签名可通过多种形式的聚合压缩为单个签名。ZK Rollup 承诺每秒可以处理 500 笔交易，这个效率比以太坊本身提升了三十倍，这是因为它将每个交易压缩到了仅仅 10 个字节，交易有效性由零知识证明验证，因此不需要包含签名。另一方面，使用 BLS 聚合签名可以在「影子链」中实现类似的吞吐量 （和最近以太坊 Casper 核心开发人员 Karl Floersch 发布的新架构 Optimistic Rollup 类似） 。即将推出的伊斯坦布尔硬分叉会将数据的 gas 成本从每字节 68 个单位减少到每字节 16 个单位，同时还会将吞吐量提升四倍 （即每秒处理超过 2000 笔交易）。
那么，相比于 Plasma 这样的链下扩容技术，像 ZK/Optimistic Rollup 这种数据链上技 （data on-chain techniques） 有什么好处呢？
首先，ZK/Optimistic Rollup 无需「半可信」 （semi-trusted） 运营商。在 ZK Rollup 中，因为交易有效性是通过加密证明（cryptographic proofs）来验证的，所以 package 的提交者其实没有太多办法「动坏心思」 （当然，虽然根据设置，恶意提交者可能会导致系统暂停几秒钟，但这其实是他们能够给系统造成的最大伤害了） 。在 Optimistic Rollup 中，恶意提交者可以发布「坏区块」 （bad block） ，但下一个提交者可以在发布自己的区块之前立即挑战该区块。在 ZK Rollup 和 Optimistic Rollup 中，会有足够多的数据会发布到链上，允许任何人计算完整的内部状态，需按顺序处理所有提交的 delta 即可，而且没有取消此属性的「数据扣留攻击」。也就是说，成为一个运营商可以是完全「无需许可」的，所需的保证金 （只有 10 ETH） 也仅仅是用于反垃圾邮件的目的而已。
其次，Optimistic Rollup 的实现更加泛化，Optimistic Rollup 系统中的状态转换函数可以在单个区块的 gas 上限中用来进行更加通用的计算 （包括提供验证过渡期所需状态部分的 Merkle 分支） 。理论上，ZK Rollup 也可通过相同方式实现通用计算，但实际操作中，将 ZK SNARKs 用于通用计算 （比如在 EVM 中执行） 是非常困难的，至少到目前为止是这样。
再次，Optimistic Rollup 更容易构建客户端，因为它对 Layer 2 网络基础设施的需求较少，只需扫描区块链即可完成很多工作。
不过，像 ZK/Optimistic Rollup 的优势是什么呢？实际上，这是一个高度技术性的问题，也就是所谓数据可用性问题 。 （具体可以参见解释文档 https://github.com/ethereum/research/wiki/A-note-on-> 和解释视频： https://www.youtube.com/watch?v=OJT_fR7wexw ）
基本上，有两种方法可以在 Layer 2 系统中「作弊」：第一种是将无效数据发布到区块链上，第二种是根本不发布数据 （ 例如，在 Plasma 中将 Plasma 新区块的根哈希发布到主链上，但不向任何人透露区块内容） 。
发布无效数据其实很容易处理，因为一旦数据在链上发布，有许多方法可以确定它是否有效，并且将提交的无效数据标记为无效，提交者也会因此受到严厉的惩罚。另一方面，不可用数据相比而言会更难处理，因为即使遇到挑战也无法检测到不可用性，也无法精准确定这些未发布的数据到底是谁的错误，尤其是在数据被默认保留的情况下，仅当某些验证机制试图验证其可用性时才按需显示。这一点在「渔夫困境」 （Fisherman’s dilemma） 中得到了说明，即在一个挑战响应游戏中，无法区分恶意提交者和恶意挑战者：
通过将问题推给用户，Plasma 和状态通道有效地解决了「渔夫困境」问题：如果你是一个用户，并且决定与另一个用户进行交互 （状态通道中的交易对手、或是 Plasma 中的操作员） ，假设该用户没有向你发送他们应该发布的数据，那么你就会退出，并转移到下一个交易对手 / 操作员。作为用户，你拥有所有以前的数据和由你签署的所有交易数据，这一事实使你可以在区块链中证明自己在 Layer 2 协议中拥有的资产，从而安全地将这些资产带出系统。另外，你还需要有 （之前同意过的） 接收资产的操作证明，同时，没有其他人可以证明你把相关资产发送给其他人，那么你就获得了这笔资产。这个技术的确很优雅，但却依赖一个关键性的假设：每个状态对象都有一个逻辑「所有者」，而且在未经该所有者同意的情况下，对象状态是不能被更改的。
所以，该技术适用于基于未花费交易输出 （UTXO） 的支付交易 （但不适用账户模型的支付交易，因为在这种情况下你能在未经他人同意的情况下向上编辑其他人的账户余额，这也是账户模型的 Plasma 如此困难的原因） ，甚至可以用于去中心化交易所，但这种「所有者 」的属性还远远不够。一些应用 （ 比如 Uniswap） 并没有自然所有者，即使在那些拥有所有者的应用程序中，也经常出现多个人可合法地对相关对象进行编辑。如果不引入拒绝服务 （Do S）攻击的可能性，就没有办法允许任意第三方退出资产，因为没有人能够证明发布者或提交者是否有过错。
此外，Plasma 和状态通道还分别存在一些其他问题。对于那些还没有加入状态通道的用户，不允许进行链下交易。Plasma 要求用户用户存储大量的历史数据，当不同的资产相互交织时，这些数据会变得更大（比如，一种资产转移的条件是基于另一种资产转移，就像在具有单段式（single-stage）买单机制的去中心化交易所中发生的那样）。
因为数据链上计算链下（>的 Layer 2 技术没有数据可用性问题，所以不存在上述弱点。ZK Rollup 和 Optimistic Rollup 会非常谨慎地在链上放置足够的数据，以便允许用户计算 Layer 2 系统的完整状态，确保如果任何参与者消失，新的参与者可以轻而易举地顶替。Layer 2 技术的唯一问题是不进行链上计算的情况下验证计算，但这其实是一个很容易解决的问题。而且，扩容会带来更大的效益：ZK Rollup 中每个交易大约 10 个字节，通过使用 BLS 聚合签名，Optimistic Rollup 也能达到类似的级别。理论上，每秒最高可达 500 次交易，而在伊斯坦布尔升级之后该指标数字可以达到每秒 2000 次。
但是，如果你想获得更高的可扩展性呢？
实际上，数据链上 Layer 2 和数据链下 Layer 2 协议之间存在很大的中间地带，许多混合解决方案较好地利用了两者的优势。举个简单的例子，通过在链上发布一个（少于 4 个字节的）订单撮合映射，就可以防止部署在 Plasma Cash 上的去中心化交易所出现历史存储爆炸问题：
上图中： 当拥有一个代币且该代币是通过 原子交换 获得时， Plasma Cash 用户需要存储的历史数据；
上图右： 如果订单撮合被发布在链上， Plasma Cash 用户需要存储的历史数据；
在去中心化交易所用例之外，为了减少用户需在 Plasma 中存储的历史数据量，则可以让 Plasma 链定期在链上发布每个用户的一些数据（per-user data）。我们还可以想象一个平台在某些状态有逻辑「所有者」的情况下像 Plasma 一样工作，或者在某些状态没有逻辑「所有者」的情况下，像 ZK Rollup 或 Optimistic Rollup 一样工作。Plasma 开发人员已开始着手这些优化工作。
其实，现在有必要为 Layer 2 扩容解决方案的开发者提供一个强有力的用例，让他们更愿意在链上发布每个用户的数据 （至少在某些时候愿意） ：这样会极大地提升开发便捷性、通用性和安全性，并减少了每个用户的负载 （例如，不需要用户存储历史数据） 。这么做也会提升效率，即使在完全链下的 Layer 2 架构中，用户在不同交易对手方和提供商之间存、取款和转账也将是不可避免且经常发生的，因此，会产生大量的用户数据。显然，混合路由为实现在准 Layer 2 架构内部快速部署完全通用的以太坊式智能合约打开了一扇门。
撰文：Vitalik Buterin
编译：链闻
来源：链闻
