Vitalik Buterin： 在 Layer-2 和 Layer-1 上异曲同工的技术,艾美奖

在许多情况下，为了提升可扩展性而提议的 Layer-1 改进方案（也就是说，对区块链协议或对客户端工作方式的修改）和 Layer-2 改进方案（姑且用这个广为传播的术语吧；所有从应用层设计模式上去改进可扩展性的，都可以算作此类），其实都在做相同的事。这篇帖子将通过一些例子和直觉知识来考虑这些案例。

无状态客户端

请参阅 The Stateless Client Concept （编者注：中译本见文末）了解无状态客户端的背景知识。概括一下，无状态客户端的工作方式是：让全节点仅存储状态的根哈希值，使用与区块一起发送的默克尔分支，来证明状态读写已经正确地执行了。但是无状态客户端可以有两种实现方式，一种是对区块链协议的修改（例如：http://medium.com/@akhounov/data-from-the-ethereum-stateless-prototype-8c69479c8abc)（编者注：中译本见文末）），或者是对特定合约做点改变，用代码来保证合约只有一个哈希值作为其状态，任何对状态的改变都需要有默克尔证据。值得注意的是，在这两种情况下，用来改进可扩展性的行为（让客户端下载并处理额外的默克尔分支来代替数据存储）都是一样的，只是实现不同，一个是对区块链全节点行为的改变，一个是作为可选的应用层改变。

错误性证明

Optimistic rollup 的工作方式是：让系统存储一系列的历史状态根；添加了一个新的状态的一段时间（例如：1 周）后才将新状态最终敲定。当一个新的、包含一些交易的 “包” 被提交至 rollup 合约，（这些刷新 Layer-2 状态的）交易不会在链上被验证（尽管这些交易的可用性会被隐式地验证，因为它们都得打包在这笔上链交易里）；相反，只是把状态根添加到列表中。然而，如果外部观察者发现有的包是无效的（也就是说，这些包中声称的状态根，与基于前一个状态并诚实地执行区块后应该生成的状态不匹配），他们可以提交一个挑战。当且仅当如此，包才会在链上实际执行；如果包被证明是无效的，那么这个包及其后面的状态都会回滚。上述模式即是所谓的 “错误性证明”（Fraud proofs）。错误性证明的工作方式是：默认情况下，客户端不验证状态（尽管它们依旧需要下载所有的区块去验证可用性），而是去接受区块；只有当客户端收到网络中的消息，其中包含默克尔证明，表明特定的某个区块是无效的时候，才会拒绝区块。显然，相同的机制（默认情况下，下载区块但是不检查内容，只有某人发送警报时才检查）可以在 Layer-2 方案中使用，也可以在 Layer1 中作为对客户端效率的改进。然而要注意一点：想让 Layer-1 的错误性证明和 rollup 拥有一样的特性，对数据的共识和对状态的共识需要是分离的过程。否则，创造区块的节点在发布其区块之前，需要自己验证最近的所有区块（因为可能没有足够的时间得到错误性证明），这可能会限制可扩展性的增益。

签名聚合

像 BLS signature aggregation （BLS 签名聚合）这样的技术可以让很多签名被压缩成一个，极大地节省了数据和一些计算开销（相对于计算，数据存储上的巨大节省使其与错误性证明相结合时可以有非常强大的性能）。这些技术可以用在链上，将一个区块内的所有交易组合成一笔交易。这些技术也可以用在应用层，通过交易打包机制，让许多交易打包成一个包来提交，一个签名检查器根据所有交易的哈希值和交易中声称的发送方的公钥来验证签名，然后再独立执行交易。

SNARK / STARK

SNARK 和 STARK 可以解除客户端重新执行长时间计算的需要，因为其验证只需一个简单的证明。这个同样可以在 layer 1 上（例如：见 Coda）或者在 layer 2 上（例如：ZK Rollup）完成。

在 layer 1 实现 vs 在 layer 2 实现

在 Layer 1 上实现有以下优势：

• 它对链 “保留可识别性”，因为默认的基础设施能够理解可扩展性解决方案，并且解释发生了什么（虽然通用的 Layer-2 技术的标准化在某种程度上也可以提供这个）

• 它降低了 Layer-2 解决方案的碎片化风险

• 它允许网络围绕解决方案去组织基础设施，例如，为响应新的区块，自动地更新证明；交易可抵抗 DoS 攻击；等等

• 在需要有所牺牲的情况下，它为 节点 提供了更多的选择自由，节点可以考虑自己的需要。例如，一些客户端可能存储所有的状态，并最小化带宽，然而其他的客户端可能无状态地验证区块，并接受这样做带来的带宽损失（VPSes 与家用计算机相比，在这里可能会选择不同的选项）。作为一种选择，一些客户端可能会使用基于错误性证明的验证方式去节省花销，而另一些客户端可能会验证所有状态去最大化他们的安全等级。

在 layer 2 上实现有以下优势：

• 它给未来可能出现的创新保留了空间，不需要硬分叉区块链

• 可以最小化共识层的复杂性，尤其是在不同场景需要多种方案时，这是很大的优势

• 用户可以因此从拥有很强假设（例如：受信任的初始设置）的应用中受益，而不必在共识安全性构造中引入这些假设（尽管有时候放到 Layer 1 上也可以实现这一点）

• 需要权衡的时候，它为 应用 提供了更多的选择自由，应用可以按自己的需要挑选方案。一些应用可以在链上运行，而另一些可以在 rollup 中运行

其他的关键点

从依赖于相同底层行为的 Layer 1 和 Layer 2 上获得的可扩展性增益一般是不能结合的。例如，使用错误性证明得到的可扩展性增益与使用 rollups 得到的可扩展性增益不会彼此叠加，因为他们根本上是实现了相同的机制，因此如果使用 rollups 在基础层得到了 10000 tx/sec，使用错误性证明达到 1000 tx/sec 是安全的，只使用错误性证明在相同的基础层上得到 10000 tx/sec 也是安全的。在 Layer 1 和 Layer 2 上做相同的事会导致不必要的基础设施膨胀，因此经常在两者中选择一个是比较合理的。例如，如果不管不顾地使用 Layer 2 的无状态合约，那么这也会使 Layer-1 的状态极其昂贵，而不能去有效地实施 layer-2 的方案，因此，要保持较小的状态，免得 layer 1 也需要构建无状态客户端。同样的需要注意的是，数据可用性是唯一一件可以在 Layer 1 上可以解决、但在 Layer-2 上则只能依靠大幅放松的安全假设（例如：假设另一组参与者中诚实方占大多数）来提供的事。这是因为在数据可用性证明或者其它可用别的块和纠删码来重构一个块的替代性系统中，区块重构在很大程度上依赖于客户端一侧的随机性，而对于不同的客户端这个随机性又是不一样的，且在链上不能重复。

结论

在 Layer 2 进行持续创新的愿望是一个很重要的论点，这驱使我自己倾向于对 eth2 提供一个重量级的 Layer-2 设计，即最小化 Layer 1 提供的特性（例如：保持较小的状态，这样一来，就不需要无状态客户端，而在 L2 上则强制使用无状态合约）。然而，因为一些需要，我们想在 Layer 1 提供一个显式的工具。根据前述理由，最重要的一件事应该就是在通用可扩展区块链的 Layer 1 中的数据可用性，这也是为什么要完全实现 eth2， 而不是对已存的 eth1 链构建一个重量级 Layer-2 的路线图的主要原因。
（完）（文内提供了许多超链接，请点击阅读原文到 EthFans 网站上获取）

原文链接:http://ethresear.ch/t/cases-where-the-same-thing-can-be-done-with-layer-1-and-layer-2-techniques/6111作者: Vitalik翻译 & 校对: haiki & 阿剑