ETH 1.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 的提案。

 

来源:以太坊爱好者

联系我们

在线咨询:点击这里给我发消息

邮件:midysky@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息