作者： 币安app官方 日期：2024-06-19 07:47
这篇文章的目的是概述 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 需要进行更多的相互对抗测试，以更好地了解权衡空间。 如果它们不相互排斥，那么我们将愿意在未来部署多个与 AA 相关的 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 通过使 EL 侧的智能合约能够控制 CL 侧的 1 个或多个验证器来解锁无需信任的重新质押和质押池。 从我们的角度来看，EIP 是理所当然的，至少它将使现有的质押池能够从实现提款的智能合约中消除一层中心化。
将有状态预编译引入 EVM 是我们需要在 EVM 实现中捕获的新抽象，但除此之外，我们认为这是一个可以直接执行的 EIP。
这引入了 EL 状态中的存款，简化了需要在 CL 上完成的状态管理。 在实施方面，这类似于跟踪 CL 提款，因此总的来说，我们认为这也是一个易于实施且隔离的 EIP。
目前 BLS12-381 有多种实现，它是许多 SNARK、BLS 签名算法和 EIP-4844 中经常使用的曲线。 我们认为实现复杂度较低，因为它只是通过预编译接口公开曲线的验证算法。 我们可能还需要 BLS12-381 曲线预编译的哈希值。
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 的到期方法。
我们对这一更改持开放态度，这对应于 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 队伍的意见。
不做什么：
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 限制。 我们认为增加 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。
