摘要
这篇文章的目的是概述 Paradigm Reth 团队对于哪些 EIP（以太坊改进提案）应该被包含在布拉格（Prague）中的观点，布拉格是继坎昆之后的下一个 EL（以太坊执行层）硬分叉，以及我们 2024 年的“EL 核心开发者”计划概况。以下观点仍在不断发展中，仅代表 Reth 团队当前的看法，不一定代表更广泛的 Paradigm 团队的观点。
我们认为，在 2024 年第三季度，布拉格硬分叉在以太坊测试网上是可行的，并且在年底之前可以在主网实施。它应该包括：
（1）与质押相关的 EIPs，例如 EIP-7002，它使得再质押（re-staking）和无需信任的质押池成为可能。
（2）独立的 EVM 变更。
（3）我们愿意与任何想要进一步探究布拉格或其他未来 EL 硬分叉的困难问题的团队合作，乐于提供指导或接收对 Reth 代码库进行修改的建议。
建议事项：
（1）我们认为以下 EIP 应优先考虑：7002、6110、2537。
（2）我们支持 EOF 如规范中所描述，但希望尽快确定范围并创建一个 meta-EIP 来承诺这一范围。（注：EOF 代表 EVM 对象格式，其对以太坊的代码执行环境进行了一些更改。有开发者提议将 EOF 纳入下次执行层升级 Prague 中，但目前观点不一，有些认为其规范尚未最终确定，有些认为 Verkle Tries 才是下次升级的重点）
（3）我们对增加 EIP-4844 最大 Blob Gas 持开放态度。我们对正确数字没有具体看法，但邀请数据领域的专家与我们合作调查这个主题。（注：Blob 是一种用于存储 L2 向 L1 提交交易数据的存储结构，并拥有自己的定价系统 Blob Gas）
（4）我们对推出 EIP-7547: 包含列表（Inclusion lists）持开放态度，以帮助提高基层审查抵抗力。
不建议事项：
（1）我们不支持在布拉格中引入 Verkle Tries，但支持客户端团队从 2024 年第二季度开始朝这个方向努力，并承诺在 2025 年中/晚期的大阪（Osaka）中实施它。（注：未来以太坊将转向的一种数据结构，相比当前的 Merkle Trie 结构，Verkle 有证明大小和验证效率等方面优势，是未来以太坊实现无状态不可缺少的一环）
（2）我们认为不应该增加 L1 执行 Gas 限制或合约大小，但我们邀请数据专家与我们合作研究这对网络的影响。我们对此持开放态度，因为过去的测试显示 Reth 节点可以在不出问题的情况下处理增加的负载。
（3）我们认为钱包/账户抽象的 EIP 需要更多相互间的实战测试，以更好地了解它们之间的权衡空间。如果它们不是相互排斥的，那么我们未来愿意部署多个与 AA（账户抽象）相关的 EIP。
（4）对于 EIP-7212（secp256r1），如果社区对传闻中的 NSA（美国国家安全局）后门没有意见，我们可能会支持它。
（5）其他路线图主题：我们对 CL（共识层）EIP 或 CL/EL（执行层）分叉的耦合没有直接的看法，但 EIP-7549 和 EIP-7251 看起来很有前景。我们也愿意在可能的情况下，从 EL 方面贡献于 PeerDAS 的工作。我们目前希望避免引入 SSZ 根（EIP-6404、6465、6466）。最后，我们注意到，对于过期的 blobs、历史和状态，有一个长期的数据存档解决方案的机会，因为 EIP-4844 和 EIP-4444 都没有指定这一点，而以太坊是否想提供这样的解决方案还有待确定。
具体理由如下
建议事项
我们支持1）进一步缩小共识层（CL）和执行层（EL）之间的差距；2）EVM 的修改，这些修改可以作为单人工作执行，并且可以隔离和并行地进行测试。
EIP-7002
这个 EIP 通过允许执行层（EL）的智能合约控制共识层（CL）的一个或多个验证器，解锁了无需信任的再质押和质押池。从我们的角度来看，这是一个不费思考的 EIP，因为它至少可以使现有的质押池从实施其提款的智能合约中去除一个集中化层。
我们需要在 EVM 实现中捕获到引入状态预编译的新抽象，但除此之外，我们认为这是一个可以直接执行的 EIP。
EIP-6110
这个 EIP 在执行层（EL）状态中引入了存款，简化了在共识层（CL）上需要进行的状态管理。从实现的角度来看，这类似于追踪共识层的提款，所以总的来说，我们认为这也是一个容易实施且独立的 EIP。
EIP-2537
目前市面上已经有多种 BLS12-381 的实现，它是在许多 SNARKs（零知识证明技术）、BLS 签名算法和 EIP-4844 中频繁使用的曲线。我们认为实现复杂度较低，因为它只是在预编译接口上公开了曲线的验证算法。我们可能还需要 BLS12-381 曲线预编译的哈希算法。
EOF
简要总结：支持 Solidity 和 Vyper 会采用的明确范围版本。代码格式和验证调整使分析变得更容易，这是毋庸置疑的选择，我们建议对此之外的任何内容进行仔细考虑。我们在下面推荐了一些 EIP，但我们也愿意进一步精简。
好处：
（1）仅限 EVM 的变更，可以通过 ethereum/tests 进行测试，并由一个人实施。
（2）Vyper 和 Solidity 想要的 EVM 变更。
（3）有助于提高性能和增加合约大小限制。
（4）无需 EVM 在运行时进行字节码分析，在不涉及缓存的情况下，这种分析可能需要多达 50% 的时间，并随着合约大小的增加而增加。
（5）支持部分代码加载，有助于执行大型智能合约。
（6）开发者体验：将允许在 solidity 中使用 dupN/swapN 修复 "堆栈过深 "问题，并改进其他工具。
（7）未来验证：可以在 L2s 中安全地引入新功能，并且工具知道哪些是兼容的。
不足之处：
（1）范围和移动目标。
（2）没有支持者大力推动将其纳入。
（3）仍需支持遗留代码。
（4）在被采用之前，以太坊主网与其他 EVM 链之间暂时存在分歧。
我们认为以下 EOF 功能应该在 2024 年部署。我们建议尽快确定范围并承诺坚持。其他内容应考虑用于后续部署。我们的建议：
（1）EIP-3540：EOF - EVM 对象格式 v1：引入代码和数据容器，并为以太坊字节码添加结构和版本控制。
（https://eips.ethereum.org/EIPS/eip-3540）
（2）EIP-3670：EOF - 代码验证：拒绝部署时不遵循 EOF 格式的合约。强制实施更加结构化的代码，并禁用无效和未定义的指令。
（https://eips.ethereum.org/EIPS/eip-3670）
（3）EIP-663：无限制的 SWAP 和 DUP 指令：这解决了 Solidity 中的“堆栈过深”问题，因为 JUMPDEST 分析作为立即值可能会产生副作用。这对 EVM 语言非常有益。
（https://eips.ethereum.org/EIPS/eip-663）
（4）EIP-4200：EOF - 静态相对跳转：更好的静态分析，没有不确定的跳转。更好的 AOT 编译。相对跳转更有利于代码重用。
（https://eips.ethereum.org/EIPS/eip-4200）
（5）EIP-4750：EOF - 函数：需要解决可使用动态跳转但不能使用静态跳转的子程序问题。它还允许部分代码加载，这与 Verkle 和增加合约大小限制的功能配合得很好。
（https://eips.ethereum.org/EIPS/eip-4750）
（6）EIP-5450：EOF - 堆栈验证：验证代码和堆栈要求。除了 CALLF（EIP-4750）指令外，移除所有指令的运行时堆栈下溢和上溢检查。
（https://eips.ethereum.org/EIPS/eip-5450）
（7）EIP-7480：EOF - 数据段访问指令：允许访问字节码的数据段。
（https://eips.ethereum.org/EIPS/eip-7480）
（8）EIP-7069：改进的 CALL 指令：使得从 CALLs 中移除 Gas 可观测性成为可能，这有助于未来更容易地对 Gas 进行重新定价。虽然与 EOF 无关，但我们认为这是引入它的好机会。
（https://eips.ethereum.org/EIPS/eip-7069）
关于 EIP-6206：EOF - JUMPF 和非返回函数，我们的看法不那么确定。虽然它允许在 EOF 函数中进行尾部调用优化，但我们仍需要看到语言分析其有效性。如果没有这种分析，我们认为从范围中剔除它，并在后续的 EOF 更新中包含它是可行的。
我们预计上述工作由一人全职进行，需要 1-2 个月的时间。如果缩减上述提到的范围意味着保持进展，我们愿意进一步缩减。
关于遗留字节码的说明：
（1）虽然我们可以禁止新的遗留/非 EOF 字节码，但没有办法淘汰现有的遗留字节码，这实际上充当了 EOF 的“v0”版本。遗留字节码在 EOF 之后仍然需要 JUMPDEST 分析，并且在 Verkle Tries 中将其分段仍然需要特殊的代码处理。
（2）据我们所知，没有办法在没有源代码工件的情况下，将非 EOF 字节码可验证地转换为 EOF，但我们愿意探索促进此类转换的机制。
（3）另外，我们也愿意探索强制将状态迁移到 EOF 的失效方法。
增加 EIP-4844 Blob 数量
我们对这一变更持开放态度，这将相应地增加 MAX_BLOB_GAS_PER_BLOCK（每个区块的最大 Blob Gas 限制）和 TARGET_BLOB_GAS_PER_BLOCK（每个区块的目标 Blob Gas 限制）。
以 EIP-4844 为背景：TARGET_BLOB_GAS_PER_BLOCK 和 MAX_BLOB_GAS_PER_BLOCK 的值被选定为对应于每个区块 3 个blobs（0.375 MB）的目标和 6 个blobs（0.75 MB）的最大值。这些小的初始限制旨在最小化这个 EIP 对网络造成的压力，并预计将在未来的升级中增加，因为网络在更大区块下展示出可靠性。
实际上这是一个小的代码变更，我们需要调查其在交易池中的实际影响，但我们认为可以重用 EIP-4844 的压力测试基础设施来进行这项工作。CL（共识层）可能在传播更多 blobs 方面有更大的困难；我们听从 CL 团队的意见。
不建议事项：
Verkle Tries
我们看不到在 2024 年底到 2025 年初部署 Verkle tries 的路径。我们建议团队在 2024 年第二季度为此分配资源，并承诺在 2025 年第二季度至第三季度的大阪硬分叉中进行部署。
好处：
（1）通过更小的存储证明，实现更便宜的轻客户端。
（2）通过在区块头部包含读取预状态实现无状态执行，这也可能由于静态状态访问而带来性能提升。
（3）通过分块字节码和启用部分代码加载，提高合约大小限制。
（4）随着“revive”状态的成本降低，状态过期变得更加可行。
不足之处：
（1）变更的影响以及实施和测试的整合工作量。
（2）Gas 计算更改：Verkle tries 引入了见证大小到 Gas 计算函数中。我们担心尚未对存储定价的变化进行探讨（例如，Verkle 之后，顶级 Gas 消耗者的成本会是多少）。
（3）应用集成：在 Overlay 转换运行期间，带有 Merkle Patricia Trie 验证器的应用应该做些什么？eth_getProof 应该如何表现？
尽管我们理解 Verkle tries 的好处，但我们认为需要更多的思考关于第三方工具/合约需要如何适应，以及转换将对例如 Layer 2 解决方案等产生什么影响。最初我们对迁移策略表示怀疑，因为它规定当从现有的 MPT（Merkle Patricia Trie）读取状态时，应该更新 Verkle tries，但现在似乎不再是这种情况。因此，我们支持 overlay tree 方法作为一种可行的迁移路径。
有关 Verkle 迁移策略的文档总体上似乎已经过时，因为大多数资源仍然指出，当从 MPT 中读取状态时，Verkle trie 应该更新，尽管事实并非如此。我们希望看到用最新方法更新关键转换文档（如：https://notes.ethereum.org/@parithosh/verkle-transition）。我们还希望看到关于过渡策略的 EIP 草案。
因此，我们仍然支持在 2025 年推出，但不认为它应该在布拉格分叉中部署。
L1 Gas 限制
我们认为，由于派生需求，提高 L1 Gas 限值在实践中不会有太大作用。我们还认为，大多数客户端可以处理平均负载增加，但我们希望对最坏的情况保持警惕，因此我们还不能建议提高 L1 Gas 限制。我们认为，在短期内，增加 Blob Gas 限制是一个更有前途的解决方案。
账户抽象
我们对纳入其中一个或多个 EIP（或将 ERC 纳入其中）持开放态度，但我们更希望看到每个提案之间更多的用户体验和开发者体验比较，以便更好地了解工具集成的权衡空间和工作量。我们关注以下 EIP/ERC，但欢迎向我们提出更多建议：
（1）EIP-3074：AUTH 和 AUTHCALL 操作码
（https://eips.ethereum.org/EIPS/eip-3074）
（2）ERC-4337：使用 Alt Mempool 的账户抽象
（https://eips.ethereum.org/EIPS/eip-4337）
（3）EIP-5806：代理交易
（https://eips.ethereum.org/EIPS/eip-5806）
（4）EIP-5920：PAY 操作码
（https://eips.ethereum.org/EIPS/eip-5920）
（5）EIP-6913：SETCODE 指令
（https://eips.ethereum.org/EIPS/eip-6913）
（6）EIP-7377：迁移交易
（https://eips.ethereum.org/EIPS/eip-7377）
（7）RIP-7560： 原生账户抽象 - 核心 EIP - 以太坊魔术师联谊会
(https://ethereum-magicians.org/t/rip-7560-native-account-abstraction/16664）
我们要提醒的是，在上述内容中，“账户抽象”是指“抽象验证功能，主要目标是实现密钥轮换，使多重签名成为区块链的核心特性，并为我们提供自动的量子抵抗路径”（h/t VB），仅适用于上述 4337 和 7560，而其他建议则分为两类，即 Gas 赞助和批量操作。
