编者注：这篇文章的原标题为 “Phase One and Done: eth2 as a data availability engine”，在颁发其时（2019 年 4 月），作者意在为 Eth2.0 提出一种替代 Phase 2 的蹊径图，也就是，假如仅用分片来担保数据可得性，这样的系统是否有用，还需要增加哪些部门来使之变得有用。令人惊奇的是，在一年半以前，作者就已经认识到，对 zk-rollup 这样的系统来说，底层必需保障的是 “状态转换的执行和数据可得性必需是原子化地绑定在一起的”，因此底层必需具备执行本领，哪怕长短常简朴的无状态执行；并且，（作者也通过层层推理指出）为担保用户体验，还缺少的主要部门是数据怎么上分片的手续费付出协议（这两点认识，纵然放到本日，也仍然称得上是前沿，甚至是超前）。手续费协议在 Phase 2 的类型中，今朝也仍然是缺失的。

顺带说一句，本文作者是 Casey Detrio，他是 Ewasm 团队的一员，之前也为 Phase 2 提供过许多想法；他也认为，应该以 “担保 Eth1 的合约到了 Eth2 可以或许如常执行” 为焦点来设计 Eth2.0。他是被低估的一个开拓者。

今朝，限制 Eth1 吞吐量的瓶颈是状态增长。因此，假如我们想要扩展以太坊，从逻辑上来说，1000 个具有独立状态的分片可以或许将吞吐量提高 1000 倍。

可是，从 Eth1.x 的蹊径来看，Eth1.x 想要对两类资源的本钱举办重大调解：存储（storage）和生意业务数据（tx data）。今朝，存储的订价过低，而生意业务数据的订价过高。这会鼓励 dApp 开拓者在编写合约时更多利用存储而非生意业务数据，从而导致存储成为吞吐量的瓶颈。针对这一问题提出的办理方案是增加存储的订价，并淘汰生意业务数据的订价。颠末这些本钱调解，开拓者将受到鼓励更多地利用生意业务数据，而非存储（即，他们会编写更多无状态合约而非状态合约）。因此，在不久的未来（假如 Eth1.x 的蹊径图得到遍及回收），我们预期 Eth1 的吞吐量会受到生意业务数据的限制，而非存储的限制。

假如我们假设吞吐量受到生意业务数据的限制，那么为了扩展以太坊，Serenity 上的分片不需要有状态。假如吞吐量受到来自无状态合约的生意业务数据的限制，那么 1000 个无状态分片就会将吞吐量提高 1000 倍。

这听起来不错，可是需要通过度片来实现，按打算要比及 Phase 2。与此同时，我们可以将 Phase 1 作为数据可得性引擎。数据可得性引擎一词好像逐渐风行起来。我们来思考一下它是如何运作的。

以 zk-rollup 为例，zk-rollup 受到数据可得性的限制。Eth1 上的 zk-rollup 合约可否有效地将 Eth2 作为桥接式可用性保障提供方？假如在执行（即，验证 SNARK 证明并更新状态根）进程中无法同时保障数据可得性，你就会获得一个雷同 plasma 的zk-rollback系统。这个系统固然可以或许大幅提高 TPS，可是会引入巨大的衡量干系，需要处理惩罚像 plasma 那样的运营者挑战和退出机制。在可用性挑战中，任何人都可以提供数据来证明可用性，因此今朝还不清楚将数据放入桥接的 Eth2 分片中能不能让工作变得更简朴。

此刻有了另一个版本的 zk-rollup，即，500 TPS 的 zk-rollup，一切都变得简朴多了。不再需要指定的运营者，任何人随时都能充傍边继者，并生成 SNARK 证明来更新状态。事实上，数据可得性保障始终陪伴着状态更新，也就是说不需要处理惩罚像 plasma 那样的运营者挑战和退出机制。可是这需要执行和数据可得性保障都产生在同一笔生意业务中，而遗憾的是我们无法利用桥接式可用性引擎做到这点。换言之，桥接对付 zk-rollback 这样的欺诈证明系统来说足够了，可是对 zk-rollup 这样的有效性证明系统来说还不足。结论是，为了将 Layer 2 上的有效性证明简朴化，Layer 1 上的可用性引擎需要具备的一项重要成果是，能担保数据可得性与状态转换的执行是原子化地一起产生的。

或者我们不该该对这一认识感想惊奇。假如单靠数据可得性（没有执行）就有用的话，就不会有人说 Phase 1 启动只是为了确保一堆非零 blob（二进制大型工具）的可用性，也就不会有人诉苦必需要等 Eth2 进入下一阶段才气真正发挥浸染了（除了 PoS 之外）。我们正在尽力将 Phase 1 作为数据可得性引擎，可是它依然无法执行任何操纵，因此令人感想失望。（哇，我们可以构建 Mastercoin 2.0 了！）

那么，为什么 Phase 1 会与执行相斗嘴？好吧，假设是有状态执行，则每个分片都要维护一些当地状态。假如验证者需要维护许多当地状态，那么验证者混洗就会巨大得多。反之，假如没有执行，就不消担忧当地状态。验证者混洗就会简朴得多，我们就可以专注于利用数据 blob 构建分片，然后更快地启动分片。

可是，我们先不假设执行是有状态的。假如我们实验利用很是简朴的无状态虚拟机来执行操纵会怎么样？

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。