原文：《WhatcomesafterEthereum'sCancunhardfork?》
作者：GeorgiosKonstantopoulos
编译：星球日报Moni
一、内容概述
本文将分析ParadigmReth团队对Prague（布拉格）硬分叉（Cancun 坎昆升级后的下个执行层硬分叉）包含的重要EIP（以太坊网络改进协议）的理解以及对 2024 年“ELCoreDev”计划的看法。
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-4844MaxBlobGas，对其中正确的数字不做过多评论，但会邀请数据人员合作调研该EIP。
4、对于发布EIP-7547：InclusionLists版本，Paradigm持开放态度，该EIP可以帮助抵抗基础层审查。
Paradigm不认同的方向：
1、Paradigm不支持Prague硬分叉所采用的VerkleTries数据结构，但支持客户端团队在2024年第二季度开始为此努力，同时承诺于2025年中/下旬在大阪升级发布。
2、Paradigm认为不应该增加L1执行Gas限制或合约规模，但会邀请数据人员合作调查这种做法对以太坊网络的影响。同时Paradigm愿意调整自己的看法，因为过去的测试表明Reth节点可以毫无问题地处理增加的负载。
3、Paradigm认为钱包/账户抽象EIP需要进行更多的相互对抗测试，以更好地了解权衡网络空间。如果钱包/账户抽象不相互排斥，那么将愿意在未来部署多个与账户抽象相关的EIP。
4、如果社区同意传闻中的NSA后门，Paradigm认为可以越过EIP-7212(secp256r1)的线路。
5、其他路线图主题：Paradigm对共识层EIP或CL/EL（共识层/执行层）分叉耦合没有做过实际了解，但EIP7549和EIP7251两个提案似乎很有前途。Paradigm还希望尽可能从EL方面为PeerDAS的工作做出贡献，目前希望避免引入SSZ根（EIP6404、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
现阶段，BLS12-381有多种实现，是许多SNARK、BLS签名算法和EIP-4844中经常使用的曲线。Paradigm认为BLS12-381实现复杂度较低，因为它只是通过预编译接口公开曲线的验证算法，因此可能还需要BLS12-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“v0”。遗留字节码仍然需要EOF后的JUMPDEST分析，并且仍然需要特殊的代码处理以将其分段为VerkleTries中的区块。
●据Paradigm所知，如果不访问源代码，就无法验证从非EOF字节码到EOF的转换，但Paradigm愿意研究促进这种转换的机制。
●或者，Paradigm愿意探索强制状态迁移到EOF的到期方法。
增加EIP-4844Blob数量
Paradigm对这一更改持开放态度，对应地，将增加“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对网络造成的压力，随着网络在较大区块下展现出可靠性，也可以在后续的升级中增加初始限制大小。
实际上，相关代码更改不会太大，但Paradigm需要调查这些更高对txpool中的实际影响，因此可以重新使用EIP-4844压力测试基础设施。共识层可能很难传播更多的blob，所以Paradigm也尊重共识层队伍的意见。
Paradigm 不认同的方向
VerkleTries
简单来说，2024年底/2025年初完成Verkle部署的可能似乎不大，Paradigm建议团队在2024年第二季度为此分配资源，并承诺在2025年第二季度至第三季度在大阪硬分叉中进行部署。
好的方面：
●通过更小的存储证明实现成本更低的轻客户端。
●通过在区块标头中包含读取预状态来进行无状态执行，这也可能由于静态状态访问而导致性能改进。
●通过对字节码进行分块并启用部分代码加载来提高合约大小限制。
●由于“恢复”状态的成本较低，状态到期变得更容易接受。
不好的方面：
●实施和测试的变更和集成工作的影响。
●Gas核算变化：VerkleTries将见证人的大小引入到Gas计算功能中，Paradigm担心存储定价的变化尚未被探索（例如，Verkle后头部gas消耗者的成本是多少）。
●应用程序集成：当Overlay转换运行时，带有MerklePatriciaTrie验证器的应用程序应该做什么？应该如何eth_getProof表现？
虽然VerkleTries有一定优势，但Paradigm认为需要更多地考虑第三方工具/合约需要如何适应，以及过渡会对二层解决方案等产生什么影响。最初Paradigm对迁移策略心存疑虑，因为它规定当从预先存在的MPT中读取状态时应该更新VerkleTries，但情况似乎不再如此了。因此，Paradigm支持覆盖Overlay方法作为可行的迁移路径。
Verkle迁移策略的文档通常似乎已经过时，因为大多数资源仍然指出从MPT读取状态时应该更新Verkletrie，即使事实并非如此。Paradigm希望看到关键的过渡文档使用最新的方法进行更新，可参考该文档。Paradigm还希望看到有关过渡战略的生态投资计划草案。
因此，Paradigm仍然支持其在2025年推出，不是在本次硬分叉中部署。
L1Gas限制
Paradigm认为，在需求侧可能存在某些“误导”，实际上，提高L1Gas限制在实践中并不会产生太大影响。Paradigm还认为大多数客户端可以应对平均负载增加，但Paradigm希望对最坏的情况保持警惕，因此目前不建议增加L1Gas限制。Paradigm认为，短期内增加blobGas限制是一个更有希望的解决方案。
Paradigm希望邀请社区合作进行相关方向的研究，通常围绕打破EVM中的资源计量进行。BrokenMeter发布的这篇论文应该是该研究领域的一个很好起点。
账户抽象
Paradigm愿意在硬分叉中包含1个或多个EIP（或纳入ERC），但理想情况下，更希望看到每个提案之间有更多的用户体验和开发者体验对比，这样可以更好地了解工具集成的权衡空间和工作量。Paradigm正在关注以下EIP/ERC，社区可以随时向Paradigm提出建议：
●EIP-3074：AUTH和AUTHCALL操作码
●ERC-4337：使用AltMempool进行账户抽象
●EIP-5806：委托交易
●EIP-5920：PAY操作码
●EIP-6913：SETCODE指令
●EIP-7377：迁移交易
●RIP-7560：原生帐户抽象-核心EIP-FellowshipofEthereumMagicians
最后需要提醒的是，“帐户抽象”仅适用于上述EIP-4337和EIP-7560，而其他提案主要涉及两个领域，分别是：Gas赞助和批量操作。（“帐户抽象”就像对验证函数进行抽象，主要目标是启用密钥轮换，使多重签名成为关键要素，并为我们提供一条自动实现量子抗性的路径。）
",
