Subscribe to Sffile
Subscribe to Sffile
<100 subscribers
<100 subscribers
Share Dialog
Share Dialog
以太坊核心开发者将于本周四召开电话会议，讨论是否将 EIP-4844 纳入考虑范围（CFI）。
对于很多致力于将该 EIP 投入生产的团队来说，这是一个重要的时刻!
以下是我认为应该将 EIP-4844 纳入考虑范围的原因。
提醒：EIP-4844 为以太坊的短期数据增加了一个新的费用市场, Rollup 将使用它来提高数据可用性。
这是以 Rollup 为中心的路线图的游戏规则改变者，因为费用可以降低约 100 倍。
TL;DR 为什么 4844 应该纳入考虑范围：
建立在提款基础上
规范~经过 9 个多月的迭代后已经完成
带压力测试的 Interop repo
KZG 仪式规范已完成 + 能工作的前端
KZG 库支持 Node、C#、Rust、Python 等
Devnet v3 将支持 6/9 主要客户端
让我解释一下每一部分。首先，EIP-4844 是建立在提款规范之上的。执行层和共识层的工作都直接建立在现有的提款实施之上。不需要重新建立，它纯粹是附加的。
该规范经过 9 个月的密集迭代，其余的更改已经非常少了。
大多数客户端团队已经审查（甚至实施）了它！此外，还有互补的共识层和 engine API 规范。
https://github.com/ethereum/execution-apis/blob/main/src/engine/blob-extension.md
在互操作性方面，开发者们进行了大量的工作，这导致了多个不同的开发者测试网（devnet），并且 Georgios Konstantopoulos 进行了额外的网络压力测试。不过，保守地说，我们已经减少了初始迭代的 blobs 参数。
https://github.com/Inphi/eip4844-interop
在 KZG 可信设置仪式方面，我们已经准备就绪。
有一个已完成的规范，包含三个前端实现，并实现和审核了排序器。
https://github.com/ethereum/kzg-ceremony-specs
为了使实施更流畅、更可靠，我们在 KZG 库方面也取得了重大进展。C-kzg-4844 处于活动状态，并使用 NodeJS、CSharp、Python 以及正在进行的 Rust 绑定实现所需的组件。Go-KZG 已准备就绪。
https://github.com/ethereum/c-kzg-4844/
我们在开发者测试网（devnet）方面也取得了巨大进展。
下一个 devnet v3 将支持 9 个主要客户端中的 6 个（不错），应该会在 11 月 30 日准备就绪。
https://notes.ethereum.org/@timbeiko/4844-devnet-3
一直以来，社区和生态系统始终与不断发展的公共站点保持同步，该公共站点包含了所有这些信息，并且已经持续了将近一年。
在我看来，EIP-4844 是合并（The Merge）之后最有希望为以太坊的未来做出贡献的 EIP。
几只 L2 团队、来自以太坊基金会的各种核心开发人员、大型 crypto 业务以及主要的新项目都为它做出了贡献，因为我们希望看到以太坊获胜。
现在，我想补充的是，CFI 并不意味着「包含」在下一次硬分叉升级中。关于上海升级的决定是一个独立的过程。
然而，考虑到 EIP-4844 以及提款都涉及到了共识层和执行层，似乎有很好的理由考虑将其纳入上海升级。
无论如何，我希望在即将到来的 ACD 电话会议中，我们能够了解 EIP-4844 的情况，并对 CFI 地位的合理性做出强有力的判断！
如果你对这个 EIP 有任何想法，并希望在下一次 ACD 电话会议上发表意见，请查看议程:
以太坊核心开发者将于本周四召开电话会议，讨论是否将 EIP-4844 纳入考虑范围（CFI）。
对于很多致力于将该 EIP 投入生产的团队来说，这是一个重要的时刻!
以下是我认为应该将 EIP-4844 纳入考虑范围的原因。
提醒：EIP-4844 为以太坊的短期数据增加了一个新的费用市场, Rollup 将使用它来提高数据可用性。
这是以 Rollup 为中心的路线图的游戏规则改变者，因为费用可以降低约 100 倍。
TL;DR 为什么 4844 应该纳入考虑范围：
建立在提款基础上
规范~经过 9 个多月的迭代后已经完成
带压力测试的 Interop repo
KZG 仪式规范已完成 + 能工作的前端
KZG 库支持 Node、C#、Rust、Python 等
Devnet v3 将支持 6/9 主要客户端
让我解释一下每一部分。首先，EIP-4844 是建立在提款规范之上的。执行层和共识层的工作都直接建立在现有的提款实施之上。不需要重新建立，它纯粹是附加的。
该规范经过 9 个月的密集迭代，其余的更改已经非常少了。
大多数客户端团队已经审查（甚至实施）了它！此外，还有互补的共识层和 engine API 规范。
https://github.com/ethereum/execution-apis/blob/main/src/engine/blob-extension.md
在互操作性方面，开发者们进行了大量的工作，这导致了多个不同的开发者测试网（devnet），并且 Georgios Konstantopoulos 进行了额外的网络压力测试。不过，保守地说，我们已经减少了初始迭代的 blobs 参数。
https://github.com/Inphi/eip4844-interop
在 KZG 可信设置仪式方面，我们已经准备就绪。
有一个已完成的规范，包含三个前端实现，并实现和审核了排序器。
https://github.com/ethereum/kzg-ceremony-specs
为了使实施更流畅、更可靠，我们在 KZG 库方面也取得了重大进展。C-kzg-4844 处于活动状态，并使用 NodeJS、CSharp、Python 以及正在进行的 Rust 绑定实现所需的组件。Go-KZG 已准备就绪。
https://github.com/ethereum/c-kzg-4844/
我们在开发者测试网（devnet）方面也取得了巨大进展。
下一个 devnet v3 将支持 9 个主要客户端中的 6 个（不错），应该会在 11 月 30 日准备就绪。
https://notes.ethereum.org/@timbeiko/4844-devnet-3
一直以来，社区和生态系统始终与不断发展的公共站点保持同步，该公共站点包含了所有这些信息，并且已经持续了将近一年。
在我看来，EIP-4844 是合并（The Merge）之后最有希望为以太坊的未来做出贡献的 EIP。
几只 L2 团队、来自以太坊基金会的各种核心开发人员、大型 crypto 业务以及主要的新项目都为它做出了贡献，因为我们希望看到以太坊获胜。
现在，我想补充的是，CFI 并不意味着「包含」在下一次硬分叉升级中。关于上海升级的决定是一个独立的过程。
然而，考虑到 EIP-4844 以及提款都涉及到了共识层和执行层，似乎有很好的理由考虑将其纳入上海升级。
无论如何，我希望在即将到来的 ACD 电话会议中，我们能够了解 EIP-4844 的情况，并对 CFI 地位的合理性做出强有力的判断！
如果你对这个 EIP 有任何想法，并希望在下一次 ACD 电话会议上发表意见，请查看议程:
No activity yet