Paradigm：以太坊坎昆硬分叉之后会发生什么？

TL;DR

这篇文章的目的是概述 Paradigm Reth 团队对哪些 EIP 应该包含在 Prague、坎昆升级之后的下一个 EL 硬分叉以及关于 2024 年「EL Core Dev」总体计划的看法。以下观点是不断变化的，仅代表 Reth 团队当前的观点，不一定代表更广泛的 Paradigm 团队。

我们认为Prague硬分叉有可能于 2024 年第三季度在以太坊测试网上进行，并于年底在主网上进行。它应该包括：

任何与质押相关的 EIP，如 EIP-7002，它可以实现重新质押和无信任质押池；

孤立的 EVM 变化。

我们愿意与任何希望进一步研究Prague或其他未来 EL 硬分叉问题的团队合作，并欢迎指导或提供有关修改 Reth 代码库的指导。

支持：

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

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

我们对增加 EIP-4844 Max Blob Gas 持开放态度。我们对合适的数字还没有定论，但我们邀请数据人员与我们一起研究该问题。

我们愿意提供 EIP-7547 版本：纳入列表，以帮助抵制基础层审查。

不支持：

我们不支持在Prague中的 Verkle Tries，但支持客户团队在 2024 年第 2 季度开始努力，并承诺在 2025 年中/末在 Osaka 中交付。

我们认为不应增加 L1 执行Gas限额或合约规模，但我们邀请数据人员与我们合作，共同调查对网络的影响。由于过去的测试表明 Reth 节点可以顺利处理增加的负载，因此我们愿意修改我们的观点。

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

如果社区对传言中的NSA后门没有意见，我们可能会在 EIP-7212 (secp256r1) 中取得突破。

其他路线图主题： 我们对 CL EIP 或 CL/EL 分叉的耦合没有实际看法，但 EIP 7549 和 7251 似乎很有前途。我们还希望在可能的情况下，从 EL 方面为 PeerDAS 的工作做出贡献。目前，我们希望避免引入 SSZ 根（EIP 6404、6465、6466）。最后，我们注意到，EIP-4844 和 EIP-4444 均未指定过期 blob、历史和状态的长期数据存档解决方案，而以太坊是否愿意提供这样的解决方案尚待确定。

支持

摘要：我们支持 1) 进一步缩小 CL 和 EL 之间的差距；2) EVM 修改可作为单人工作执行，并可进行隔离和并行测试。

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

简而言之：支持 Solidity 和 Vyper 将采用的范围明确的版本。代码格式和验证调整可使分析更容易，这一点毋庸置疑。我们建议仔细考虑除此之外的任何内容。我们在下面推荐了一些 EIP，但我们愿意进一步调整。

优势：

仅对 EVM 进行更改，可通过以太坊/测试进行测试，并由一人实施。

Vyper 和 Solidity 想要的 EVM 更改！

有助于提高性能和增加合约大小限制。

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

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

Devex： 将允许使用 dupN/swapN 修复 solidity 中的 “堆栈过深”问题，并改进其他工具。

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

劣势：

范围和移动目标。

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

遗留代码仍需支持。

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

我们认为应在 2024 年部署以下 EOF 功能。我们建议尽快确定范围，并做出承诺。其他内容应考虑后续部署。我们的建议：

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

EIP-3670： EOF - 代码验证： 在部署时拒绝任何不遵循 EOF 格式的合约。强化代码结构，禁用无效和未定义的指令。

EIP-663： 无限制 SWAP 和 DUP 指令： 这解决了 solidity 中的 “堆栈过深 ”问题，并通过 JUMPDEST 分析，因为即时值可能会产生副作用。evm langs 非常需要。

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

EIP-4750: EOF - 函数： 需要解决可使用动态跳转但不能使用静态跳转的子程序问题。它还允许部分代码加载，这与 Verkle 和增加合约大小限制很好地配合。

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

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

EIP-7069： 改造后的 CALL 指令：可移除 CALL 中的Gas可观察性，从而在未来更容易进行Gas重新定价。虽然与 EOF 无关，但我们认为这是引入 EOF 的好机会。

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

我们将上述工作预算为 1-2 个月，由 1 名全职人员完成。如果能保持势头，我们愿意进一步缩减上述范围。

关于遗留字节码的说明：

虽然我们可以禁止新的遗留/非 EOF 字节码，但无法废除现有的遗留字节码，因为它们实际上是 EOF "v0"。遗留字节码在 EOF 后仍需要 JUMPDEST 分析，在 Verkle Tries 中仍需要特殊代码处理来将其分割成块。

据我们所知，在无法访问源工件的情况下，没有可验证的方法将非 EOF 字节代码转换为 EOF，但我们愿意研究促进这种转换的机制。

另外，我们也愿意探索强制将状态迁移到 EOF 的老方法。

增加 EIP-4844 Blob 数量

我们对这一更改持开放态度，这相当于增加 EIP-4844 的 MAX_BLOB_GAS_PER_BLOCK 和 TARGET_BLOB_GAS_PER_BLOCK：

> 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 尝试

TL;DR：我们认为 Verkle tries 无法在 2024 年底/2025 年初部署。我们建议团队在 2024 年第二季度为此分配资源，并承诺在 2025 年第二季度至第三季度的Osaka硬分叉中进行部署。

优势：

通过更小的存储证明，使轻量级客户端更便宜。

通过在代码区块的头中包含读取预状态来实现无状态执行，这也可能通过静态状态访问来提高性能。

通过分块字节码和启用部分代码加载，提高合约大小限制。

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

劣势：

变化的影响以及实施和测试的整合工作。

Gas核算更改： Verkle 尝试将证人的大小引入Gas计算功能。我们担心尚未对存储定价的变化进行探讨（例如，Verkle 推出后，顶级Gas消耗者的成本会是多少）？

应用集成： 在叠加过渡运行期间，使用 Merkle Patricia Trie 校验器的应用程序应该做些什么？eth_getProof 应该如何运行？

虽然我们理解 Verkle Tries 的好处，但我们认为需要更多考虑第三方工具/合约需要如何调整，以及过渡对第 2 层解决方案等的影响。起初，我们对迁移策略存有疑虑，因为该策略规定，当从先前存在的 MPT 中读取状态时，Verkle trie 应进行更新，但现在似乎不再是这样了。因此，我们支持将覆盖树方法作为一种可行的迁移路径。

一般来说，Verkle 迁移策略的文档似乎已经过时，因为大多数资源仍然指出，当从 MPT 中读取状态时，Verkle 三元组应该更新，尽管事实并非如此。我们希望看到用最新方法更新关键转换文档，比如这份出色的 文档 。我们还希望看到关于过渡策略的 EIP 草案。

因此，我们仍然支持在 2025 年推出，但看不到在Prague部署的路径。

L1 Gas限制

我们认为，由于需求诱导，提高 L1 Gas限值在实践中不会有太大作用。我们还认为，大多数客户都能承受平均负载的增加，但我们希望对最坏的情况保持警惕，因此我们还不能建议提高 L1 Gas限制。我们认为，在短期内，增加 Blob Gas限制是一个更有前途的解决方案。

我们邀请大家与我们合作，共同开展这方面的研究，以及围绕打破 EVM 中资源计量的总体研究。Broken Metre论文是这一研究方向的良好起点。

账户抽象

我们对纳入其中一个或多个 EIP（或将 ERC 纳入其中）持开放态度，但我们更希望看到每个提案之间更多的用户体验和 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，而其他建议则分为两类，即Gas赞助和批量操作。