本文的目标是概述 Paradigm Reth 团队[4]对于布拉格硬分叉的看法，布拉格（Prague）是坎昆之后的下一个 EL 硬分叉，以及我们 2024 年“EL 核心开发”计划的概况。以下观点正在发展中，仅代表 Reth 团队当前的观点，不一定代表更广泛的 Paradigm 团队。
我们认为布拉格硬分叉可能在 2024 年第三季度在以太坊测试网上实现，年底在主网上实现。它应该包括：
任何与质押相关的 EIP，比如 EIP-7002，它使重质押(re-staking)和无信任质押池成为可能。
独立的 EVM 更改。
我们愿意与任何希望进一步研究布拉格或其他未来 EL 硬分叉的团队合作，乐意指导或提供指导以修改 Reth 代码库的位置。
支持:
我们认为以下 EIP 必须优先考虑：7002[5], 6110[6], 2537[7]。
我们支持 EOF，如规范[8]中所述，但希望尽快确定范围，并创建一个元 EIP，承诺遵守该范围。
我们愿意增加 EIP-4844 最大 Blob Gas[9] 的版本。我们对正确的数字没有看法，但我们邀请数据人员与我们合作调查这个问题。
我们愿意发布 EIP-7547：包含列表[10]的版本，以帮助基础层抗审查。
不支持:
我们不支持在布拉格中使用 Verkle Tries[11]，但我们支持客户端团队从 2024 年第二季度开始努力实现它，并承诺在 2025 年中期/晚期在大阪发布。
我们不认为应该增加 L1 执行 Gas 限制或合约大小，但我们邀请数据人员与我们合作调查对网络的影响。我们愿意修改我们的看法，因为过去的测试表明 Reth 节点可以处理增加的负载而没有问题。
我们认为钱包/账户抽象 EIP 需要更多相互对抗的测试，以更好地理解权衡空间。如果它们不是相互排斥的，那么我们愿意在未来部署多个 AA 相关的 EIP。
如果社区对传闻中[12]的NSA[13]后门[14] OK ，我们可以接受 EIP-7212（secp256r1）。
其他路线图主题：我们对 CL EIP 或 CL/EL 分叉的耦合没有具体看法，但 EIP 7549[15]和 7251[16] 似乎很有前景。我们还希望在 EL 方面尽可能地为 PeerDAS 的工作做出贡献。我们希望暂时避免引入 SSZ 根（EIP 6404, 6465, 6466）。最后，我们注意到为过期的 Blob、历史和状态提供长期数据存档解决方案的机会，因为 EIP-4844[17] 和EIP-4444[18]都没有指定这一点，以及以太坊是否愿意提供这样的解决方案。
以下是推理。
抽象地说，我们支持 1)进一步弥合 CL 和 EL 之间的差距，2) EVM 修改可以作为单人工作执行，并且可以在隔离和并行测试。
这个 EIP 通过使 EL 侧的智能合约控制 CL 侧的一个或多个验证者，解锁了无信任的重新质押和质押池。从我们的角度来看，这是一个不需要思考的 EIP，因为至少它将使现有的质押池能够从实施其提款的智能合约中去除一层中心化。
在 EVM 实现中引入有状态的预编译是我们需要在 EVM 实现中捕获的新抽象，但除此之外，我们认为这是一个可以直接执行的 EIP。
这个 EIP 在 EL 状态中引入了存款，简化了 CL 上需要进行的状态管理。在实施上，这类似于跟踪 CL 提款，因此总体上我们认为这也是一个容易实现且独立的 EIP 。
现在外面有多个 BLS12-381 的实现，它是许多 SNARKs、BLS 签名算法和 EIP-4844 中经常使用的曲线。我们认为实现复杂性低，因为它只是通过预编译接口公开了曲线的验证算法。可能我们还想要一个 Hash 到 BLS12-381 曲线的预编译。
TL;DR：支持一个 Solidity 和 Vyper 将采用的范围明确的版本。使分析更容易的代码格式和验证调整是一个不需要思考的事情，我们建议进一步修剪。
好处：
只有 EVM 的更改，可以通过以太坊/tests 进行测试，并由一人实施。
做 Vyper 和 Solidity 想要的 EVM 更改！
有助于性能和提高合约限制大小。
通过 EVM 在运行时消除了对字节码的分析的需要，当没有缓存时，这可能占用时间的 50%，随着合约大小的增加而增加。
可以部分加载代码，有助于执行大型合约。
Devex：将允许在 Solidity 中使用 dupN/swapN 修复“Stack Too deep”，以及其他工具改进。
未来验证：可以安全地引入新功能到 L2，并且工具将知道什么是兼容的。
不足：
变化了目标。
没有支持者极力推动它的加入。
仍然需要支持旧代码
直到被采用之前，以太坊主网和其他 EVM 链之间会有暂时的分歧。
我们认为以下 EOF 功能应该在 2024 年部署。我们建议尽快确定范围并承诺遵守。其他任何事情应该考虑后续部署。我们的建议：
EIP-3540: EOF - EVM 对象格式 v1[23]：引入代码和数据容器，并为以太坊字节码添加结构和版本。
EIP-3670: EOF - 代码验证[24]：在部署时拒绝任何不遵循 EOF 格式的合约。强制更结构化的代码，并禁用无效和未定义的指令。
EIP-663: 无限的 SWAP 和 DUP 指令[25]：这解决了 Solidity 中的“Stack Too Deep”问题，通过 JUMPDEST 分析作为即刻值可能会产生副作用。EVM 语言非常希望有这样的功能。
EIP-4200: EOF - 静态相对跳转[26]：更好的静态分析，没有不确定的跳转。更好的 aot 编译。相对跳转对代码的可重用性更好。
EIP-4750: EOF - 函数[27]：需要处理可能具有动态跳转但不具有静态跳转的子例程。它还允许部分代码加载，这与 Verkle 很好地配合使用，并增加了合约大小限制。
EIP-5450: EOF - 栈验证[28]：验证代码和栈要求。除了 CALLF（EIP-4750）之外的所有指令都删除了运行时栈下溢和上溢检查。
EIP-7480: EOF - 数据段访问指令[29]：允许访问字节码的数据段。
EIP-7069: 改进的 CALL 指令[30]：使 CALLs 中的 gas 可观察性消失，这样将来更容易进行 gas 重新定价。虽然独立于 EOF，但我们认为这是一个引入它的好机会。
我们对 EIP-6206: EOF - JUMPF and non-returning functions[31] 的确定性较低。虽然它允许在 EOF 函数中进行尾调用优化，但我们仍需要看到语言分析其有用性。如果我们没有这个，我们认为可以将其从范围中剔除，并包含在后续 EOF 更新中。
我们将以上工作预算为 1-2 个月，由 1 人全职完成。如果这意味着保持动力，我们愿意进一步削减上述提到的范围。
关于传统字节码的说明：
虽然我们可以禁止新的传统/非 EOF 字节码，但无法废弃现有的传统字节码，它实际上充当 EOF“v0”。传统字节码仍需要在 EOF 后进行 JUMPDEST 分析，并且仍需要特殊的代码处理来将其分段到 Verkle Tries 中。
据我们所知，在不需要访问源工件情况下，没有从非 EOF 字节码到 EOF 的可验证转换，但我们愿意调查促进这种转换的机制。
或者，我们愿意探索强制将状态迁移到 EOF 的到期方法。
我们愿意接受这一变化，这将对MAX_BLOB_GAS_PER_BLOCK和TARGET_BLOB_GAS_PER_BLOCK进行增加，有关上下文，请参阅 EIP-4844[32]：
TARGET_BLOB_GAS_PER_BLOCK 和 MAX_BLOB_GAS_PER_BLOCK 的值被选择为每个块的目标为 3 个 blob（0.375 MB），最大为 6 个 blob（0.75 MB）。这些较小的初始限制旨在最大限度地减少此 EIP 对网络造成的压力，并且预计将在未来的升级中增加，以便网络在更大的块下表现出可靠性。*
实际上，这是一个小的代码更改，我们需要调查它在 txpool 中的实际影响，但我们认为我们可以重用 EIP-4844 的压力测试基础设施。共识层可能在传播更多 blob 时遇到困难；我们听取 CL 团队的意见。
TL;DR：我们认为没有办法在 2024 年底/2025 年初部署 Verkle tries。我们建议团队在 2024 年第二季度分配资源，并承诺在大阪硬分叉中在 2025 年第二季度至第三季度部署。
好处：
通过更小的存储证明实现更便宜的轻客户端。
通过在块头中包含读取的预状态来实现无状态执行，这也可能由于静态状态访问而导致性能改进。
通过对字节码进行分块和启用部分代码加载来提高合约大小限制。
由于“复活”状态的成本较低，状态到期变得更具吸引力。
不足：
工作量大：变更的影响、整合工作实现以及测试。
Gas 计费变更：Verkle Tries 将见证的大小引入到 gas 计算函数中。我们担心存储定价的变化尚未被探索（例如，Verkle 后的顶级 gas 消耗者的成本将是多少）？
应用集成：当 Overlay 过渡运行时，具有 Merkle Patricia Trie 验证器的应用程序应该怎么做？eth_getProof行为应该怎样的？
虽然我们理解 Verkle Tries 的好处，但我们认为需要更多的思考，以了解第三方工具/合约需要如何适应，以及过渡对例如第 2 层解决方案的影响。最初，我们对迁移策略持怀疑态度，因为它规定 Verkle trie 应在从现有 MPT 读取状态时进行更新，但现在似乎并非如此。因此，我们支持 Overlay 树方法作为可行的迁移路径。
Verkle 迁移策略的文档似乎普遍过时，因为大多数资源仍然指出 Verkle trie 应在从 MPT 读取状态时进行更新，尽管情况并非如此。我们希望看到关键的过渡文档更新为最新的方法，例如这篇优秀的文档[34] 。我们还希望看到一份关于过渡策略的草案 EIP。
因此，我们仍然支持在 2025 年推出 Verkle，但在布拉格升级没有看到部署路径。
我们认为从引发需求的角度，提高 L1 gas 限制在实践中不会有太大作用。我们还认为大多数客户端可以处理平均负载的增加，但我们希望对最坏情况保持警惕，因此我们暂时不建议增加 L1 gas 限制。我们认为在短期内增加 blob gas 限制是更有前途的解决方案。
我们邀请大家与我们合作，进行任何关于这方向的研究，以及围绕突破 EVM 中的资源计量方式。Broken Metre paper[35] 是这一研究方向的一个很好的起点。
我们愿意包含 1 个或多个这些 EIP（或协议实现 ERCs），但我们希望更理想地看到更多的用户体验和开发体验比较，以更好地理解各个提案的权衡空间和工具集成的工作量。我们正在关注以下 EIP/ERCs，但请随时向我们建议更多：
EIP-3074: AUTH and AUTHCALL opcodes[36]
ERC-4337: Account Abstraction Using Alt Mempool[37]
EIP-5806: Delegate transaction[38]
EIP-5920: PAY opcode[39]
EIP-6913: SETCODE instruction[40]
EIP-7377: Migration Transaction[41]
RIP-7560: Native Account Abstraction - Core EIPs - Fellowship of Ethereum Magicians[42]
我们想要说明，在上述内容中，“账户抽象”指的是“抽象验证功能，主要目标是启用密钥轮换，使多签名成为一等功能，并为我们提供自动的量子抵抗路径”（h/t VB），只适用于 4337 和 7560，而其他提案则分为两个类别，即 gas 赞助和操作批处理。
作者：
Georgios Konstantopoulos[43]
Georgios Konstantopoulos 是 Paradigm 的首席技术官和研究合伙人，专注于 Paradigm 的投资组合公司和开源协议的研究。此前，Georgios 是一名独立顾问和研究人员。
本文仅代表作者观点，不代表喜来顺财经立场。
未经喜来顺财经许可，不得转载。
喜来顺财经
