撰文：Georgios Konstantopoulos
编译：小白导航coderworld
导读
这篇文章的目的是概述 Paradigm Reth 团队对布拉格会议（坎昆会议之后的下一个 EL 硬分叉）应包含哪些 EIP （以太坊改进提案），以及2024年“EL核心开发”计划的看法。文中的观点仅代表Reth团队当前的观点，并不一定代表整个Paradigm团队的立场。
摘要
我们认为，布拉格硬分叉（Prague hard fork）可能在2024年第三季度在以太坊测试网上实施，并在年底前在主网上实施。它应该包括：
-
任何与质押相关的 EIP，例如 EIP-7002，它支持再质押和无需信任的质押池。
-
独立的EVM更改。
-
我们愿意与任何团队合作，进一步调查布拉格或其他未来EL硬分叉的难题，乐意提供指导或协助调整Reth代码库。
应做的事情：
-
我们认为以下EIP必须优先考虑：7002、6110、2537。
-
我们支持EOF（EVM对象格式）的规范描述，但希望尽快确定其范围，并创建一个致力于该范围的元 EIP（meta-EIP）。
-
我们愿意增加EIP-4844的最大Blob Gas。我们对正确的数字没有具体看法，但我们邀请数据人员与我们合作调查这个主题。
-
我们愿意推出EIP-7547的版本：包含列表，以帮助基层抵抗审查。
不应做的事情：
-
我们不支持在布拉格中引入Verkle Tries，但支持客户端团队从2024年第二季度开始努力实现它，并承诺在2025年中/晚期的大阪硬分叉中发布它。
-
我们认为不应该增加L1执行Gas上限或合约大小，但我们邀请数据人员与我们合作调查对网络的影响。我们愿意根据以往的测试结果（显示Reth节点可以承受增加的负载）来重新考虑我们的立场。
-
我们认为钱包/账户抽象化EIP需要更多的实战测试，以更好地理解它们之间的权衡。如果它们不是互斥的，那么我们将来愿意部署多个与AA相关的EIP。
-
如果社区对传言中的NSA后门（NAS backdoor）表示接受，我们可能会在EIP-7212（secp256r1）上做出决定。
-
其他路线图主题：我们对CL EIP或CL/EL分叉的耦合没有直接看法，但EIP 7549和7251看起来很有前途。我们也愿意尽可能从EL方面为PeerDAS的工作做出贡献。我们目前希望避免引入SSZ根（EIP 6404、6465、6466）。最后，我们注意到有机会为过期的 blob、历史记录和状态提供长期数据归档解决方案，因为 EIP-4844 和 EIP-4444 都没有指定这一点，而且以太坊是否愿意提供这样的解决方案还有待确定。
下面是全文详细的小白导航介绍。
应做的事情：
简单来说，我们支持
-
进一步缩小CL和EL之间的差距
-
可作为单人工作执行的 EVM 修改，可进行独立和并行测试。
EIP-7002
该 EIP 可让 EL 端的智能合约控制 CL 端的 1 个或多个验证器，从而解锁了无需信任的再质押和质押池。从我们的角度来看，这是一个不费吹灰之力的 EIP，因为它至少能让现有的质押池从实现提款的智能合约中移除一层中心化。
将有状态预编译引入 EVM 是我们需要在 EVM 实现中捕获的新抽象，但除此之外，我们认为这是一个可以直接执行的 EIP。
EIP-6110
这个EIP在EL状态中引入存款，简化了在CL上需要进行的状态管理。实际上，这类似于跟踪CL提款，所以总体上我们认为这也是一个容易且独立实施的EIP。
EIP-2537
目前已经有多种BLS12-381的实施方式，并且它是许多SNARKs、BLS签名算法和EIP-4844中频繁使用的曲线。我们认为实施的复杂性很低，因为它只是通过预编译接口公开曲线的验证算法。我们可能还需要一个 BLS12-381 曲线预编译的哈希接口。
EOF
简而言之：支持一个定义明确的版本，Solidity和Vyper将会采用。代码格式和验证调整可使分析更容易，这一点毋庸置疑，除此之外，我们建议慎重考虑。我们建议采用以下几个 EIP，但我们对进一步的删减持开放态度。
好的方面：
-
只涉及EVM的变更，可以通过ethereum/tests测试，并由一个人实施
-
Vyper和Solidity想要的EVM的改变
-
有助于提升性能和增加合约大小上限
-
消除了 EVM 在运行时进行字节码分析的需要，在不涉及缓存的情况下，分析的时间可能高达 50%，并且随着合约大小的增加而增加
-
支持部分代码加载，有助于执行大型智能合约
-
开发体验：将允许通过 dupN/swapN 和其他工具改进来修复“堆栈太深”的问题
不好的方面：
-
范围和移动目标
-
没有强有力的推动者促成其纳入
-
遗留代码仍然需要支持
-
在采用之前，以太坊主网和其他 EVM 链之间存在暂时分歧
我们认为应在 2024 年部署以下 EOF 功能。我们建议尽快确定范围，并做出承诺。其他内容应考虑后续部署。我们的建议包括：
-
EIP-3540：EOF – EVM对象格式v1：引入代码和数据容器，为以太坊字节码添加结构和版本控制。
-
EIP-3670：EOF – 代码验证：拒绝部署时不遵循 EOF 格式的任何合约。实施更结构化的代码并禁用无效和未定义的指令。
-
EIP-663：无限制的SWAP和DUP指令：这解决了 Solidity 中的“堆栈太深”问题，具有立即价值的JUMPDEST分析可能会产生副作用。这对EVM语言非常有吸引力。
-
EIP-4200：EOF – 静态相对跳转：更好的静态分析，没有不确定的跳转。相对跳转更利于代码的可复用性。
-
EIP-4750：EOF – 函数：解决使用静态跳转而不是动态跳转时可能的子程序问题。此外，它还允许部分代码加载，这与 Verkle 配合良好并增加了合约大小限制。
-
EIP-5450：EOF – 栈验证：验证代码和栈要求。除了CALLF (EIP-4750)指令外，移除所有指令的运行时栈下溢和溢出检查。
-
EIP-7480：EOF – 数据部分访问指令：允许访问字节码的数据部分。
-
EIP-7069：改进的CALL指令：允许从CALL中删除gas可观察性，从而使将来更容易重新定价 gas。虽然独立于 EOF，但我们认为这是引入它的好机会。
我们对EIP-6206：EOF – JUMPF和非返回函数的确定性较低。虽然它允许在 EOF 函数中进行尾部调用优化，但我们仍然需要看到语言分析其有用性。如果我们没有这些，我们认为可以将其从范围中删除并包含在后续 EOF 更新中。
我们将上述工作预算为 1 人全职工作 1-2 个月的世界。如果这意味着保持势头，我们愿意进一步缩小上述范围。
关于遗留字节码的说明：
-
虽然我们可以禁止新的遗留/非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 Tries
简而言之，我们看不到Verkle tries在2024年底/2025年初部署的途径。我们建议团队在2024年第二季度分配资源，并承诺在 2025 年第二季度至第三季度在大阪硬分叉中部署。
好的方面：
-
通过更小的存储证明实现更便宜的轻客户端。
-
通过在区块头中包含读取预状态实现无状态执行，这也可通过静态状态访问提高性能。
-
通过分块字节码和启用部分代码加载来提高合约大小限制。
-
状态过期变得更加可接受，因为恢复状态的成本更低。
不好的方面：
-
变更的影响以及实施和测试的集成工作。
-
Gas 核算变化：Verkle Tries将见证的大小引入Gas计算函数。我们担心存储定价的变化尚未被探索（例如，Verkle后顶级Gas消耗者的成本将是多少？）。
-
应用集成：在Overlay转换运行时，具有Merkle Patricia Trie验证器的应用应该如何处理？eth_getProof应该如何表现？
虽然我们理解 Verkle Tries 的好处，但我们认为需要更多考虑第三方工具/合约需要如何调整，以及过渡对第 2 层解决方案等的影响。最初，我们对迁移策略持怀疑态度，因为它要求在从现有的MPT（Merkle Patricia Trie）读取状态时更新Verkle树，但现在这种情况似乎已经改变。因此，我们支持覆盖树方法作为可行的迁移路径。
关于Verkle树的迁移策略的文档普遍过时，大多数资源仍然声称在从MPT读取状态时应更新Verkle树，尽管实际并非如此。我们希望看到关键的过渡文档更新为最新的方法，例如这篇出色的文档。我们还希望看到关于迁移策略的草案EIP（Ethereum Improvement Proposal）。
因此，我们仍然支持其在2025年的推出，但不认为在布拉格会有部署该系统的可能。
L1 Gas限制
我们认为，由于诱发需求，提高L1 gas限制实际上并不会有太大效果。我们还认为，大多数客户端可以处理平均负载的增加，但我们想对最坏情况保持警惕，所以我们目前还不能建议增加L1 gas限制。我们认为短期内增加blob gas限制是一个更有希望的解决方案。
我们邀请人们与我们合作进行这方面的研究，通常围绕打破 EVM 中的资源计量进行。《Broken Metre》论文是这一研究方向的一个很好的起点。
账户抽象
我们愿意包含一个或多个这些EIP（或纳入ERC），但我们理想中希望看到更多关于每个提案的用户体验和开发者体验的比较，以便更好地了解工具集成的权衡空间和工作量。我们正在关注以下EIP/ERC，但也欢迎大家向我们推荐更多：
需要指出的是，在上述内容中，“账户抽象”指的是“抽象验证函数，主要目标是实现密钥轮换，使多重签名成为一流的技术，并为我们提供自动的抗量子路径，仅适用于4337和7560，而其他提案则分为两类：Gas赞助和批量操作。
文章来源于互联网:Paradigm：以太坊坎昆升级后的下一步是什么？
相关推荐: 每周播客推荐 ｜ 畅想DeSci：或许我们可以用 DNA 来存储链上数据
用DNA作为链上数据的存储媒介，也不是没有可能吧？ 整理：Sunny，小白导航coderworld 1.a16z：用 DNA 存储数据是未来的数据存储常态吗？ 用DNA作为链上数据的存储媒介，也不是没有可能吧？ 在这期最新的a16z播客中，主播和生物科技投资人…
相关文章
