本文讨论坎昆之后的下一个 EL 硬分叉布拉格, 从 Reth 团队的观点,应该包含哪些 EIP .
- 原文链接:https://www.paradigm.xyz/2024/01/ethereum-2024
- 译文出自:登链翻译计划
- 译者:翻译小组 > 校对:Tiny 熊
- 本文永久链接:learnblockchain.cn/article…
本文的目标是概述 Paradigm Reth 团队对于布拉格硬分叉的看法,布拉格(Prague)是坎昆之后的下一个 EL 硬分叉,以及我们 2024 年“EL 核心开发”计划的概况。以下观点正在发展中,仅代表 Reth 团队当前的观点,不一定代表更广泛的 Paradigm 团队。
我们认为布拉格硬分叉可能在 2024 年第三季度在以太坊测试网上实现,年底在主网上实现。
它应该包括:
支持:
不支持:
以下是推理。
抽象地说,我们支持 1)进一步弥合 CL 和 EL 之间的差距,2) EVM 修改可以作为单人工作执行,并且可以在隔离和并行测试。
这个 EIP 通过使 EL 侧的智能合约控制 CL 侧的一个或多个验证者,解锁了无信任的重新质押和质押池。从我们的角度来看,这是一个不需要思考的 EIP,因为至少它将使现有的质押池能够从实施其提款的智能合约中去除一层中心化。
在 EVM 实现中引入有状态的预编译是我们需要在 EVM 实现中捕获的新抽象,但除此之外,我们认为这是一个可以直接执行的 EIP。
这个 EIP 在 EL 状态中引入了存款,简化了 CL 上需要进行的状态管理。在实施上,这类似于跟踪 CL 提款,因此总体上我们认为这也是一个容易实现且独立的 EIP 。
现在外面有多个 BLS12-381 的实现,它是许多 SNARKs、BLS 签名算法和 EIP-4844 中经常使用的曲线。我们认为实现复杂性低,因为它只是通过预编译接口公开了曲线的验证算法。可能我们还想要一个 Hash 到 BLS12-381 曲线的预编译。
TL;DR:支持一个 Solidity 和 Vyper 将采用的范围明确的版本。使分析更容易的代码格式和验证调整是一个不需要思考的事情,我们建议进一步修剪。
好处:
不足:
我们认为以下 EOF 功能应该在 2024 年部署。我们建议尽快确定范围并承诺遵守。其他任何事情应该考虑后续部署。我们的建议:
我们对 EIP-6206: EOF - JUMPF and non-returning functions 的确定性较低。虽然它允许在 EOF 函数中进行尾调用优化,但我们仍需要看到语言分析其有用性。如果我们没有这个,我们认为可以将其从范围中剔除,并包含在后续 EOF 更新中。
我们将以上工作预算为 1-2 个月,由 1 人全职完成。如果这意味着保持动力,我们愿意进一步削减上述提到的范围。
关于传统字节码的说明:
我们愿意接受这一变化,这将对MAX_BLOB_GAS_PER_BLOCK
和TARGET_BLOB_GAS_PER_BLOCK
进行增加,有关上下文,请参阅 EIP-4844:
TARGET_BLOB_GAS_PER_BLOCK 和 MAX_BLOB_GAS_PER_BLOCK 的值被选择为每个块的目标为 3 个 blob(0.375 MB),最大为 6 个 blob(0.75 MB)。这些较小的初始限制旨在最大限度地减少此 EIP 对网络造成的压力,并且预计将在未来的升级中增加,以便网络在更大的块下表现出可靠性。*
实际上,这是一个小的代码更改,我们需要调查它在 txpool 中的实际影响,但我们认为我们可以重用 EIP-4844 的压力测试基础设施。共识层可能在传播更多 blob 时遇到困难;我们听取 CL 团队的意见。
TL;DR:我们认为没有办法在 2024 年底/2025 年初部署 Verkle tries。我们建议团队在 2024 年第二季度分配资源,并承诺在大阪硬分叉中在 2025 年第二季度至第三季度部署。
好处:
不足:
eth_getProof
行为应该怎样的?虽然我们理解 Verkle Tries 的好处,但我们认为需要更多的思考,以了解第三方工具/合约需要如何适应,以及过渡对例如第 2 层解决方案的影响。最初,我们对迁移策略持怀疑态度,因为它规定 Verkle trie 应在从现有 MPT 读取状态时进行更新,但现在似乎并非如此。因此,我们支持 Overlay 树方法作为可行的迁移路径。
Verkle 迁移策略的文档似乎普遍过时,因为大多数资源仍然指出 Verkle trie 应在从 MPT 读取状态时进行更新,尽管情况并非如此。我们希望看到关键的过渡文档更新为最新的方法,例如这篇优秀的文档 。我们还希望看到一份关于过渡策略的草案 EIP。
因此,我们仍然支持在 2025 年推出 Verkle,但在布拉格升级没有看到部署路径。
我们认为从引发需求的角度,提高 L1 gas 限制在实践中不会有太大作用。我们还认为大多数客户端可以处理平均负载的增加,但我们希望对最坏情况保持警惕,因此我们暂时不建议增加 L1 gas 限制。我们认为在短期内增加 blob gas 限制是更有前途的解决方案。
我们邀请大家与我们合作,进行任何关于这方向的研究,以及围绕突破 EVM 中的资源计量方式。Broken Metre paper 是这一研究方向的一个很好的起点。
我们愿意包含 1 个或多个这些 EIP(或协议实现 ERCs),但我们希望更理想地看到更多的用户体验和开发体验比较,以更好地理解各个提案的权衡空间和工具集成的工作量。我们正在关注以下 EIP/ERCs,但请随时向我们建议更多:
我们想要说明,在上述内容中,“账户抽象”指的是“抽象验证功能,主要目标是启用密钥轮换,使多签名成为一等功能,并为我们提供自动的量子抵抗路径”(h/t VB),只适用于 4337 和 7560,而其他提案则分为两个类别,即 gas 赞助和操作批处理。
作者:
Georgios Konstantopoulos 是 Paradigm 的首席技术官和研究合伙人,专注于 Paradigm 的投资组合公司和开源协议的研究。此前,Georgios 是一名独立顾问和研究人员。
本翻译由 DeCert.me 协助支持, 在 DeCert 构建可信履历,为自己码一个未来。
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!