从“Block”到“Blob”，这其中涵义深刻。带有“crosslink”的可执行的“分片链”被淘汰了：在信标链中实现EVM；使用“数据可用性采样”的以rollup为中心的以太坊路线图，扩容以太坊基础层而无需增加应用环境的复杂性。但是，你如何在没有区块元数据的情况下调用分片内容呢？好吧，这就是“blob”派上用场的地方。“Blobspace”真是一个不错的叫法！让我来分享一些以太坊分片设计的历史吧：分片(或“阶段1”)按之前的计划应该是在“阶段2”(即信标链执行环境)推出。但在“阶段0”(信标链启动)之前，主网EVM具有优先权这一情况变得清晰，而“阶段2”执行层(ewasm?)的推出遥遥无期。“阶段1”的规范在信标链之前已经重写了多次：更少的分片(1024->64)借助理想的跨分片通信(crosslinksjtqo)实现自由骑行新的托管证明设计(去掉托管部分，转而采用罕见的故意证明丢失)更别说更早期的分片研究工作了，实话说，那些研究都非常抽象以及雄心勃勃：跨域消息传递、带有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年底，EIP4488(注意不要搞混了，不是4844！)和4490出现了：人们开始变得不耐烦，calldata的成本必须快速降低以保持竞争力！伦敦升级之后的AllCoredevs上对这些话题的讨论也变得很热烈。但在我看来这是不可持续的，因为calldata带有L2不需要的传统开销。同时，Vitalik和Dankrad继续研究一些新的分片设计：更加以信标链为中心、只通过数据进行扩容、专注于采样方案。我觉得“danksharding”在21年底/22年初真正公开出来？不是很确定第一个版本是哪个了，Dankrad一直都在研究分片。22年初，Vitalik提出了两种方法，我们可以在不使用采样的情况下，向完整的danksharding发展：简单版本和复杂版本。虽然在我看来，这其实就是“重EL(执行层)”以及“EL和CL分离，更容易和未来兼容”之间的区别。我喜欢第二个方案，然后在EthDenver2022期间，我们实现了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和TCPDHTs不好，UDPDHT类的覆盖很好：这都是关于轻节点的计数(什么时候进行discv5扩展？)更多danksharding的热点：采样很大程度上依赖于良好的对等节点，希望看到更多评分优先但健壮的设计。宁愿选择轻量级的通信和更多的女巫，而不是缺乏p2p上的验证者隐私。ZK可以成为未来p2p抗女巫的技术，但现在来说似乎还远着。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。