首页 > 热点新闻 > 观点 | 范式转变:Eth2.0 的分片链如何能服务于 Eth1.0 上的合约?
转载  

观点 | 范式转变:Eth2.0 的分片链如何能服务于 Eth1.0 上的合约?

摘要:编者注:本文为 Casey Detrio 于 6 月 1 日发表的长推特,谈及 Eth1.0 的迁移问题以及一个他认为非常天才的想法:用桥接器让 Eth1.0 上的合约来协调分片链,让后者的吞吐量可以为前者所用。Eth1.0 的迁移问题实际上是所有以太坊社区成员都关心的问题,而周全

编者注:本文为 Casey Detrio 于 6 月 1 日发表的长推特,谈及 Eth1.0 的迁移问题以及一个他认为非常天才的想法:用桥接器让 Eth1.0 上的合约来协调分片链,让后者的吞吐量可以为前者所用。Eth1.0 的迁移问题实际上是所有以太坊社区成员都关心的问题,而周全的解决方案显然还需进一步讨论。

Casey Detrio:

昨天我跟 @josephch 聊了很长时间,他问了一个重大但又可怕的问题:随着大家的注意力都转向 Eth2.0 的发布,从长远来看,Eth1.0 链以及链上的所有合约及其用户,要如何适应 Eth2.0(Serenity)的路线图呢?

我们曾经害怕这个问题,因为给不出一个好的答案。但这一次,我们问了一个新的问题、用了一种新的叙事方式,因此我从中得到的更多是启发,而非恐惧。因为其中实际上包含着一种思考模式的转变,一开始它只会逐渐地发生,(我希望)未来它会集体性地同时爆发。

我所受到的启发是:与其问 Eth1.0 的合约要如何迁移到 Eth2.0 的分片上(破),不如问 Eth2.0 的分片要如何服务于 Eth1.0 上的合约(立)!

尽管他也知道这是一个棘手的问题,我觉得 Joseph 一定从中得到了启发,因为他也意识到了这种转变。这种朝向全新理解的角度转变始于一项围绕着 Eth2 的创新:Eth1 到 Eth2 的 “可用性桥接器”。

桥接器这种想法已经被提出有几个月之久了,但当时并没有被当成重要的创新(至少我是没看出来)。追溯历史,我们可以看出为什么它被低估了。这故事要从 2018 年 6 月那场转折开始说起。

在 2018 年 6 月的路线转折中,人们放弃了在主网上部署 PoS,而是选择发布 Eth2.0(PoS + Sharding)作为一条独立的新链(信标链 + 分片链),让我们晕头转向。被推到了一个新的宇宙中,我们就要围绕着 Eth2.0 来调整自己,我们的愿景也变得完全以 Eth2.0 为中心。

在 2018 年的路线转折中,人们提出了分阶段的 Eth2.0 构想;自那以后,可用性桥接器就成了最重要的一件事,虽然这一念想完全不引人注目。我们可以从 Eth2.0 阶段性构想的一个有趣侧面证明这一点。

这个有趣的一面就是,在 Phase1 中分片链是完全没有用途的,因为验证者为分片链打包的区块(即数据块)里面除了 0 字节什么也没有。要启动 100 条满是 0 字节的分片链显然很蠢。

这里的问题在于,要想可靠地把用户的交易(非 0 字节的数据)打包到分片链区块中,我们先得确定 Phase 2 工作的基本原理。而这是我们还没能确定的。

而可用性桥接器的天才之处在于,它使用 Eth1.0 的合约给分片区块提议者支付、要求后者在数据块中纳入有用的非零数据。

我要说的是,如果我们盯着 Phase2 作为最终目标,我们是看不见 eth2-phase1 桥接器对 Eth1.0 链的重要性的:在等待 Phase2 发行的时候,这个桥接器看起来就是某种装装样子的哨子。

而我正在意识到,这种桥接器是一种全新的想法,有可能产生出新路线图和传统愿景的统一体:Eth2.0 = Eth1.0 + PoS + 分片链

这种统一体不再把 Eth2.0/分片 当成一个独立的新系统、也不再给 Eth1.0 的 dApp 安排一场迫在眉睫、颠沛流离、挫人士气的大迁徙;桥接器可以让我们把分片链当成 Eth1.0 的延伸,分片链会建立在 Eth1.0 生态系统的势能之上,并带着这种势能继续前行。

也许我们可以拓宽桥接器,变成一个 8 车道超级通道,将 Eth1.0 链 与百万吨级的可用性和执行引擎连接起来,获得 1000 条乃至 10000 条分片链的并行吞吐量。

Eth1.0 链可以成为 “帝国首都”/最热门的分片链,其中的合约可以发起即时的同步调用(调用部署在其它 “城市” 里的合约)(当然也要付出更高的费用)。

那些不是严格与 dApp 间交互相关的 dApp 功能可以并行处理,可以迁移到 “分片上” 而非链下(即在分片上执行,而不是在主链上执行)。

我猜想,其他开发者和研究者也正在产生类似的想法、在迭代 eth1-eth2 桥接器。我迫不及待想看看他们的提议。

Vitalik:

这……感觉不太 make sense。理由如下:

无论怎么说,我们需要从 PoW 迁移到 PoS,而信标链会是 PoS 中心链。所以,如果 “Eth1.0” 要变成每个人都跟踪的一个中心,它得变成信标链上的一个状态根和一个数据空间。所以无论怎么说我们都不得不付出这个迁移成本。

然后,我们还有 @realLedgerwatch 在打造 Eth1.0 无状态客户端上的工作。为了防止运行信标链节点的门槛太高,eth1.0 的验证工作必须基于无状态客户端。当前我们有的是一个执行环境,除了某些原因,每个信标链节点都必须验证数据。对于安全性来说这不是必需的,我们可以降格成由一个委员会(和感兴趣的节点)来验证数据。

目前我们已经为将 Eth1.0 引擎转变为一个执行环境的每一步都做了辩护。也许它会是人们首要使用的一个执行环境。如果有需要,我也可以通过加入基本的跨分片支持来让它变得更突出。

因此,我们可以合理地说,eth1.0 系统整个要从一条链转变为一个执行环境。如果计划得当,这一操作可以无缝完成,不会破坏应用。因此,对 dApp 来说迁移成本也可以下降到零。

好吧,我收回 “不太 make sense” 的说法。实际上这并不是 “A vs B” 的辩论,把 Eth1.0 当执行环境的模型是两大方法的综合(eth2 围绕 eth1 vs eth2 取代 eth1),综合之后我们可以同时获得双方的优势。具体来说,就是:

  • 接近于 0 的迁移成本
  • 在 eth1 上开发 dApp 变成了一个长期可靠的策略,因为 eth2 完全体出现之后,他们就可以开始使用其它分片链
  • 不会在长期中导致共识复杂性翻倍
  • 快速离开 PoW
  • 更低的设计成本,因为我们可以把我们首要关注的第一个执行环境放在 eth1.0 无状态客户端中
  • 同时,感兴趣的团队可以专注于用更好的设计打造相互竞争的执行环境,也许最终大多数活动都可以迁移到更好的执行环境中
  • 以及,最重要的是,eth1.0 以及上面的合约 “看起来” 就像 eth2.0 系统中的一等公民(译者注:在软件设计上指的是第一级的操作对象),而非二等公民
Casey Detrio:

 

当你说 “ ‘这’ 不太 make sense” 的时候,我不太清楚你的 “这” 指的是什么。当然,问题本身 “eth2.0 的分片链可以给现有的 eth1.0 合约带来什么帮助” 当然是有意义的。我的意思是,这就是可用性桥接器本身试图回答的问题,不是吗?

所以,也许你的意思是迭代可用性桥接器的提议没什么意义?你似乎是在主张:把 eth1.0 链变成一个分片(或者一个执行环境)是一种更好的方法。有些 eth2.0 研究员怀疑这是不是真的可行,我还算乐观的了。

另,你的第(4) 条指出 “除了某些原因,每个信标链节点都必须验证数据”,我不太清楚你在讲什么。我做了一个模糊而开发的建议:迭代可用性桥接器的理念。我没有提议每个信标链节点都要验证数据(不管这到底是什么意思)。

不管怎么说,你得承认,这里面是一种叙事上的转变。旧的故事是:“我们可能永远都无法把 eth1.0 整合到 eth2.0 中。还是开始准备迁移所有合约吧,而且需要完全 重写/重新设计 跨合约通信服务”。

而新的故事是:“我们可以在 Phase2 发布之前给 eth1.0 做一个可用性桥接器。Phase2 发布之后,一条可行的路是将 eth1.0 转变为 eth2.0 中的分片链/执行环境。” 最终的迁移作为一种遥远的可能性一直都是摆在台面上的,但它不再是主流叙事了。

我认为可用性桥接器(及其迭代)是另一条可以结出硕果的路径(而且与 eth1.0 的迁移并不互斥)。桥接器 1.0 及其迭代版本是否有用,或者是否不得不做出重大牺牲,是我想要讨论的问题。

再说清楚一些,我所谓的 “可用性桥接器” 指的是 @VitalikButerin 提出过的 “在 eth1.0 轻客户端中实现 eth2.0”,而非我曾经写过的 “开发到 Phase1 就结束”,后者讲到了可用性桥接器,但并没有迭代它,而且就其自身而言只是一个 eth2.0 的提案。

原文链接: https://twitter.com/cdetrio/status/1134949249974767616 作者: Casey Detrio 翻译: 阿剑

(本文来源于以太坊爱好者 EthFans,未经作者许可严禁转载,违者法律必究)

免责声明
世链财经作为开放的信息发布平台,所有资讯仅代表作者个人观点,与世链财经无关。如文章、图片、音频或视频出现侵权、违规及其他不当言论,请提供相关材料,发送到:2785592653@qq.com。
风险提示:本站所提供的资讯不代表任何投资暗示。投资有风险,入市须谨慎。
世链粉丝群:提供最新热点新闻,空投糖果、红包等福利,微信:msy2134。