original:What comes after Ethereums Cancun hard fork?》
Author: Georgios Konstantopoulos
Compiled by: Odaily Moni
1. Content overview
This article will analyze the Paradigm Reth team’s understanding of the important EIP (Ethereum Network Improvement Protocol) included in the Prague (Prague) hard fork (the next execution layer hard fork after the Cancun upgrade) and its understanding of the 2024 “EL Core Dev View of the plan.
The Prague hard fork may take place on the Ethereum testnet in the third quarter of 2024 and be implemented on the mainnet before the end of the year.Its upgrade content includes：
1. It is recommended to include EIPs related to staking, such as EIP-7002, to activate re-staking and staking pools that do not require external trust;
2. Independent EVM changes;
In addition, Paradigm is willing to work with any team wishing to further investigate difficult issues in EL hard forks such as Prague, and is happy to provide guidance including modifying the Reth code base.
Directions recognized by Paradigm:
1. Paradigm believes that the following EIPs should be given priority: 7002, 6110, 2537.
2. Paradigm supports the Ethereum Object Format (EOF) described in the specification, but hopes to determine the scope as soon as possible and create a meta-EIP dedicated to this scope.
3. Paradigm is willing to add EIP-4844 Max Blob Gas. It will not comment too much on the correct number, but will invite data scientists to cooperate in investigating the EIP.
4. Paradigm is open to releasing EIP-7547: Inclusion Lists version, which can help resist base layer censorship.
Directions that Paradigm does not agree with:
1. Paradigm does not support the Verkle Tries data structure used in the Prague hard fork, but supports the client team to start working on this in the second quarter of 2024, and promises to upgrade and release it in Osaka in mid/late 2025.
2. Paradigm believes that L1 execution gas limits or contract sizes should not be increased, but will invite data personnel to cooperate in investigating the impact of this approach on the Ethereum network. At the same time Paradigm is willing to temper its views as past testing shows that Reth nodes can handle the increased load without issue.
3. Paradigm believes that wallet/account abstraction EIP needs to be tested against each other to better understand the trade-offs in cyberspace. If the wallet/account abstraction are not mutually exclusive, then there will be a willingness to deploy multiple EIPs related to the account abstraction in the future.
4. If the community agrees with the rumored NSA backdoor, Paradigm believes that the line of EIP-7212 (secp 256 r 1) can be crossed.
5. Other roadmap topics: Paradigm has no actual understanding of consensus layer EIP or CL/EL (consensus layer/execution layer) fork coupling, but the two proposals EIP 7549 and EIP 7251 seem promising. Paradigm also wants to contribute to the PeerDAS effort as much as possible from the EL side and currently wants to avoid the introduction of SSZ roots (EIPs 6404, 6465, 6466). Finally, Paradigm believes that there should be a long-term data archiving solution for expired blobs, history, and state, as neither EIP-4844 nor EIP-4444 specified this, but whether Ethereum is willing to provide such a solution remains to be determined.
Here are the details:
Paradigm direction of identification
Abstractly speaking, Paradigm mainly supports the following two aspects:
1) Further narrow the gap between the consensus layer and the execution layer;
2) EVM modifications can be performed as a single-person job and tested independently or in parallel.
EIP-7002
This EIP unlocks trustless re-staking and staking pools by enabling smart contracts on the execution layer side to control single or multiple validators on the consensus layer side. From Paradigm’s perspective, this EIP makes some sense and will at least enable existing staking pools to remove a layer of centralization from the smart contracts that enable withdrawals.
In addition, introducing stateful precompilation into EVM is also a feature that Paradigm agrees needs to be met in the EVM implementation, but beyond that, Paradigm believes that this is an EIP that can be directly implemented.
EIP-6110
This EIP introduces the deposit function in the execution layer state, simplifying the state management that needs to be done on the consensus layer. In terms of implementation, this is similar to tracking consensus layer withdrawals, so overall Paradigm feels this is also an easy to implement and independent EIP.
EIP-2537
Currently, BLS 12-381 has multiple implementations and is a commonly used curve in many SNARKs, BLS signature algorithms, and EIP-4844. Paradigm believes that BLS 12-381 implementation complexity is low because it only exposes the verification algorithm of the curve through a precompiled interface, so a precompiled hash of the BLS 12-381 curve may also be required.
Ethereum Object Format (EOF)
Simply put, EOF will support both Solidity and Vyper. With a wider range of releases, code formatting and verification tweaks to make analysis easier are also justified. Paradigm recommends careful consideration of anything beyond this and recommends it below. Some EIPs are also willing to make further adjustments.
good aspect:
● EVM-only changes that can be tested using Ethereum/testnet and implemented by a single person.
● EVM changes desired by Vyper and Solidity.
● Helps improve performance and increase contract size limits.
● Eliminates the need for EVM to perform bytecode analysis at runtime, which can take up to 50% of the time without caching, and increases as the contract size increases.
● Enable partial code loading, Zhejiang helps execute large smart contracts.
● Devex: Will allow fixing stack too deep issues with dupN/swapN and other tooling improvements.
● Future-applicable features: New secure cross-L2 features can be introduced, and the tool will know which features are compatible.
bad side:
● Range and moving targets.
● There is no support for a major push for its inclusion.
● Legacy code still needs support.
● Prior to adoption, there was a temporary divergence between the Ethereum mainnet and other EVM chains.
Paradigm believes the following EOF capabilities should be deployed by 2024 and recommends scoping and committing to implementation as soon as possible. Additional issues should be considered for subsequent deployments. Therefore, Paradigm recommends:
● EIP-3540 (EOF - EVM Object Format v1): Introducing code and data containers and adding structure and versioning to Ethereum bytecode.
● EIP-3670 (EOF - Code Verification): Reject any contract that does not follow the EOF format when deployed, only more structured code can be executed, and invalid and undefined instructions are disabled.
● EIP-663 (unlimited SWAP and DUP instructions): This EIP solves the stack too deep problem in Solidity where using JUMPDEST analysis as immediate values may have side effects, but is a much wanted feature of the EVM becoming a language.
● EIP-4200 (EOF - static relative jump): Better static analysis, no undefined jumps. Better aot compilation and relative jumps are more conducive to code reusability.
● EIP-4750 (EOF – function): It is necessary to solve the problem of subroutines that can use dynamic jumps but not static jumps, and also allow partial code loading, which can work well with Verkle data structures and increase the contract size limit.
● EIP-5450 (EOF - Stack Verification): Verify code and stack requirements. Remove runtime stack underflow and overflow checks for all instructions except CALLF (EIP-4750).
● EIP-7480 (EOF - Data Partial Access Instruction): Allows access to the data portion of the bytecode.
● EIP-7069 (Improved CALL instruction)Being able to remove Gas observability from CALL will make it easier to reprice Gas in the future. Although this EIP is independent of EOF, Paradigm believes that this hard fork is a good opportunity to introduce this EIP.
Paradigm rightEIP-6206 (EOF-JUMPF and non-returning functions)Not so sure, although this EIP allows for tail call optimization in EOF functions, Paradigm still needs to see language analysis for its usefulness. If not, Paradigm deems it appropriate to remove it from scope and include it in subsequent EOF updates.
Paradigm estimates the above workload to be approximately 1-2 person-months on a full-time basis, and is willing to narrow the above range further if the workload assessed is larger.
A note on legacy bytecode:
● While new legacy/non-EOF bytecode can be suppressed, existing legacy bytecode cannot be deprecated since it effectively acts as EOF v 0. Legacy bytecode still requires post-EOF JUMPDEST analysis, and special code handling is still required to segment it into chunks in Verkle Tries.
● To the best of Paradigms knowledge, it is not possible to verify the conversion from non-EOF bytecode to EOF without access to the source code, but Paradigm is willing to investigate mechanisms to facilitate this conversion.
● Alternatively, Paradigm is willing to explore expiration methods that force state migration to EOF.
Increase the number of EIP-4844 blobs
Paradigm is open to this change and, accordingly, will add MAX_BLOB_GAS_PER_BLOCK and TARGET_BLOB_GAS_PER_BLOCK
Choose values for TARGET_BLOB_GAS_PER_BLOCK and MAX_BLOB_GAS_PER_BLOCK to correspond to a target of 3 blobs (0.375 MB) per block (up to 6 blobs, approximately 0.75 MB). These initial limits are not large, but will minimize the stress this EIP puts on the network, and can be increased in subsequent upgrades as the network demonstrates reliability with larger blocks.
In practice, the associated code changes wont be too big, but Paradigm needs to investigate the actual impact of these higher in txpool so the EIP-4844 stress test infrastructure can be reused. The consensus layer may have difficulty propagating more blobs, so Paradigm also respects the opinions of the consensus layer team.
Paradigm does not agree with the direction
Verkle Tries
Simply put, completion of Verkle deployment by the end of 2024/early 2025 seems unlikely, with Paradigm recommending that the team allocate resources to this in Q2 2024 and committing to an Osaka hard fork in Q2-Q3 2025 Deploy.
good aspect:
● Lower-cost light clients through smaller storage proofs.
● Stateless execution by including read pre-state in the block header, which may also lead to performance improvements due to static state access.
● Increase contract size limits by chunking bytecode and enabling partial code loading.
● State expiration becomes more acceptable due to the lower cost of restoring state.
bad side:
● Impact of changes and integration efforts implemented and tested.
● Gas accounting changes: Verkle Tries introduces witness sizing into the gas accounting function, and Paradigm is concerned that storage pricing changes have not yet been explored (e.g., how much does a head gas consumer cost after Verkle).
● Application Integration: What should an application with the Merkle Patricia Trie validator do when the Overlay transformation is running? How should eth_getProof behave?
While Verkle Tries has certain advantages, Paradigm believes more consideration needs to be given to how third-party tools/contracts need to adapt, and what impact the transition will have on second-tier solutions and the like. Initially Paradigm was leery of the migration policy because it stipulated that Verkle Tries should be updated when state is read from a pre-existing MPT, but this does not appear to be the case anymore. Therefore, Paradigm supports overlay methods as a viable migration path.
Documentation of Verkle migration strategies often seems to be out of date, as most resources still state that the Verkle trie should be updated when reading state from MPT, even though this is not the case. Paradigm would like to see key transition documents updated with the latest methods, please refer toThis document. Paradigm also wants to see a draft ecological investment plan on a transition strategy.
Therefore, Paradigm still supports its launch in 2025 and is not deployed in this hard fork.
L1 Gas Limit
Paradigm believes that there may be some misleading on the demand side, and in fact, increasing the L1 Gas limit will not have much impact in practice. Paradigm also believes that most clients can handle the increase in average load, but Paradigm wants to be wary of worst-case scenarios and therefore does not currently recommend increasing the L1 Gas limit. Paradigm believes that increasing the blob gas limit is a more promising solution in the short term.
Paradigm would like to invite the community to collaborate on research in related directions, often around breaking resource metering in EVM. Posted by Broken MeterpaperShould be a good starting point for this area of research.
Account abstraction
Paradigm is willing to include 1 or more EIPs (or incorporate ERCs) in the hard fork, but ideally would like to see more user experience and developer experience comparisons between each proposal, which would be better Understand the trade-off space and effort of tool integration. Paradigm is focusing on the following EIPs/ERCs, and the community can make suggestions to Paradigm at any time:
● EIP-3074: AUTH and AUTHCALL opcodes
● ERC-4337: Account abstraction using Alt Mempool
● EIP-5806: Commissioned transaction
● EIP-6913: SETCODE instruction
● EIP-7377: Migrate transactions
● RIP-7560: Native Account Abstraction - Core EIP - Fellowship of Ethereum Magicians
A final reminder is that account abstraction only applies to the above-mentioned EIP-4337 and EIP-7560, while other proposals mainly cover two areas: Gas sponsorship and batch operations. (Account abstraction is like abstracting the verification function, the main goal is to enable key rotation, make multi-signature a key element, and provide us with an automated path to quantum resistance.)
