http://www.7klian.com

概念:Eth2作为数据可用性引擎

这篇文章的原标题为 “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 构建分片,然后更快地启动分片。

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

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