以太坊分片设计简史:从「Block」到「Blob」

本文约2184字,阅读全文需要约3分钟
从 “Block” 到 “Blob”,这其中涵义深刻。

原文来源: @protolambda推文

原文作者:Protolambda

从 “Block” 到 “Blob”,这其中涵义深刻。

带有 “crosslink” 的可执行的 “分片链” 被淘汰了:在信标链中实现 EVM;使用 “数据可用性采样” 的以 rollup 为中心的以太坊路线图,扩容以太坊基础层而无需增加应用环境的复杂性。但是,你如何在没有区块元数据的情况下调用分片内容呢?

好吧,这就是 “blob” 派上用场的地方。“Blobspace” 真是一个不错的叫法!

让我来分享一些以太坊分片设计的历史吧:

分片 (或 “阶段 1”) 按之前的计划应该是在 “阶段 2” (即信标链执行环境) 推出。但在 “阶段 0” (信标链启动) 之前,主网 EVM 具有优先权这一情况变得清晰,而 “阶段 2” 执行层 (ewasm?) 的推出遥遥无期。

“阶段 1” 的规范在信标链之前已经重写了多次:

  • 更少的分片 (1024 -> 64)

  • 借助理想的跨分片通信 (crosslinks) 实现自由骑行

  • 新的托管证明设计 (去掉托管部分,转而采用罕见的故意证明丢失)

更别说更早期的分片研究工作了,实话说,那些研究都非常抽象以及雄心勃勃:跨域消息传递、带有 ewasm 的执行环境、动态访问的无状态性、分片委员会等等都让 L1 变得更加复杂。而 L1 已经开始僵化了。

但是,如果 L1 只专注于解决数据问题,那么上述提到的大多数问题都转化为 L2 的开发问题。而采样 (sampling) 正好解决了 L1 数据问题。如果我们可以在网络层支持额外的功能...会如何呢?

因此在 2020 年 10 月 14 日,开发者就 ”阶段 1 的网络连接问题(networking)“ 进行了一次电话会议。讨论下来可以得出:gossipsub 热度很高 + DHTs 似乎很慢。但在当时,这些为时还早 —— 每一个网络开发者都还在忙着为信标链的发布做准备 (12 月 1 日!),而且由于当时的最新情况,网络层存在很明显的偏向。

当时的偏向:

  • Gossipsub = 炙手可热,主网准备就绪 (除了一些 DoS 问题之外,没有多大问题了。并且这些问题也在主网启动之前发现/披露了)

  • Discv5 = 不完整,需要在主网启动前从5.0 -> 5.1进行实时网络迁移

(https://github.com/protolambda/discv5-catdog)

但方向似乎很明确:减少 L1 复杂性,信标链已经够复杂了。只通过数据提高可扩展性,长期来看使用“数据可用性采样”方案,并拥抱 L2 扩容解决方案。因此 Vitalik 将其描述为 《以 rollup 为中心的以太坊路线图》 (中文版)。

然而,当实现者忙于信标链的发布时,研究人员已经忙于发布后的工作了:Vitalik/Dankrad 当时致力于一些早期的数据可用性设计草案,试图让实现者更加容易理解这些原理。

同时,我们启动了 Zinken、Toledo 和 Pyrmont 测试网 + 检查更多的启动事项 (检查漏洞等)。并且我们尝试跟上研究的进度,并开始针对网络层上的东西添加设计文档。就当时来说,关注这些问题还太早了,但 DAS (数据可用性采样) 实在太好了,没办法忽视。

基于 gossipsub 的一些东西,我确实写了一些想法,把它用于 DAS。事后看来,我现在倒认为 DHTs 比 Gossipsub 更加适合 DAS,也许除了初始分配。

当时我期望一些 DAS 的规范能够被实现和模拟。我想这是 “blob” 首次被提到?我们确实在 “分片数据 blob” 这样的上下文中使用过它,而且那时分片的规范中还没出现过这个词。

信标链发布之后,又有了更多的时间,然后我写了一个草案,在 Vitalik 和 Dankrad 写的采样规范草案中加入了更多 typing 和网络层的内容。将 blob 命名引入分片的规范 :)

2021 年一些事情发生了改变:为其设计的理想的 p2p 结构太复杂了,所以我转而尝试为它贡献工具 (go-kzg) 和参与早期的合并工作 (rayonism)。然后在夏天再次尝试加入分片的研究工作,而不是参与 Altair/London 升级的开发工作。

Blob 又出现了,这次它的结构更加 PBS 化 —— 聚合了 blob-构建者和 blob-提议者的 BLS 签名。但还是太复杂了:因此,分片设计的演进方向变得主要 “以信标提议者为中心”,这样设计使得其 “仅” 成为一个网络层的问题。

这在某种程度上就像是对分片的第五次设计?极简主义要舍弃掉很多东西,但结果确是美丽且强大的:更多的模块化设计、封装以及可选的复杂性。Rollup 引起了我的注意,尤其是 Optimism

2022 年底,EIP 4488 (注意不要搞混了,不是 4844!) 和 4490 出现了:人们开始变得不耐烦,calldata 的成本必须快速降低以保持竞争力!伦敦升级之后的 All Core devs 上对这些话题的讨论也变得很热烈。但在我看来这是不可持续的,因为 calldata 带有 L2 不需要的传统开销。

同时,Vitalik 和 Dankrad 继续研究一些新的分片设计:更加以信标链为中心、只通过数据进行扩容、专注于采样方案。我觉得 “danksharding” 在 21 年底/22 年初真正公开出来?不是很确定第一个版本是哪个了,Dankrad 一直都在研究分片。

22 年初,Vitalik 提出了两种方法,我们可以在不使用采样的情况下,向完整的 danksharding 发展:简单版本和复杂版本。虽然在我看来,这其实就是 “重 EL (执行层)” 以及 “EL 和 CL 分离,更容易和未来兼容” 之间的区别。

我喜欢第二个方案,然后在 EthDenver 2022 期间,我们实现了 EIP-4844:我和 @lightclients 致力于 Geth;@asn_d6 帮助研发 KZG;@adietrichs 致力于费用市场的研究;并且都和 Vitalik/Dankrad 一起起草一份 EIP。Prysm 团队构建了首个 CL 原型。

现在 4844 被命名为 proto-danksharding:实现完整分片的前提条件。但是 “blobspace” 才是真正的模因:经过许多次分片的设计迭代之后,这是比任何其他分片设计都更接近达到以太坊愿景的一个版本。

对我来说,Serenity 这个阶段就是完成所有 PoS 和分片设计以及迭代更新的工作。我们已经在信标链以及类似于协议外 PBS 这些开发上获得一些进展,让我们在 PoS 方面有了一个不错的开始。我想现在是时候对分片进行首次升级了:4844!

还有一些对未来 danksharding 的热点:

  • L1 数据包含延迟对 L2 的影响被高估了。

  • 为了获得更多数据可用性的带宽,值得权衡的设计空间。

  • Gossip 和 TCP DHTs 不好,UDP DHT 类的覆盖很好:这都是关于轻节点的计数 (什么时候进行 discv5 扩展?)

更多 danksharding 的热点:

  • 采样很大程度上依赖于良好的对等节点,希望看到更多评分优先但健壮的设计。

  • 宁愿选择轻量级的通信和更多的女巫,而不是缺乏 p2p 上的验证者隐私。

  • ZK 可以成为未来 p2p 抗女巫的技术,但现在来说似乎还远着。

原创文章,作者:ECN以太坊中国。转载/内容合作/寻求报道请联系 report@odaily.email;违规转载法律必究。

ODAILY提醒,请广大读者树立正确的货币观念和投资理念,理性看待区块链,切实提高风险意识;对发现的违法犯罪线索,可积极向有关部门举报反映。

推荐阅读
星球精选