Due to the induced demand, raising the L1 gas limit will not actually have much effect.
Written by: Georgios Konstantopoulos
Translated by: DeepTechFlow
Introduction
The purpose of this article is to outline the Paradigm Reth team's views on which EIPs (Ethereum Improvement Proposals) should be included in the Prague hard fork (the next EL hard fork after the Cancun fork) and the 2024 "EL Core Development" plan. The views expressed in this article represent the current views of the Reth team and do not necessarily represent the position of the entire Paradigm team.
Abstract
We believe that the Prague hard fork may be implemented on the Ethereum testnet in the third quarter of 2024 and on the mainnet by the end of the year. It should include:
Any EIP related to staking, such as EIP-7002, which supports re-staking and trustless staking pools.
Independent EVM changes.
We are willing to collaborate with any team to further investigate the challenges of the Prague or other future EL hard forks and are happy to provide guidance or assist in adjusting the Reth codebase.
To-Do List:
We believe the following EIPs should be given priority consideration: 7002, 6110, 2537.
We support the specification description of EOF (EVM Object Format) but hope to determine its scope as soon as possible and create a meta-EIP dedicated to that scope.
We are willing to increase the maximum Blob Gas of EIP-4844. We do not have a specific opinion on the correct number, but we invite data analysts to collaborate with us to investigate this topic.
We are willing to introduce a version of EIP-7547: including lists to help resist review at the grassroots level.
Not-To-Do List:
We do not support the introduction of Verkle Tries in Prague, but we support client teams' efforts to implement it starting from the second quarter of 2024 and commit to releasing it in the Osaka hard fork in mid/late 2025.
We believe that the L1 execution gas limit or contract size should not be increased, but we invite data analysts to collaborate with us to investigate the impact on the network. We are willing to reconsider our position based on past test results (showing that Reth nodes can handle the increased load).
We believe that EIPs for wallet/account abstraction 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 in the future.
If the community accepts the rumored NSA backdoor on EIP-7212 (secp256r1), we may make a decision.
Other roadmap topics: We do not have a direct opinion on the coupling of CL EIP or CL/EL forks, but EIP 7549 and 7251 look promising. We are also willing to contribute to PeerDAS's work from the EL perspective as much as possible. We currently hope to avoid introducing SSZ roots (EIP 6404, 6465, 6466). Finally, we note the opportunity to provide long-term data archiving solutions for expired blobs, history, and states, as neither EIP-4844 nor EIP-4444 specifies this, and whether Ethereum is willing to provide such a solution remains to be determined.
The following is a detailed introduction of the full text.
To-Do List:
In short, we support
Further narrowing the gap between CL and EL
EVM modifications that can be executed as single-person work, independently and in parallel testing.
EIP-7002
This EIP allows smart contracts on the EL side to control 1 or more validators on the CL side, unlocking trustless re-staking and staking pools. From our perspective, this is an effortless EIP, as it can at least remove a layer of centralization from existing staking pools in the smart contract implementation.
Introducing stateful precompiles to the EVM is a new abstraction we need to capture in the EVM implementation, but other than that, we believe this is an EIP that can be directly implemented.
EIP-6110
This EIP introduces deposits in the EL state, simplifying the state management required on the CL side. In essence, this is similar to tracking CL withdrawals, so overall, we believe this is also an easy and independent implementation of an EIP.
EIP-2537
There are currently multiple implementations of BLS12-381, and it is a curve frequently used in many SNARKs, BLS signature schemes, and EIP-4844. We believe the implementation complexity is low, as it simply exposes the curve's verification algorithm through a precompile interface. We may also need a hash interface for the BLS12-381 curve precompile.
EOF
In short: support for a clearly defined version that will be adopted by Solidity and Vyper. Code formatting and verification adjustments can make analysis easier, which is beyond doubt. In addition, we suggest careful consideration. We propose adopting the following EIPs, but we are open to further reductions.
Pros:
Only involves changes to the EVM, can be tested through ethereum/tests, and implemented by one person
Changes to the EVM that Vyper and Solidity want
Helps improve performance and increase the contract size limit
Eliminates the need for bytecode analysis at runtime in the EVM, which can take up to 50% of the analysis time without involving caching and increases with increasing contract size
Supports partial code loading, which helps execute large smart contracts
Development experience: will allow for improvements to fix "stack too deep" issues through dupN/swapN and other tools
Future-oriented: can safely introduce new features in L2, and tools will know which ones are compatible
Cons:
Scope and moving targets
Lack of strong advocates to push for its inclusion
Legacy code still needs support
Temporary divergence between the Ethereum mainnet and other EVM chains before adoption
We believe the following EOF features should be deployed in 2024. We recommend determining the scope as soon as possible and making a commitment. Other content should be considered for subsequent deployments. Our suggestions include:
EIP-3540: EOF - EVM Object Format v1: Introduces code and data containers, adding structure and version control to Ethereum bytecode.
EIP-3670: EOF - Code Verification: Rejects any contracts deployed that do not adhere to the EOF format. Implements more structured code and disables invalid and undefined instructions.
EIP-663: Unrestricted SWAP and DUP Instructions: This addresses the "stack too deep" issue in Solidity, with immediate value for JUMPDEST analysis that may have side effects. This is very appealing for the EVM language.
EIP-4200: EOF - Static Relative Jumps: Better static analysis with no uncertain jumps. Relative jumps are more conducive to code reusability.
EIP-4750: EOF - Functions: Addresses potential subroutines issues when using static jumps instead of dynamic jumps. Additionally, it allows for partial code loading, which integrates well with Verkle and increases the contract size limit.
EIP-5450: EOF - Stack Verification: Verifies code and stack requirements. Removes runtime stack underflow and overflow checks for all instructions except CALLF (EIP-4750) instruction.
EIP-7480: EOF - Data Section Access Instructions: Allows access to the data section of the bytecode.
EIP-7069: Improved CALL Instruction: Allows for the removal of gas observability from CALL, making it easier to reprice gas in the future. Although independent of EOF, we believe this is a good opportunity to introduce it.
We have lower certainty about EIP-6206: EOF - JUMPF and Non-Return Function. While it allows tail call optimization in EOF functions, we still need to see language analysis of its usefulness. If we don't have these, we believe it can be removed from the scope and included in subsequent EOF updates.
We budget the above work as a full-time job for 1 person for 1-2 months worldwide. If this means maintaining momentum, we are willing to further narrow the scope.
Explanation of Legacy Bytecode:
While we can prohibit new legacy/non-EOF bytecode, we cannot deprecate existing legacy bytecode, which effectively serves as "v0" for EOF. Legacy bytecode still requires JUMPDEST analysis after EOF and also requires special code handling to segment it into Verkle Tries.
To our knowledge, there is no verifiable method to convert non-EOF bytecode to EOF without the source code, but we are willing to explore mechanisms to facilitate this conversion.
Additionally, we are also open to discussing the expiration method for migrating states to EOF.
Increasing EIP-4844 Blob Quantity
We are open to this modification. In the context of EIP-4844, this is equivalent to increasing MAXBLOBGASPERBLOCK and TARGETBLOBGASPERBLOCK:
The target values for TARGETBLOBGASPERBLOCK and MAXBLOBGASPERBLOCK are 3 blobs (0.375 MB) and up to 6 blobs (0.75 MB) per block, respectively. These smaller initial limits are intended to minimize the pressure on the network caused by this EIP, with the expectation of increasing these limits in future upgrades as the network demonstrates reliability under larger blocks.
This is actually a small code change, and we need to investigate its actual impact in the txpool, but we believe we can reuse the stress testing infrastructure of EIP-4844 for this work. It may be more challenging for CL to propagate more blobs, and we defer to the CL team's opinion.
Not-To-Do List
Verkle Tries
In short, we do not see a path for the deployment of Verkle tries by the end of 2024/early 2025. We recommend allocating resources in the second quarter of 2024 and committing to deployment in the second to third quarter of 2025 in the Osaka hard fork.
Pros:
Achieving cheaper light clients through smaller storage proofs.
Achieving stateless execution by including read pre-state in the block header, which also improves performance through static state access.
Improving the contract size limit through chunked bytecode and enabling partial code loading.
Making state expiration more acceptable, as the cost of restoring state is lower.
Cons:
Impact of changes and integration work for implementation and testing.
Gas accounting changes: Verkle Tries introduces witness size into gas calculation functions. We are concerned that the changes in storage pricing have not been explored (e.g., what will be the cost of the top-level gas consumer after Verkle?).
Application integration: How should applications with Merkle Patricia Trie validators handle overlay transitions? How should eth_getProof behave?
While we understand the benefits of Verkle Tries, we believe more consideration is needed for how third-party tools/contracts will need to adjust and the impact on transitioning to Layer 2 solutions, among other things. Initially, we were skeptical of the migration strategy, as it requires updating Verkle trees when reading state from the existing MPT (Merkle Patricia Trie), but it seems that this situation has changed. Therefore, we support the overlay tree method as a viable migration path.
The documentation on the migration strategy for Verkle trees is generally outdated, with most resources still claiming that Verkle trees should be updated when reading state from MPT, although this is not actually the case. We hope to see key transition documents updated to the latest methods, such as this excellent document. We also hope to see a draft EIP on the migration strategy.
Therefore, we still support its launch in 2025, but we do not believe there is a possibility of deploying the system in Prague.
L1 Gas Limit
We believe that due to induced demand, increasing the L1 gas limit will not actually have much effect. We also believe that most clients can handle an increase in average load, but we want to remain cautious about worst-case scenarios, so we currently cannot recommend increasing the L1 gas limit. We believe that increasing the blob gas limit in the short term is a more promising solution.
We invite people to collaborate with us on research in this area, typically around breaking resource metering in the EVM. The "Broken Metre" paper is a good starting point for this research direction.
Account Abstraction
We are willing to include one or more of these EIPs (or incorporate ERCs), but ideally, we would like to see more comparisons of user experience and developer experience for each proposal to better understand the trade-off space and workload of tool integration. We are keeping an eye on the following EIPs/ERCs, but we also welcome recommendations for more.
It should be noted that in the above content, "account abstraction" refers to "abstract verification functions, primarily aiming to achieve key rotation, making multisig a first-class technique, and providing us with an automatic quantum-resistant path, applicable only to 4337 and 7560, while the other proposals are divided into two categories: Gas sponsorship and batch operations."
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
