今日推荐 | Vitalik：在Layer-2和Layer-1上异曲同工的技术

作者: Vitalik Buterin

翻译&校对: haiki & 阿剑

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

无状态客户端

概括一下，无状态客户端的工作方式是：让全节点仅存储状态的根哈希值，使用与区块一起发送的默克尔分支，来证明状态读写已经正确地执行了。

但是无状态客户端可以有两种实现方式，一种是对区块链协议的修改的工作方式是：让系统存储一系列的历史状态根；添加了一个新的状态的一段时间（例如：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 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 的路线图的主要原因。