EN
Vitalik：在Layer-2和Layer-1上异曲同工的技术
无状态客户端
请参阅 The Stateless Client Concept （编者注：中译本见文末）了解无状态客户端的背景知识。概括一下，无状态客户端的工作方式是：让全节点仅存储状态的根哈希值，使用与区块一起发送的默克尔分支，来证明状态读写已经正确地执行了。
但是无状态客户端可以有两种实现方式，一种是对区块链协议的修改（例如： https://medium.com/@akhounov/>错误性证明
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 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 的路线图的主要原因。
（完）
原文链接: https://ethresear.ch/t/cases-where-the-same-thing-can-be-done-with-layer-1-and-layer-2-techniques/6111 作者: Vitalik Buterin 翻译&校对: haiki & 阿剑
（本文来源于以太坊爱好者 EthFans，未经作者许可严禁转载，违者法律必究）
