内含对 Prague（布拉格）硬分叉包含的重要 EIP 的理解以及对 2024 年 “EL Core Dev” 计划的看法。
原文：What comes after Ethereum's Cancun hard fork?
编译：Moni，Odaily 星球日报
封面：Photo by Shubham Dhage on Unsplash
一、内容概述
本文将分析 Paradigm Reth 团队对 Prague（布拉格）硬分叉（Cancun 坎昆升级后的下个执行层硬分叉）包含的重要 EIP（以太坊网络改进协议）的理解以及对 2024 年 “EL Core Dev” 计划的看法。
Prague 硬分叉可能在 2024 年第三季度在以太坊测试网上进行，并在年底前在主网上实现。其升级内容包括：
1、建议囊括与质押相关的 EIP，如 EIP-7002 ，激活再质押和无需外部信任的质押池；
2、独立的 EVM 变更；
此外，Paradigm 愿与所有希望进一步研究 Prague 等 EL 硬分叉中难题的团队合作，也十分乐意提供修改 Reth 代码库在内的指导。
Paradigm 认同的方向：
1、Paradigm 认为应当优先考虑以下 EIP： 7002、 6110、 2537 。
2、Paradigm 支持规范中描述的以太坊对象格式（EOF） ，但希望尽快确定范围，并创建一个致力于该范围的 meta-EIP。
3、Paradigm 愿意增加 EIP-4844 Max Blob Gas，对其中正确的数字不做过多评论，但会邀请数据人员合作调研该 EIP。
4、对于发布 EIP-7547 ：Inclusion Lists 版本，Paradigm 持开放态度，该 EIP 可以帮助抵抗基础层审查。
Paradigm 不认同的方向：
1、Paradigm 不支持 Prague 硬分叉所采用的 Verkle Tries 数据结构，但支持客户端团队在 2024 年第二季度开始为此努力，同时承诺于 2025 年中/下旬在大阪升级发布。
2、Paradigm 认为不应该增加 L1 执行 Gas 限制或合约规模，但会邀请数据人员合作调查这种做法对以太坊网络的影响。同时 Paradigm 愿意调整自己的看法，因为过去的测试表明 Reth 节点可以毫无问题地处理增加的负载。
3、Paradigm 认为钱包/账户抽象 EIP 需要进行更多的相互对抗测试，以更好地了解权衡网络空间。如果钱包/账户抽象不相互排斥，那么将愿意在未来部署多个与账户抽象相关的 EIP。
4、如果社区同意传闻中的 NSA 后门，Paradigm 认为可以越过 EIP-7212 (secp 256 r 1) 的线路。
5、其他路线图主题：Paradigm 对共识层 EIP 或 CL/EL（共识层/执行层）分叉耦合没有做过实际了解，但 EIP 7549 和 EIP 7251 两个提案似乎很有前途。Paradigm 还希望尽可能从 EL 方面为 PeerDAS 的工作做出贡献，目前希望避免引入 SSZ 根（EIP 6404、 6465、 6466）。最后，Paradigm 认为应该为过期的 blob、历史记录和状态提供长期数据归档解决方案，因为 EIP-4844 和 EIP-4444 都没有指明这一点，但以太坊是否愿意提供这样的解决方案还有待确定。
以下是详细内容：
Paradigm 认同的方向
抽象地说，Paradigm 主要支持以下两个方面：
1) 进一步缩小共识层和执行层之间的差距；
2) EVM 修改可以作为单人作业执行，并且可以进行独立测试或并行测试。
EIP-7002
该 EIP 通过使执行层侧的智能合约能够控制共识层侧的单个或多个验证器来解锁去信任的重新质押和质押池。从 Paradigm 的角度来看，这个 EIP 有一定道理，至少将使现有质押池能够从实现提款的智能合约中消除一层中心化。
此外，将有状态预编译引入 EVM 也是 Paradigm 认同需要在 EVM 实现中满足的功能，但除此之外，Paradigm 认为这是一个可以直接执行的 EIP。
EIP-6110
该 EIP 引入了执行层状态中的存款功能，简化了需要在共识层上完成的状态管理。在实施方面，这类似于跟踪共识层提款，因此总的来说，Paradigm 认为这也是一个易于实施且独立的 EIP。
EIP-2537
现阶段，BLS 12-381 有多种实现，是许多 SNARK、BLS 签名算法和 EIP-4844 中经常使用的曲线。Paradigm 认为 BLS 12-381 实现复杂度较低，因为它只是通过预编译接口公开曲线的验证算法，因此可能还需要 BLS 12-381 曲线预编译的哈希值。
以太坊对象格式（EOF）
简单来说，EOF 将同时支持 Solidity 和 Vyper 采用范围更广泛的版本，使分析变得更容易的代码格式和验证调整也是合理的，Paradigm 建议仔细考虑除此之外的任何内容并在下面推荐了一些 EIP，同时也愿意做进一步调整。
好的方面：
● 仅限 EVM 的更改，可以使用以太坊/测试网进行测试并由单人实施。
● Vyper 和 Solidity 想要的 EVM 改变。
● 有助于提高绩效并增加合约规模限制。
● 消除了 EVM 在运行时进行字节码分析需求，在不涉及缓存的情况下，分析的时间可能高达 50% ，并且随着合约大小的增加而增加。
● 启用部分代码加载，浙江有助于执行大型智能合约。
● Devex：将允许通过 dupN/swapN 和其他工具改进来修复 “堆栈太深” 的问题。
● 未来可适用的功能：可以引入安全跨 L2 新功能，工具会知道哪些功能是兼容的。
不好的方面：
● 范围和移动目标。
● 没有支持大力推动将其纳入其中。
● 遗留代码仍然需要支持。
● 在采用之前，以太坊主网和其他 EVM 链之间存在暂时分歧。
Paradigm 认为以下 EOF 功能应在 2024 年部署，并且建议尽快确定范围并承诺实施。后续部署应该考虑其他问题。因此，Paradigm 建议：
● EIP-3540 （EOF - EVM 对象格式 v1）：引入代码和数据容器，并向以太坊字节码添加结构和版本控制。
● EIP-3670（EOF -代码验证）：拒绝部署时不遵循 EOF 格式的任何合约，只有更具结构化的代码才能被执行，同时禁用无效和未定义的指令。
● EIP-663（无限 SWAP 和 DUP 指令）：该 EIP 解决了 Solidity 中的 “堆栈太深” 问题，使用 JUMPDEST 分析作为即时值可能会产生副作用，但这是 EVM 变成语言非常想要的功能。
● EIP-4200（EOF -静态相对跳转）：更好的静态分析，没有不确定的跳转。更好的 aot 编译，相对跳转更有利于代码的可重用性。
● EIP-4750（EOF –函数）：需要解决可以使用动态跳转但不能使用静态跳转的子例程，并且还允许部分代码加载，可以与 Verkle 数据结构进行良好配合并增加了合约大小限制。
● EIP-5450（EOF -堆栈验证）：验证代码和堆栈要求。删除除 CALLF 之外的所有指令的运行时堆栈下溢和溢出检查（EIP-4750）。
● EIP-7480（EOF -数据部分访问指令）：允许访问字节码的数据部分。
● EIP-7069（改进的 CALL 指令）能够从 CALL 中删除 Gas 可观测性，未来将更容易重新定价 Gas。虽然该 EIP 独立于 EOF，但 Paradigm 认为本次硬分叉是引入该 EIP 的好机会。
Paradigm 对 EIP-6206 （EOF-JUMPF 和非返回函数）不太确定，虽然该 EIP 允许在 EOF 函数中进行尾部调用优化，但 Paradigm 仍然需要看到语言分析其有用性。如果没有，Paradigm 认为可以将其从范围中删除并包含在后续 EOF 更新中。
Paradigm 估计上述工作量大约为全职工作 1-2 个人月，如果评估的工作量较大，Paradigm 愿意进一步缩小上述范围。
关于遗留字节码的注释：
● 虽然可以禁止新的遗留/非 EOF 字节码，但无法弃用现有的遗留字节码，因为它实际上充当 EOF“v 0 ”。遗留字节码仍然需要 EOF 后的 JUMPDEST 分析，并且仍然需要特殊的代码处理以将其分段为 Verkle Tries 中的区块。
● 据 Paradigm 所知，如果不访问源代码，就无法验证从非 EOF 字节码到 EOF 的转换，但 Paradigm 愿意研究促进这种转换的机制。
● 或者，Paradigm 愿意探索强制状态迁移到 EOF 的到期方法。
增加 EIP-4844 Blob 数量
Paradigm 对这一更改持开放态度，对应地，将增加 “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 对网络造成的压力，随着网络在较大区块下展现出可靠性，也可以在后续的升级中增加初始限制大小。
实际上，相关代码更改不会太大，但 Paradigm 需要调查这些更高对 txpool 中的实际影响，因此可以重新使用 EIP-4844 压力测试基础设施。共识层可能很难传播更多的 blob，所以 Paradigm 也尊重共识层队伍的意见。
Paradigm 不认同的方向
Verkle Tries
简单来说， 2024 年底/2025 年初完成 Verkle 部署的可能似乎不大，Paradigm 建议团队在 2024 年第二季度为此分配资源，并承诺在 2025 年第二季度至第三季度在大阪硬分叉中进行部署。
好的方面：
● 通过更小的存储证明实现成本更低的轻客户端。
● 通过在区块标头中包含读取预状态来进行无状态执行，这也可能由于静态状态访问而导致性能改进。
● 通过对字节码进行分块并启用部分代码加载来提高合约大小限制。
● 由于 “恢复” 状态的成本较低，状态到期变得更容易接受。
不好的方面：
● 实施和测试的变更和集成工作的影响。
● Gas 核算变化：Verkle Tries 将见证人的大小引入到 Gas 计算功能中，Paradigm 担心存储定价的变化尚未被探索（例如，Verkle 后头部 gas 消耗者的成本是多少）。
● 应用程序集成：当 Overlay 转换运行时，带有 Merkle Patricia Trie 验证器的应用程序应该做什么？应该如何 eth_getProof 表现？
虽然 Verkle Tries 有一定优势，但 Paradigm 认为需要更多地考虑第三方工具/合约需要如何适应，以及过渡会对二层解决方案等产生什么影响。最初 Paradigm 对迁移策略心存疑虑，因为它规定当从预先存在的 MPT 中读取状态时应该更新 Verkle Tries，但情况似乎不再如此了。因此，Paradigm 支持覆盖 Overlay 方法作为可行的迁移路径。
Verkle 迁移策略的文档通常似乎已经过时，因为大多数资源仍然指出从 MPT 读取状态时应该更新 Verkle trie，即使事实并非如此。Paradigm 希望看到关键的过渡文档使用最新的方法进行更新，可参考该文档。Paradigm 还希望看到有关过渡战略的生态投资计划草案。
因此，Paradigm 仍然支持其在 2025 年推出，不是在本次硬分叉中部署。
L1 Gas 限制
Paradigm 认为，在需求侧可能存在某些 “误导”，实际上，提高 L1 Gas 限制在实践中并不会产生太大影响。Paradigm 还认为大多数客户端可以应对平均负载增加，但 Paradigm 希望对最坏的情况保持警惕，因此目前不建议增加 L1 Gas 限制。Paradigm 认为，短期内增加 blob Gas 限制是一个更有希望的解决方案。
Paradigm 希望邀请社区合作进行相关方向的研究，通常围绕打破 EVM 中的资源计量进行。Broken Meter 发布的这篇论文应该是该研究领域的一个很好起点。
账户抽象
Paradigm 愿意在硬分叉中包含 1 个或多个 EIP（或纳入 ERC），但理想情况下，更希望看到每个提案之间有更多的用户体验和开发者体验对比，这样可以更好地了解工具集成的权衡空间和工作量。Paradigm 正在关注以下 EIP/ERC，社区可以随时向 Paradigm 提出建议：
● EIP-3074 ：AUTH 和 AUTHCALL 操作码
● ERC-4337 ：使用 Alt Mempool 进行账户抽象
● RIP-7560 ：原生帐户抽象 - 核心 EIP - Fellowship of Ethereum Magicians
最后需要提醒的是，“帐户抽象” 仅适用于上述 EIP-4337 和 EIP-7560 ，而其他提案主要涉及两个领域，分别是：Gas 赞助和批量操作。（“帐户抽象” 就像对验证函数进行抽象，主要目标是启用密钥轮换，使多重签名成为关键要素，并为我们提供一条自动实现量子抗性的路径。）
免责声明：作为区块链信息平台，本站所发布文章仅代表作者及嘉宾个人观点，与 Web3Caff 立场无关。文章内的信息仅供参考，均不构成任何投资建议及要约，并请您遵守所在国家或地区的相关法律法规。
