以太坊分片设计简史：从区块到 Blob

从“Block”到“Blob”，意义深远。

带有“交联”的可执行“分片链”已经过时：信标链中的 EVM 实现； 以汇总为中心的以太坊路线图使用“数据可用性抽样”，在不增加应用程序环境复杂性的情况下扩展以太坊基础层。 但是如何在没有块元数据的情况下调用分片内容呢？

那么，这就是“斑点”派上用场的地方。 “Blobspace”是个好名字！

让我分享一些以太坊分片设计的历史：

分片（或“第 1 阶段”）应该按先前计划在“第 2 阶段”（信标链执行环境）中启动。 但是在“阶段 0”（信标链启动）之前，很明显主网 EVM 具有优先权，而“阶段 2”执行层（ewasm？）的推出还遥遥无期。

“Phase 1”规范在 Beacon Chain 之前已经被多次改写：

更少的碎片（1024 -> 64）

通过理想的跨分片通信（交叉链接）自由骑行

新的托管证明设计（删除托管部分，有利于罕见的故意证明丢失）

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

但是以太坊分片什么时候实现，如果L1只专注于解决数据问题，那么上面提到的大部分问题都会转化为L2开发问题。 而采样（sampling）正好解决了L1数据问题。 如果我们可以在网络层支持额外的功能会怎样……？

因此，在 2020 年 10 月 14 日，开发人员就“第一阶段网络连接问题（联网）”召开了电话会议。 经过讨论，可以得出结论：gossipsub很火+DHTs好像很慢。 但当时还处于早期阶段——每个 Web 开发人员都还在忙于准备信标链的发布（12 月 1 日！），并且由于当时的最新发展，网络层存在明显的差距。 有偏见。

当时的偏见：

Gossipsub = 热门，主网就绪（除了一些 DoS 问题外没有太大问题。这些问题也在主网启动之前被发现/披露）

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

()

但方向似乎很明确：降低 L1 复杂度，信标链已经足够复杂了。 只通过数据提高扩展性，长期使用“数据可用性抽样”方案，拥抱L2扩展方案。 因此，Vitalik 将其描述为“Ethereum Roadmap Centered on Rollup”（中文版）。

然而，当实施者忙于信标链的发布时，研究人员已经忙于上线后的工作：Vitalik/Dankrad 正在研究一些早期的数据可用性设计草案，试图让实施者更容易理解这些原则。

同时以太坊分片什么时候实现，我们启动了 Zinken、Toledo 和 Pyrmont 测试网+检查更多启动项目（检查错误等）。 我们努力跟上研究的步伐，并开始为网络层的事物添加设计文档。 在当时，关注这些问题还为时过早，但 DAS（数据可用性抽样）实在是太好了，不容忽视。

基于 gossipsub 的一些东西，我确实写了一些想法将它用于 DAS。 事后看来，我现在认为 DHT 比 Gossipsub 更适合 DAS，除了最初的分发。

当时我期望一些 DAS 规范能够被实现和模拟。 我想这是第一次提到“blob”？ 我们确实在“分片数据 blob”这样的上下文中使用过它，而那个术语当时并没有出现在分片规范中。

信标链发布后，我有更多的时间，然后我写了一个草案，在 Vitalik 和 Dankrad 编写的采样规范草案中增加了更多的类型化和网络层内容。 将 blob 命名带入分片规范 :)

2021 年有些事情发生了变化：为它设计的理想 p2p 结构太复杂了，所以我转而尝试为它贡献工具（go-kzg）并参与早期的合并工作（rayonism）。 然后在夏天再次尝试加入分片的研究工作，而不是致力于 Altair/London 升级的开发。

Blob 再次出现，这次使用更像 PBS 的结构——聚合 blob-builder 和 blob-proposer 的 BLS 签名。 仍然太复杂：因此，分片设计演变为主要“以信标提议者为中心”，因此它“仅”是网络层问题。

这在某种程度上像是第五种分片设计？ 极简主义有很多要放弃的地方，但结果是美丽而强大的：更多的模块化设计、包装和可选的复杂性。 Rollup 引起了我的注意，尤其是 Optimism。

2022 年底，EIP 4488（不要混淆，不是 4844！）和 4490：人们开始不耐烦了，呼叫数据的成本必须快速下降才能保持竞争力！ 在伦敦升级后，关于这些主题的讨论在 All Core 开发人员中也变得活跃起来。 但我认为这是不可持续的，因为 calldata 带有 L2 不需要的遗留开销。

与此同时，Vitalik 和 Dankrad 继续致力于一些新的分片设计：更加以信标链为中心，仅通过数据进行扩展，并专注于采样方案。 我认为“danksharding”真的是在 21 月底/22 月初发布的吗？ 不确定第一个版本是什么，Dankrad 一直致力于分片。

22 年初，Vitalik 提出了两种我们可以在不使用采样的情况下向全暗分片发展的方式：简单版本和复杂版本。 虽然在我看来，这其实就是“重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！

未来暗分片也有一些热点：

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

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

Gossip 和 TCP DHT 很糟糕，UDP DHT 类覆盖率很好：都是关于计算轻节点（discv5 什么时候横向扩展？）

更多danksharding热点：

采样在很大程度上依赖于优秀的同行，希望看到更多分数优先但稳健的设计。

比 p2p 缺乏验证者隐私更喜欢轻量级通信和更多 Sybil。

ZK可以成为未来的p2p反巫术，但现在看来还很遥远。