作者：Georgios Konstantopoulos，Paradigm；编译：松雪，金色财经

TL;DR

这篇文章的目的是概述 Paradigm Reth 团队对哪些 EIP 应该包含在布拉格、坎昆之后的下一个 EL 硬分叉以及我们 2024 年“EL Core Dev”总体计划的看法。 以下观点正在不断发展，仅代表 Reth 团队当前的观点，并不**代表 Paradigm 团队。

我们认为布拉格硬分叉可能会在 2024 年第三季度在以太坊测试网上实现，并在年底在主网上实现。 它应该包括：

• **与质押相关的 EIP，例如 EIP-7002，它支持重新质押和无需信任的质押池。

• 

  孤立的 EVM 变化。

• 我们愿意与**想要进一步调查布拉格或其他未来 EL 硬分叉的难题的团队合作，并乐意指导或提供修改 Reth 代码库的指导。

做什么：

• 我们认为以下EIP必须优先考虑：7002、6110、2537。

• 我们支持规范中描述的 EOF，但希望尽快确定范围，并创建一个致力于该范围的元 EIP。

• 我们愿意增加 EIP-4844 Max Blob Gas。 我们对正确的数字没有看法，但我们邀请数据人员与我们合作调查这个主题。

• 我们愿意发布 EIP-7547 的版本：包含列表，以帮助抵抗基础层审查。

不做什么：

• 我们不支持布拉格的 Verkle Tries，但支持客户团队在 2024 年第二季度开始为此努力，并承诺于 2025 年中/下旬在大阪升级发布。

• 我们认为不应该增加 L1 执行 Gas 限制或合约规模，但我们邀请数据人员与我们合作调查对网络的影响。 我们愿意修改我们的看法，因为过去的测试表明 Reth 节点可以毫无问题地处理增加的负载。

• 我们认为钱包/账户抽象 EIP 需要进行更多的相互对抗测试，以更好地了解权衡空间。 如果它们不相互排斥，那么我们将愿意在未来部署多个与 ** 相关的 EIP。

• 如果社区同意传闻中的 NSA 后门，我们就可以越过 EIP-7212 (secp256r1) 的线路。

• 其他路线图主题：我们对 CL EIP 或 CL/EL 分叉的耦合没有实际的看法，但 EIP 7549 和 7251 似乎很有前途。 我们还希望尽可能从 EL 方面为 PeerDAS 的工作做出贡献。 目前我们希望避免引入 SSZ 根（EIP 6404、6465、6466）。 **，我们观察到，有机会为过期的 blob、历史记录和状态提供长期数据归档解决方案，因为 EIP-4844 和 EIP-4444 都没有指定这一点，而且以太坊是否愿意提供这样的解决方案还有待确定。

以下是内容详述。

要做什么：

抽象地说，我们支持 1) 进一步缩小 CL 和 EL 之间的差距，2) EVM 修改可以作为 1 人作业执行，并且可以单独和并行测试。

EIP-7002

该 EIP 通过使 EL 侧的智能合约能够控制 CL 侧的 1 个或多个验证器来解锁无需信任的重新质押和质押池。 从我们的角度来看，EIP 是理所当然的，至少它将使现有的质押池能够从实现提款的智能合约中**一层**化。

将有状态预编译引入 EVM 是我们需要在 EVM 实现中捕获的新抽象，但除此之外，我们认为这是一个可以直接执行的 EIP。

EIP-6110

这引入了 EL 状态中的存款，简化了需要在 CL 上完成的状态管理。 在实施方面，这类似于跟踪 CL 提款，因此总的来说，我们认为这也是一个易于实施且隔离的 EIP。

EIP-2537

目前 BLS12-381 有多种实现，它是许多 SNARK、BLS 签名算法和 EIP-4844 中经常使用的曲线。 我们认为实现复杂度较低，因为它只是通过预编译接口公开曲线的验证算法。 我们可能还需要 BLS12-381 曲线预编译的哈希值。

EOF

TL;DR：支持 Solidity 和 Vyper 将采用的范围广泛的版本。 使分析变得更容易的代码格式和验证调整是理所当然的，我们建议仔细考虑除此之外的**内容。 我们在下面推荐了一些 EIP，但我们愿意进一步调整。

好的方面：

• ** EVM 的更改，可以使用以太坊进行测试并由 1 人实施。

• Vyper 和 Solidity 想要的 EVM 改变！

• 有助于提高绩效并增加合同规模限制。

• **了 EVM 在运行时进行字节码分析的需要，在不涉及缓存的情况下，分析的时间可能高达 50%，并且随着合约大小的增加而增加。

• 启用部分代码加载，有助于执行大型智能合约。

• Devex：将允许通过 dupN/swapN 和其他工具改进来修复“堆栈太深”的问题。

• 面向未来：可以安全地跨 L2 引入新功能，并且工具会知道什么是兼容的。

坏的方面：

• 范围和动态目标。

• 没有支持者大力推动将其纳入其中。

• **代码仍然需要支持。

• 在采用之前，以太坊主网和其他 EVM 链之间存在暂时分歧。

我们认为以下 EOF 功能应在 2024 年部署。我们建议尽快确定范围并承诺实施。 后续部署应该考虑其他**事情。 我们的建议：

• EIP-3540：EOF - EVM 对象格式 v1：引入代码和数据容器，并向以太坊字节码添加结构和版本控制。

• EIP-3670：EOF - 代码验证：拒绝部署时不遵循 EOF 格式的**合约。 实施更结构化的代码并禁用无效和未定义的指令。

• EIP-663：**的 SWAP 和 DUP 指令：这解决了可靠性中的“堆栈太深”问题，JUMPDEST 分析作为即时值可能会产生副作用。 evm langs 非常想实现的功能。

• EIP-4200：EOF - 静态相对跳转：更好的静态分析，没有不确定的跳转。 更好的 aot 编译。 相对跳转更有利于代码的可重用性。

• EIP-4750：EOF - 功能：需要解决可以使用动态跳转但不能使用静态跳转的子例程。 它还允许部分代码加载，这与 Verkle 配合良好并增加了合约大小限制。

• EIP-5450：EOF - 堆栈验证：验证代码和堆栈要求。 删除除 CALLF 之外的所有指令的运行时堆栈下溢和溢出检查 (EIP-4750)。

• EIP-7480：EOF - 数据部分访问指令：允许访问字节码的数据部分。

• EIP-7069：改进的 CALL 指令：能够从 CALL 中删除 Gas 可观察性，从而使将来更容易重新定价 Gas。 虽然独立于 EOF，但我们认为这是引入它的好机会。

我们对 EIP-6206 不太确定：EOF - JUMPF 和非返回函数。 虽然它允许在 EOF 函数中进行尾部调用优化，但我们仍然需要看到语言分析其有用性。 如果我们没有，我们认为可以将其从范围中删除并包含在后续 EOF 更新中。

我们将上述工作强度为 1 人全职工作 1-2 个月。 如果这意味着保持势头，我们愿意进一步缩小上述范围。

关于**字节码的注释：

• 虽然我们可以禁止新的**/非 EOF 字节码，但无法弃用现有的**字节码，它实际上充当 EOF“v0”。 **字节码仍然需要 EOF 后的 JUMPDEST 分析，并且仍然需要特殊的代码处理以将其分段为 Verkle Tries 中的块。

• 据我们所知，如果不访问源代码，就无法验证从非 EOF 字节码到 EOF 的转换，但我们愿意研究促进这种转换的机制。

• 或者，我们愿意探索强制状态迁移到 EOF 的到期方法。

增加 EIP-4844 Blob 计数

我们对这一更改持开放态度，这对应于 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 压力测试基础设施。 CL 可能很难传播更多的 blob； 我们尊重 CL 队伍的意见。

不做什么：

Verkle Tries

TL;DR：我们看不到 2024 年底/2025 年初部署 Verkle 尝试的路径。 我们建议团队在 2024 年第二季度为此分配资源，并承诺在 2025 年第二季度至第三季度在大阪硬分叉中部署。

好的方面：

• 通过更小的存储证明实现更便宜的轻客户端。

• 通过在块的标头中包含读取预状态来进行无状态执行，这也可能由于静态状态访问而导致性能提高。

• 通过对字节码进行分块并启用部分代码加载来提高合约大小限制。

• 由于“恢复”状态的成本较低，状态到期变得更容易接受。

坏的方面：

• 实施和测试的变更和集成工作的影响。

• Gas 核算变化：Verkle 尝试将见证人的大小引入到 Gas 计算功能中。 我们担心存储定价的变化尚未被探索（例如，Verkle 后**Gas消耗企业的成本是多少）？

• 应用程序集成：当 Overlay 转换运行时，带有 Merkle Patricia Trie 验证器的应用程序应该做什么？ eth_getProof 应该如何表现？

虽然我们了解 Verkle Tries 的好处，但我们认为需要更多地考虑第 3 方工具/合同需要如何适应，以及过渡会对Layer2产生什么影响。 最初我们对迁移策略有疑问，因为它规定当从预先存在的 MPT 读取状态时应该更新 Verkle trie，但情况似乎不再如此了。 因此，我们支持Overlay方法作为可行的迁移路径。

Verkle 迁移策略的文档通常似乎已经过时，因为大多数资源仍然指出从 MPT 读取状态时应该更新 Verkle trie，即使事实并非如此。 我们希望看到关键的过渡文档使用**的方法进行更新，例如这个**的文档。 我们还希望看到有关过渡战略的生态投资计划草案。

因此，我们仍然支持其在 2025 年推出，但不是在布拉格硬分叉进行部署。

L1 Gas限制

我们认为，由于诱导需求，提高 L1 Gas 限制在实践中不会产生太大作用。 我们还认为大多数客户可以应对平均负载增加，但我们希望对最坏的情况保持警惕，因此我们尚不建议增加 L1 Gas 限制。 我们认为增加 blob Gas 限制是短期内更有希望的解决方案。

我们邀请人们与我们合作进行该方向的**研究，通常围绕打破 EVM 中的资源计量进行。 《Broken Metre: Attacking Resource Metering in EVM》论文是这一研究领域的一个很好的起点。

账户抽象

我们愿意包含 1 个或多个 EIP（或纳入 ERC），但我们理想地希望看到每个提案之间有更多的 UX 和 DevEx 比较，以更好地了解工具集成的权衡空间和工作量。 我们正在关注以下 EIP/ERC，但请随时向我们建议更多：

• EIP-3074：AUTH 和 AUTHCALL 操作码；

• ERC-4337：使用 Alt Mempool 进行账户抽象；

• EIP-5806：委托交易；

• EIP-5920：PAY 操作码；

• EIP-6913：SETCODE 指令；

• EIP-7377：迁移事务；

• RIP-7560：本机帐户抽象 - 核心 EIP - Fellowship of Ethereum Magicians。

我们想在上面警告一下，“帐户抽象”就像“抽象验证函数，主要目标是启用密钥轮换，使多重签名成为**，并为我们提供一条自动实现量子抗性的路径” (h/t VB) 仅适用于上面的 4337 和 7560。