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。
微信扫一扫 
