Paradigm：以太坊坎昆硬分叉之后会发生什么？

TL;DR

这篇文章的目的是概述ParadigmReth团队对哪些EIP应该包含在Prague、坎昆升级之后的下一个EL硬分叉以及关于2024年「ELCoreDev」总体计划的看法。以下观点是不断变化的，仅代表Reth团队当前的观点，不一定代表更广泛的Paradigm团队。

我们认为Prague硬分叉有可能于2024年第三季度在以太坊测试网上进行，并于年底在主网上进行。它应该包括：

任何与质押相关的EIP，如EIP-7002，它可以实现重新质押和无信任质押池；

孤立的EVM变化。

我们愿意与任何希望进一步研究Prague或其他未来EL硬分叉问题的团队合作，并欢迎指导或提供有关修改Reth代码库的指导。

支持：

我们认为必须优先考虑以下EIP：7002、6110、2537。

我们支持规范中描述的EOF，但希望尽快确定其范围，并创建一个该范围的元EIP。

我们对增加EIP-4844MaxBlobGas持开放态度。我们对合适的数字还没有定论，但我们邀请数据人员与我们一起研究该问题。

我们愿意提供EIP-7547版本：纳入列表，以帮助抵制基础层审查。

不支持：

我们不支持在Prague中的VerkleTries，但支持客户团队在2024年第2季度开始努力，并承诺在2025年中/末在Osaka中交付。

我们认为不应增加L1执行Gas限额或合约规模，但我们邀请数据人员与我们合作，共同调查对网络的影响。由于过去的测试表明Reth节点可以顺利处理增加的负载，因此我们愿意修改我们的观点。

我们认为，钱包/账户抽象EIP需要进行更多的对战测试，以更好地了解它们之间的权衡空间。如果它们并不相互排斥，那么我们愿意在未来部署多个与AA相关的EIP。

如果社区对传言中的NSA后门没有意见，我们可能会在EIP-7212(secp256r1)中取得突破。

其他路线图主题：我们对CLEIP或CL/EL分叉的耦合没有实际看法，但EIP7549和7251似乎很有前途。我们还希望在可能的情况下，从EL方面为PeerDAS的工作做出贡献。目前，我们希望避免引入SSZ根（EIP6404、6465、6466）。最后，我们注意到，EIP-4844和EIP-4444均未指定过期blob、历史和状态的长期数据存档解决方案，而以太坊是否愿意提供这样的解决方案尚待确定。

支持

摘要：我们支持1)进一步缩小CL和EL之间的差距；2)EVM修改可作为单人工作执行，并可进行隔离和并行测试。

EIP-7002

该EIP通过启用EL侧的智能合约来控制CL侧的1个或多个验证器，从而解锁了无信任的再验证和验证池。从我们的角度来看，这是一个不费吹灰之力的EIP，因为它至少能让现有的质押池从实现提款的智能合约中消除一层中心化。

将有状态预编译引入EVM是我们需要在EVM实现中捕获的一个新抽象，但除此之外，我们认为这是一个可以直接执行的EIP。

EIP-6110

这将在EL状态中引入存款，简化了需要在CL上完成的状态管理。从实施角度看，这与跟踪CL提款类似，因此总体而言，我们认为这也是一个易于实施且独立的EIP。

EIP-2537

目前已有多种BLS12-381实现，它是许多SNARK、BLS签名算法和EIP-4844中经常使用的曲线。我们认为实现的复杂度很低，因为它只是通过预编译接口公开了曲线的验证算法。我们可能还需要BLS12-381曲线预编译的哈希算法。

EOF

简而言之：支持Solidity和Vyper将采用的范围明确的版本。代码格式和验证调整可使分析更容易，这一点毋庸置疑。我们建议仔细考虑除此之外的任何内容。我们在下面推荐了一些EIP，但我们愿意进一步调整。

优势：

仅对EVM进行更改，可通过以太坊/测试进行测试，并由一人实施。

Vyper和Solidity想要的EVM更改！

有助于提高性能和增加合约大小限制。

消除了EVM在运行时进行字节码分析的需要，在不涉及缓存的情况下，这可能需要多达50%的时间，并随着合约大小的增加而增加。

启用部分代码加载，有助于执行大型智能合约。

Devex：将允许使用dupN/swapN修复solidity中的“堆栈过深”问题，并改进其他工具。

面向未来：可以安全地跨L2引入新功能，并且工具会知道什么是兼容的。。

劣势：

范围和移动目标。

没有支持者大力推动将其纳入。

遗留代码仍需支持。

在采用之前，以太坊主网和其他EVM链之间存在暂时分歧。

我们认为应在2024年部署以下EOF功能。我们建议尽快确定范围，并做出承诺。其他内容应考虑后续部署。我们的建议：

EIP-3540:EOF-EVM对象格式v1：引入代码和数据容器，并为以太坊字节码添加结构和版本控制。

EIP-3670：EOF-代码验证：在部署时拒绝任何不遵循EOF格式的合约。强化代码结构，禁用无效和未定义的指令。

EIP-663：无限制SWAP和DUP指令：这解决了solidity中的“堆栈过深”问题，并通过JUMPDEST分析，因为即时值可能会产生副作用。evmlangs非常需要。

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分析，在VerkleTries中仍需要特殊代码处理来将其分割成块。

据我们所知，在无法访问源工件的情况下，没有可验证的方法将非EOF字节代码转换为EOF，但我们愿意研究促进这种转换的机制。

另外，我们也愿意探索强制将状态迁移到EOF的老方法。

增加EIP-4844Blob数量

我们对这一更改持开放态度，这相当于增加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.375MB），最大值为6个Blob（0.75MB）。这些较小的初始限制旨在最大限度地减少本EIP对网络造成的压力，随着网络在更大区块下显示出可靠性，预计将在未来的升级中增加这些限制。

实际上，这只是一个很小的代码变更，我们需要在txpool中调查其实际影响，但我们认为可以为此重新使用EIP-4844压力测试基础架构。可能CL更难传播更多的Blob；我们听从CL团队的意见。

不支持

Verkle尝试

TL;DR：我们认为Verkletries无法在2024年底/2025年初部署。我们建议团队在2024年第二季度为此分配资源，并承诺在2025年第二季度至第三季度的Osaka硬分叉中进行部署。

优势：

通过更小的存储证明，使轻量级客户端更便宜。

通过在代码区块的头中包含读取预状态来实现无状态执行，这也可能通过静态状态访问来提高性能。

通过分块字节码和启用部分代码加载，提高合约大小限制。

由于“恢复”状态的成本较低，状态过期变得更容易接受。

劣势：

变化的影响以及实施和测试的整合工作。

Gas核算更改：Verkle尝试将证人的大小引入Gas计算功能。我们担心尚未对存储定价的变化进行探讨（例如，Verkle推出后，顶级Gas消耗者的成本会是多少）？

应用集成：在叠加过渡运行期间，使用MerklePatriciaTrie校验器的应用程序应该做些什么？eth_getProof应该如何运行？

虽然我们理解VerkleTries的好处，但我们认为需要更多考虑第三方工具/合约需要如何调整，以及过渡对第2层解决方案等的影响。起初，我们对迁移策略存有疑虑，因为该策略规定，当从先前存在的MPT中读取状态时，Verkletrie应进行更新，但现在似乎不再是这样了。因此，我们支持将覆盖树方法作为一种可行的迁移路径。

一般来说，Verkle迁移策略的文档似乎已经过时，因为大多数资源仍然指出，当从MPT中读取状态时，Verkle三元组应该更新，尽管事实并非如此。我们希望看到用最新方法更新关键转换文档，比如这份出色的文档。我们还希望看到关于过渡策略的EIP草案。

因此，我们仍然支持在2025年推出，但看不到在Prague部署的路径。

L1Gas限制

我们认为，由于需求诱导，提高L1Gas限值在实践中不会有太大作用。我们还认为，大多数客户都能承受平均负载的增加，但我们希望对最坏的情况保持警惕，因此我们还不能建议提高L1Gas限制。我们认为，在短期内，增加BlobGas限制是一个更有前途的解决方案。

我们邀请大家与我们合作，共同开展这方面的研究，以及围绕打破EVM中资源计量的总体研究。BrokenMetre论文是这一研究方向的良好起点。

账户抽象

我们对纳入其中一个或多个EIP（或将ERC纳入其中）持开放态度，但我们更希望看到每个提案之间更多的用户体验和DevEx比较，以便更好地了解工具集成的权衡空间和工作量。我们关注以下EIP/ERC，但欢迎向我们提出更多建议：

EIP-3074：AUTH和AUTHCALL操作码

ERC-4337：使用AltMempool的账户抽象

EIP-5806:委托交易

EIP-5920：PAY操作码

EIP-6913：SETCODE指令

EIP-7377:迁移交易

RIP-7560：原生账户抽象-核心EIP-FellowshipofEthereumMagicians

我们要提醒的是，在上文中，“账户抽象”是指“抽象验证功能，其主要目标是实现密钥轮换、使多重签名成为一流的，并为我们提供一条自动实现量子抗性的途径”（h/tVB），只适用于上文的4337和7560，而其他建议则分为两类，即Gas赞助和批量操作。