Time:2022-10-24 Click:186
TL;DR
EIP4844 这项工作带来了巨大的推动力,在 Devcon 会议期间进行了多次高影响力的工作会议,确定了一些小的规格变化,并正在全速推动实施中。
EIP4844 将使第 2 层 Rollup 的费用减少 10-100 倍并拥有更高的交易吞吐量。它通过一种名为“Blobspace”的 Rollup 构建的形式,使得以太坊能够引入数据可用性来做到这一点。
这一变化对于推动以太坊的采用至关重要——例如在 Coinbase,"我们认为 EIP-4844 是将我们的客户带入加密经济的一个关键推动因素,它具有安全、易于使用的体验,而且更快、更便宜"。
Devcon 的目标是推动所有客户团队就「如何最好地交付 EIP4844」进行讨论。为了实现这一目标,来自 Ethereum、OPLab 和 Coinbase 的开发者们在过去的 5 个月里编写了规范,在 Geth 和 Prysm 中实施,启动了两个开发网,并准备了 KZG 仪式。
在会议期间,我们在许多不同的场合都进行了讨论:在 Devcon 前的研发日的多个研讨会,在 EthMagicians 期间的对话,客户团队参加的半天工作会议,以及几乎每天都有的临时对话。
从这些对话中,我们确定了对执行层和共识层规范的一些小改动。我们还发现,整个客户团队最大的关注点是增加 Blobs 的网络影响。
在共识层,我们决定将 Blobs 和 Block 结合起来,而不是让它们分离。我们做出这个决定是为了简化实施,并期望在下一阶段的 Danksharding 中,我们可能才会让它们分离。
在执行层,为了减少潜在的 DOS 载体,我们决定更新有线协议,使得带 Blob 的交易只被公布,而不是广播。这使得客户端可以安全地管理 Blob 的检索。
我们从客户那里一直听到的最大的担忧是围绕着网络延迟:有了 Blobs,总的网络带宽有可能会大大增加。虽然这是预期的行为,但人们希望尽可能地降低这一变化的风险。
为了解决这个问题,我们计划通过在测试网和主网上创建持续数量的充满 CALLDATA 的区块,来模拟网络行为会是什么样子。这将显示网络上的节点如何处理这种负载。
根据测试结果,我们将调整目标 Blob 大小,以适应带宽限制,并添加任何额外的缓解措施。我们很高兴能得到一些真实的数据,以得知最终的适合 4844 的参数。
最后,大家讨论了跨执行层和共识层使用什么库来实现 KZG 承诺。我们一致认为默认的是 c-kzg 库(取决于 Blst),但客户也可以依靠平台特定的库。
在整个 Devcon 大会上,有很多关于 4844 的确切时间的讨论。虽然大多数客户团队将分片/扩展视为首要任务,但人们也强烈希望 4844 能有充足的资金顺利进行。
对于将 4844 纳入下一个硬分叉,没有做出正式的决定,但对这一想法持高度开放的态度。如何在规范和客户端代码库中最好地体现这一点仍在确定中。
基于这些反馈,工作组将全力以赴,在短期内,意味着实施 2-3 个其他客户端(Lodestar、Erigon、Nethermind),运行带宽测试,并启动 Devnet 3。
本月晚些时候,我们计划再做一次检查,以衡量我们的进展是否与上海硬分叉的时间轴保持一致。我们很乐观地认为,鉴于我们拥有强大的跨公司工作组,我们将能够很快完成 4844。
(全网:cropty悟饭~欢迎大家一起探讨~)