Original Title: What comes after Ethereum's Cancun hard fork?
Original Author: Georgios Konstantopoulos, Paradigm Research Partner & CTO
Original Translator: defioasis, Wu Blockchain
Abstract
The purpose of this article is to outline the views of the Paradigm Reth team on which EIPs (Ethereum Improvement Proposals) should be included in Prague, the next EL (Ethereum Execution Layer) hard fork after Cancun, and an overview of our "EL Core Developer" plan for 2024. The following views are still evolving and represent only the current views of the Reth team, not necessarily those of the broader Paradigm team.
We believe that in the third quarter of 2024, the Prague hard fork will be feasible on the Ethereum test network and can be implemented on the main network by the end of the year. It should include:
(1) EIPs related to staking, such as EIP-7002, which enables restaking and trustless staking pools.
(2) Independent EVM changes.
(3) We are willing to work with any team interested in further exploring the challenges of Prague or other future EL hard forks, and are happy to provide guidance or receive suggestions for modifying the Reth codebase.
Recommendations:
(1) We believe the following EIPs should be given priority: 7002, 6110, 2537.
(2) We support EOF as described in the specification, but hope to determine the scope as soon as possible and create a meta-EIP to commit to this scope. (Note: EOF stands for EVM Object Format, which makes some changes to Ethereum's code execution environment. Some developers have proposed including EOF in the next execution layer upgrade Prague, but currently there are differing views, with some believing that its specification has not been finalized, and others believing that Verkle Tries should be the focus of the next upgrade.)
(3) We are open to increasing the maximum Blob Gas for EIP-4844. We do not have a specific view on the correct number, but invite experts in the field to collaborate with us to investigate this topic. (Note: Blob is a storage structure used to submit transaction data from L2 to L1, and has its own pricing system, Blob Gas.)
(4) We are open to introducing EIP-7547: Inclusion lists to help improve base layer resistance to review.
Not Recommended:
(1) We do not support the introduction of Verkle Tries in Prague, but support client teams working towards this direction from the second quarter of 2024, and commit to implementing it in Osaka in mid/late 2025. (Note: Verkle is a data structure that Ethereum will transition to in the future, and compared to the current Merkle Trie structure, Verkle has advantages in proof size and verification efficiency, and is an indispensable part of Ethereum's statelessness in the future.)
(2) We believe that there should not be an increase in L1 execution gas limits or contract size, but we invite data experts to collaborate with us to study the impact on the network. We are open to this because past tests have shown that Reth nodes can handle increased loads without issues.
(3) We believe that EIPs related to wallet/account abstractions need more practical testing to better understand the trade-offs between them. If they are not mutually exclusive, then we are willing to deploy multiple EIPs related to AA (account abstraction) in the future.
(4) For EIP-7212 (secp256r1), if the community has no objections to the rumored NSA (National Security Agency) backdoor, we may support it.
(5) Other roadmap topics: We do not have a direct view on the coupling of CL (consensus layer) EIPs or CL/EL (execution layer) forks, but EIP-7549 and EIP-7251 look promising. We are also willing to contribute to PeerDAS's work from the EL side where possible. We currently hope to avoid introducing SSZ roots (EIP-6404, 6465, 6466). Finally, we note that there is an opportunity for a long-term data archiving solution for expired blobs, history, and states, as neither EIP-4844 nor EIP-4444 specifies this, and whether Ethereum wants to provide such a solution remains to be determined.
Specific reasons are as follows
Recommendations
We support 1) further narrowing the gap between the consensus layer (CL) and the execution layer (EL); 2) modifications to the EVM that can be executed as solo work and can be tested in isolation and in parallel.
EIP-7002
This EIP unlocks trustless restaking and staking pools by allowing smart contracts on the execution layer (EL) to control one or more validators on the consensus layer (CL). From our perspective, this is a no-brainer EIP, as it at least removes a centralized layer from the implementation of existing staking pools.
We need to capture the introduction of state precompiles in the EVM implementation, but other than that, we believe this is an EIP that can be executed directly.
EIP-6110
This EIP introduces deposits in the execution layer (EL) state, simplifying the state management required on the consensus layer (CL). From an implementation perspective, this is similar to tracking withdrawals on the consensus layer, so overall, we believe this is also an easy-to-implement and independent EIP.
EIP-2537
There are already multiple implementations of BLS12-381 on the market, which is a curve used frequently in many SNARKs (zero-knowledge proof technology), BLS signature algorithms, and EIP-4844. We believe the implementation complexity is low, as it only exposes the curve's verification algorithm on a precompile interface. We may also need a hash algorithm for the BLS12-381 curve precompile.
EOF
In summary: Support for the explicit versioning that Solidity and Vyper will adopt. Code formatting and verification adjustments make analysis easier, which is an unquestionable choice, and we suggest careful consideration of anything beyond this. We have recommended some EIPs below, but we are also willing to further streamline.
Benefits:
(1) Changes limited to the EVM, can be tested through ethereum/tests, and implemented by one person.
(2) EVM changes desired by Vyper and Solidity.
(3) Helps improve performance and increase contract size limits.
(4) No need for bytecode analysis at runtime in the EVM, which may take up to 50% of the time without involving caching, and increases with increasing contract size.
(5) Support for partial code loading, helpful for executing large smart contracts.
(6) Developer experience: Will allow fixing "stack too deep" issues in Solidity using dupN/swapN, and improve other tools.
(7) Future verification: Can safely introduce new features in L2s, and tools know which ones are compatible.
Drawbacks:
(1) Scope and moving target.
(2) Lack of strong proponents pushing for its inclusion.
(3) Still needs to support legacy code.
(4) Temporary divergence between the Ethereum mainnet and other EVM chains until it is adopted.
We believe the following EOF features should be deployed in 2024. We recommend determining the scope as soon as possible and committing to it. Other content should be considered for subsequent deployments. Our recommendations:
(1) EIP-3540: EOF - EVM Object Format v1: Introduces code and data containers and adds structure and version control to Ethereum bytecode.
(https://eips.ethereum.org/EIPS/eip-3540)
(2) EIP-3670: EOF - Code Verification: Reject contracts deployed that do not adhere to the EOF format. Enforce more structured code and disable invalid and undefined instructions.
(https://eips.ethereum.org/EIPS/eip-3670)
(3) EIP-663: Unrestricted SWAP and DUP Instructions: This addresses the "stack too deep" issue in Solidity, as JUMPDEST analysis as an immediate value may have side effects. This is very beneficial for the EVM language.
(https://eips.ethereum.org/EIPS/eip-663)
(4) EIP-4200: EOF - Static Relative Jumps: Better static analysis, no uncertain jumps. Better AOT compilation. Relative jumps are more conducive to code reuse.
(https://eips.ethereum.org/EIPS/eip-4200)
(5) EIP-4750: EOF - Functions: Addresses the issue of subroutines that can be used for dynamic jumps but not for static jumps. It also allows for partial code loading, which complements Verkle and the increase in contract size limits.
(https://eips.ethereum.org/EIPS/eip-4750)
(6) EIP-5450: EOF - Stack Verification: Verifies code and stack requirements. Removes runtime stack underflow and overflow checks for all instructions except CALLF (EIP-4750).
(https://eips.ethereum.org/EIPS/eip-5450)
(7) EIP-7480: EOF - Data Segment Access Instructions: Allows access to bytecode data segments.
(https://eips.ethereum.org/EIPS/eip-7480)
(8) EIP-7069: Improved CALL Instruction: Makes it possible to remove gas observability from CALLs, which will make it easier to reprice gas in the future. Although unrelated to EOF, we believe this is a good opportunity to introduce it.
(https://eips.ethereum.org/EIPS/eip-7069)
Regarding EIP-6206: EOF - JUMPF and Non-Return Functions, our view is not so certain. While it allows tail call optimization in EOF functions, we still need to see language analysis of its effectiveness. If there is no such analysis, we believe it is feasible to exclude it from the scope and include it in subsequent EOF updates.
We expect the above work to be carried out by one full-time person and will take 1-2 months. We are willing to further streamline if reducing the scope means maintaining progress.
Regarding legacy bytecode:
(1) While we can prohibit new legacy/non-EOF bytecode, there is no way to phase out existing legacy bytecode, which effectively serves as the "v0" version of EOF. Legacy bytecode still needs JUMPDEST analysis after EOF and segmenting it in Verkle Tries still requires special code handling.
(2) To our knowledge, there is no way to verifiably convert non-EOF bytecode to EOF without source code artifacts, but we are willing to explore mechanisms to facilitate such conversions.
(3) Additionally, we are also willing to explore mechanisms to enforce the migration of state to EOF.
Increasing EIP-4844 Blob Quantity
We are open to this change, which will correspondingly increase MAXBLOBGASPERBLOCK (maximum Blob Gas limit per block) and TARGETBLOBGASPERBLOCK (target Blob Gas limit per block).
In the context of EIP-4844: TARGETBLOBGASPERBLOCK and MAXBLOBGASPERBLOCK are chosen to correspond to a target of 3 blobs per block (0.375 MB) and a maximum of 6 blobs per block (0.75 MB). These small initial limits are intended to minimize the pressure this EIP puts on the network and are expected to increase in future upgrades as the network demonstrates reliability under larger blocks.
In practice, this is a small code change, and we need to investigate its actual impact in the transaction pool, but we believe we can reuse the pressure testing infrastructure of EIP-4844 for this work. The CL (consensus layer) may have greater difficulty in propagating more blobs; we defer to the CL team's opinion.
Not Recommended:
Verkle Tries
We do not see a path to deploying Verkle tries from late 2024 to early 2025. We suggest allocating resources for this in the second quarter of 2024 and committing to deployment in the second to third quarter of 2025 in Osaka.
Benefits:
(1) Achieving cheaper light clients through smaller proof sizes.
(2) Performance improvements through stateless execution by including pre-state reads in block headers, which may also bring performance improvements due to static state access.
(3) Increasing contract size limits through chunked bytecode and enabling partial code loading.
(4) With reduced cost of "revive" states, state expiry becomes more feasible.
Drawbacks:
(1) Impact of changes and integration workload for implementation and testing.
(2) Gas computation changes: Verkle tries introduce witness size into gas computation functions. We are concerned about the lack of discussion on changes to storage pricing (e.g., what will be the cost of top-level gas consumers after Verkle).
(3) Application integration: What should applications with Merkle Patricia Trie validators do during overlay transition? How should eth_getProof behave?
While we understand the benefits of Verkle tries, we believe more thought is needed about how third-party tools/contracts need to adapt and what impact the transition will have on solutions such as Layer 2. Initially, we were skeptical of the migration strategy as it stipulated that Verkle tries should be updated when reading state from existing MPT (Merkle Patricia Trie), but it seems this is no longer the case. Therefore, we support the overlay tree method as a viable migration path.
The documentation on Verkle transition strategy seems outdated overall, as most resources still indicate that Verkle trie should be updated when reading state from MPT, although this is not the case. We would like to see critical transition documents updated with the latest methods (e.g., https://notes.ethereum.org/@parithosh/verkle-transition). We also hope to see an EIP draft on transition strategies.
Therefore, we still support deployment in 2025 but do not believe it should be deployed in the Prague fork.
L1 Gas Limit
We believe that increasing the L1 gas limit will not have a significant impact in practice due to derived demand. We also believe that most clients can handle an average load increase, but we want to remain cautious about worst-case scenarios, so we cannot yet recommend increasing the L1 gas limit. We believe that increasing the Blob Gas limit is a more promising solution in the short term.
Account Abstraction
We are open to including one or more EIPs (or incorporating ERCs) into this, but we would like to see more user experience and developer experience comparisons between each proposal to better understand the trade-offs and workload of tool integration. We are interested in the following EIP/ERC, but welcome more suggestions:
(1) EIP-3074: AUTH and AUTHCALL opcodes
(https://eips.ethereum.org/EIPS/eip-3074)
(2) ERC-4337: Account Abstraction using Alt Mempool
(https://eips.ethereum.org/EIPS/eip-4337)
(3) EIP-5806: Delegated Transactions
(https://eips.ethereum.org/EIPS/eip-5806)
(4) EIP-5920: PAY Opcode
(https://eips.ethereum.org/EIPS/eip-5920)
(5) EIP-6913: SETCODE Instruction
(https://eips.ethereum.org/EIPS/eip-6913)
(6) EIP-7377: Migration Transactions
(https://eips.ethereum.org/EIPS/eip-7377)
(7) RIP-7560: Native Account Abstraction - Core EIP - Ethereum Magicians
(https://ethereum-magicians.org/t/rip-7560-native-account-abstraction/16664)
It should be noted that in the above content, "account abstraction" refers to "abstract verification functionality, with the primary goal of implementing key rotation to make multisig a core feature of the blockchain and provide us with an automatic quantum-resistant path" (h/t VB), applicable only to 4337 and 7560, while other proposals are divided into two categories, namely Gas Sponsorship and Batch Operations.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
