Paradigm CTO: Interpreting the Prague Hard Fork After the Ethereum Cancun Upgrade

Author: Georgios Konstantopoulos, Paradigm CTO

Translation: Luffy, Foresight News

The purpose of this article is to outline the Paradigm Reth team's views on which EIPs should be included in the Prague hard fork (the next major upgrade of Ethereum after the Cancun hard fork) and our overall plan for "EL Core Dev" in 2024. The views expressed below are constantly evolving and only represent the current views of the Reth team, not necessarily the entire Paradigm team.

We believe that the Prague hard fork may be implemented on the Ethereum test network in the third quarter of 2024 and completed on the main network by the end of the year. It should include:

EIPs related to staking, such as EIP-7002, which supports re-staking and trustless staking pools.
Separate EVM changes.
We are willing to collaborate with any team interested in further researching the Prague or other future EL hard forks and are willing to provide guidance and assistance in modifying the Reth codebase.

To do:

We believe the following EIPs should be given priority: 7002, 6110, 2537.
We support the description of EOF in the specification and hope to finalize the scope and create a meta EIP as soon as possible.
We are willing to add EIP-4844 Max Blob Gas. We have no specific opinion on the numbers, but we invite data personnel to collaborate with us on researching this topic.
We are willing to release a version of EIP-7547: it includes a list to help the base layer resist censorship.

Don't do:

We do not support the inclusion of Verkle Tries in the Prague hard fork, but we support client teams' efforts to start working on this in the second quarter of 2024 and commit to releasing it in the Osaka upgrade in 2025.
We believe that there should not be an increase in L1 execution gas limits or contract size, but we invite data personnel to collaborate with us to investigate its impact on the network. We are willing to change our views as past tests have shown that Reth nodes can handle increased loads without any issues.
We believe that wallet/account abstraction EIPs need more adversarial testing with each other to better understand the trade-off space. If they are not mutually exclusive, then we will be willing to deploy multiple EIPs related to AA in the future.
If the community agrees on the rumored NSA backdoor, we can skip the line on EIP-7212 (secp256r1).
Other roadmap topics: We do not have a practical understanding of the coupling of CL EIP or CL/EL forks, but EIPs 7549 and 7251 look promising. We also hope to contribute to the work of PeerDAS from the EL perspective as much as possible. Currently, we hope to avoid introducing SSZ roots (EIP 6404, 6465, 6466). Finally, we see an opportunity to provide long-term data archiving solutions for expired blobs, history, and states, as both EIP-4844 and EIP-4444 explicitly state, whether Ethereum is willing to provide such a solution remains to be determined.

Details are provided below.

Things to do

In abstract terms, we support 1) further narrowing the gap between CL and EL, 2) EVM changes that can be executed as individual work and can be tested separately and in parallel.

EIP-7002

This EIP allows smart contracts on the EL side to control one or more validators on the CL side to unlock trustless re-staking and staking pools. In our view, it will at least allow existing staking pools to eliminate a layer of centralization from the smart contract implementing withdrawals.

Introducing stateful precompiles into the EVM is a new abstraction we need to obtain 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 EL state, simplifying the state management that needs to be completed on the CL. In implementation, this is similar to tracking CL withdrawals, so overall, we believe this is also a simple and independent EIP.

EIP-2537

Currently, there are multiple implementations of BLS12-381, which is a curve frequently used in many SNARKs, BLS signature algorithms, and EIP-4844. We believe its implementation complexity is low, as it only exposes the curve's verification algorithm through a precompile interface. We may also need the hash of the BLS12-381 curve precompile.

EOF

EOF will support both Solidity and Vyper. Undoubtedly, code formatting and verification adjustments will make bytecode analysis simpler, and we suggest considering things other than this. We have recommended some EIPs below, but we are willing to make further adjustments.

Good aspects:

Changes limited to the EVM, can be tested using Ethereum/test networks and implemented by a single person.
EVM changes desired by Vyper and Solidity.
Contributes to improving performance and increasing contract size limits.
Eliminates the need for bytecode analysis at runtime. Analysis time can be as high as 50% without involving caching and increases with contract size.
Enables partial code loading, which helps execute large smart contracts.
Devex: will allow for fixing "stack too deep" issues through improvements using dupN/swapN and other tools.
Future-oriented: can safely introduce new features across L2 and tools will know what is compatible.

Bad aspects:

Scope and dynamic targets.
Lack of strong supporters pushing for its inclusion.
Still needs to support legacy code.
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 finalizing the scope as soon as possible and committing to implementation. Any other considerations should be made for subsequent deployments. Our recommendations are:

EIP-3540 (EOF - EVM Object Format v1): Introduces code and data containers and adds structure and version control to Ethereum bytecode.
EIP-3670 (EOF - Code Verification): Rejects any contracts that do not comply with the EOF format when deployed. Executes more structured code and disables invalid and undefined instructions.
EIP-663 (Unlimited SWAP and DUP instructions): This solves the "stack too deep" issue in Solidity and has side effects through JUMPDEST analysis as an immediate value. A feature highly desired by the evm language.
EIP-4200 (EOF - Static Relative Jumps): Better static analysis, no uncertain jumps. Better aot compilation. Relative jumps are more conducive to code reuse.
EIP-4750 (EOF - Functions): Needs to address subroutines that can use dynamic jumps but not static jumps. It also allows for partial code loading, which complements Verkle perfectly and increases contract size limits.
EIP-5450 (EOF - Stack Verification): Verifies code and stack requirements. Removes runtime stack underflow and overflow checks for all instructions except CALLF (EIP-4750).
EIP-7480 (EOF - Data Section Access Instructions): Allows access to the data section of the bytecode.
EIP-7069 (Improved CALL Instructions): Ability to remove 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 are not very sure about EIP-6206 (EOF - JUMPF and non-returning functions). Although it allows tail call optimization in EOF functions, we still need to see language analysis of its impact. If we haven't, we think it can be removed from the scope and included in subsequent EOF updates.

We estimate the above workload to be 1 person working full-time for 1-2 months. We are willing to further narrow the scope above.

Regarding comments on legacy bytecode:

While we can prohibit new legacy/non-EOF bytecode, we cannot deprecate existing legacy bytecode, which actually serves as EOF "v0". Legacy bytecode still requires JUMPDEST analysis after EOF and still requires special code handling to segment it into blocks in Verkle Tries.
As far as we know, the transition from non-EOF bytecode to EOF cannot be verified without access to the source code, but we are willing to study mechanisms to facilitate this transition.
Alternatively, we are willing to explore methods to enforce state migration to EOF.

Increase EIP-4844 Blob Count

We are open to this change, which would correspond to an increase in MAXBLOBGASPERBLOCK and TARGETBLOBGASPERBLOCK. The relevant content in EIP-4844 states:

Choose values for TARGETBLOBGASPERBLOCK and MAXBLOBGASPERBLOCK to correspond to a target of 3 blobs (0.375 MB) per block (up to 6 blobs). These small initial limits are intended to minimize the pressure this EIP puts on the network, and it is expected that the blob count will 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 EIP-4844 stress testing infrastructure for this. It may be difficult for CL to propagate more blobs, and we respect the opinion of the CL team.

Things not to do

Verkle Tries

TL;DR: We do not see attempts to deploy Verkle by the end of 2024/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 the Osaka hard fork.

Good aspects:

Achieving cheaper 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.
Increasing contract size limits by chunking bytecode and enabling partial code loading.
Lower cost of "recovery" of states, making state expiry more acceptable.

Bad aspects:

Impact of changes and effort in implementation and testing.
Gas calculation changes: Verkle Tries introduces the size of witnesses into gas calculation. We are concerned that pricing changes for storage have not been explored (e.g., what is the cost of the top-level gas consumer after Verkle?).
Application integration: What should applications with Merkle Patricia Trie verifiers do when transitioning to Overlay? 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 adapt and what impact there will be on Layer 2 during the transition period. Initially, we had concerns about the migration strategy as it stipulated that when reading state from a pre-existing MPT, the Verkle trie should be updated, but it seems that this is no longer the case. Therefore, we support the Overlay method as a viable migration path.

The documentation for Verkle migration strategy seems outdated, as most resources still indicate that the Verkle trie should be updated when reading state from MPT. We would like to see transition documents adopting the latest methods, such as this excellent document. We also hope to see an EIP draft on transition strategies.

Therefore, we still support its launch in 2025, rather than deployment in the Prague hard fork.

L1 Gas Limit

We believe that increasing the L1 Gas limit will not have a significant impact in practice. 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 do not recommend increasing the L1 Gas limit. We believe that increasing the blob Gas limit is a more promising solution in the short term.

We invite others to collaborate with us on research in this direction, typically revolving around breaking resource metering in the EVM. The Broken Meter paper is a good starting point for such research.

Account Abstraction

We are willing to include one or more EIPs, but we would like to see more comparisons of user experience and developer experience between each proposal to better understand the trade-off space and workload of tool integration. We are paying attention to the following EIPs/ERCs, but please feel free to suggest others to us:

EIP-3074: AUTH and AUTHCALL opcodes
ERC-4337: Account abstraction using Alt Mempool
EIP-5806: Delegated transactions
EIP-5920: PAY opcode
EIP-6913: SETCODE instruction
EIP-7377: Migration transactions
RIP-7560: Native account abstraction - Core EIP - Fellowship of Ethereum Magicians

It should be noted that "account abstraction" as "abstract verification functions, with the primary goal of implementing key rotation, making multisig critical, and providing us with a path to automatically implement quantum resistance."

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。