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赞助和批量操作。
