Paradigm CTO: After the Ethereum Cancun upgrade, what actions will the next Prague upgrade take?

Original Title: What comes after Ethereum's Cancun hard fork?

Original Author: Georgios Konstantopoulos, Paradigm Research Partner & CTO

Original Compilation: defioasis, Wu Says Blockchain

Abstract

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 (Ethereum Execution Layer) hard fork following Cancun, as well as an overview of our "EL Core Developer" program for 2024. The following views are still evolving and represent the current perspective of the Reth team, not necessarily the broader Paradigm team's views.

We believe that the Prague hard fork is feasible on the Ethereum testnet in Q3 2024 and can be implemented on the mainnet before the end of the year. It should include:

(1) Staking-related EIPs, such as EIP-7002, which enables re-staking and trustless staking pools.

(2) Independent EVM changes.

(3) We are willing to collaborate with any team that wants to further explore the challenging issues of Prague or other future EL hard forks, and we are happy to provide guidance or receive suggestions for modifications to the Reth codebase.

Recommendations:

(1) We believe the following EIPs should be prioritized: 7002, 6110, 2537.

(2) We support EOF as described in the specification, but we hope to define 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 opinions are currently divided, with some believing its specification has not been finalized and others believing 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 numbers but invite experts in the data field to collaborate with us to investigate this topic. (Note: Blob is a storage structure used for storing L2 transaction data submitted to L1 and has its own pricing system, Blob Gas.)

(4) We are open to introducing EIP-7547: Inclusion Lists to help improve grassroots censorship resistance.

Discouraged Items:

(1) We do not support the introduction of Verkle Tries in Prague, but we support client teams working towards this direction starting in Q2 2024, with a commitment to implement it in the Osaka hard fork in mid to late 2025. (Note: Verkle is a data structure that Ethereum will transition to in the future, which has advantages in proof size and verification efficiency compared to the current Merkle Trie structure, and is an essential part of Ethereum's future implementation of statelessness.)

(2) We believe that L1 execution gas limits or contract sizes should not be increased, but we invite data experts to collaborate with us to study the impact of this 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 abstraction need more real-world testing among each other to better understand their trade-offs. If they are not mutually exclusive, we are willing to deploy multiple EIPs related to AA (Account Abstraction) in the future.

(4) For EIP-7212 (secp256r1), we may support it if the community has no objections to the rumored NSA backdoor.

(5) Other roadmap topics: We do not have direct views 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 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 state, as neither EIP-4844 nor EIP-4444 specified this, and it remains to be seen whether Ethereum wants to provide such a solution.

Specific Reasons Below

Recommendations

We support 1) further narrowing the gap between the Consensus Layer (CL) and Execution Layer (EL); 2) modifications to the EVM that can be executed as individual work and can be isolated and tested in parallel.

EIP-7002

This EIP unlocks trustless re-staking and staking pools by allowing smart contracts in the Execution Layer (EL) to control one or more validators in the Consensus Layer (CL). From our perspective, this is a no-brainer EIP, as it at least removes a layer of centralization from existing staking pools by implementing their withdrawal smart contracts.

We need to capture the new abstraction introduced by state precompiles in the EVM implementation, but beyond 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 from 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 frequently used in many SNARKs (zero-knowledge proof technologies), BLS signature algorithms, and EIP-4844. We believe the implementation complexity is low because it simply exposes the verification algorithm of the curve on the precompile interface. We may also need the hashing algorithm for the BLS12-381 curve precompile.

EOF

Brief Summary: Support for a clear scoped version that Solidity and Vyper would adopt. Code formatting and verification adjustments make analysis easier, which is undoubtedly a choice we recommend careful consideration of anything beyond this. We recommend some EIPs below, but we are also willing to further streamline.

Benefits:

(1) EVM-only changes can be tested via 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) Eliminates the need for EVM to perform bytecode analysis at runtime, which can take up to 50% of the time without caching and increases with contract size.

(5) Supports partial code loading, aiding in the execution of large smart contracts.

(6) Developer experience: Will allow the use of dupN/swapN in Solidity to fix "stack too deep" issues and improve other tools.

(7) Future verification: New features can be safely introduced in L2s, and tools know which are compatible.

Drawbacks:

(1) Scope and moving targets.

(2) No strong advocates pushing for its inclusion.

(3) Still need to support legacy code.

(4) There is a 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 defining the scope and committing to it as soon as possible. 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 that do not follow the EOF format at deployment. 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 immediate values can have side effects. This is very beneficial for EVM languages.

(https://eips.ethereum.org/EIPS/eip-663)

(4) EIP-4200: EOF - Static Relative Jumps: Better static analysis with 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: Needs to address the issue of subroutines that can use dynamic jumps but not static jumps. It also allows partial code loading, which pairs well with Verkle and the increased contract size limit.

(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 the bytecode's data segment.

(https://eips.ethereum.org/EIPS/eip-7480)

(8) EIP-7069: Improved CALL Instruction: Makes it possible to remove gas observability from CALLs, which helps to reprice gas more easily in the future. While not related 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-returning functions, our views are less certain. While it allows tail call optimization in EOF functions, we still need to see the language analyze its validity. Without 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 done full-time by one person and to take 1-2 months. If reducing the scope mentioned above means maintaining progress, we are willing to further streamline.

Regarding legacy bytecode:

(1) While we can prohibit new legacy/non-EOF bytecode, there is no way to eliminate existing legacy bytecode, which effectively serves as the "v0" version of EOF. Legacy bytecode still requires JUMPDEST analysis after EOF and will still require special code handling when segmented in Verkle Tries.

(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 coercive methods to migrate state to EOF.

Increasing EIP-4844 Blob Count

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: The values for TARGETBLOBGASPERBLOCK and MAXBLOBGASPERBLOCK were chosen to correspond to a target of 3 blobs (0.375 MB) per block and a maximum of 6 blobs (0.75 MB). These small initial limits are designed 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 stress testing infrastructure of EIP-4844 to do this. The CL (Consensus Layer) may have more difficulty propagating more blobs; we defer to the CL team's advice.

Discouraged Items:

Verkle Tries

We do not see a path to deploying Verkle tries by the end of 2024 or early 2025. We recommend that the team allocate resources for this in Q2 2024 and commit to deploying it in the Osaka hard fork in Q2 to Q3 2025.

Benefits:

(1) Achieves cheaper light clients through smaller storage proofs.

(2) Enables stateless execution by including read pre-state in the block header, which may also bring performance improvements due to static state access.

(3) Increases contract size limits by chunking bytecode and enabling partial code loading.

(4) As the cost of "revive" state decreases, state expiration becomes more feasible.

Drawbacks:

(1) Impact of changes and the integration workload for implementation and testing.

(2) Gas calculation changes: Verkle tries introduce witness size into the gas calculation function. We are concerned that the changes to storage pricing have not yet been discussed (e.g., what will be the cost for top gas consumers after Verkle).

(3) Application integration: What should applications with Merkle Patricia Trie verifiers do during the Overlay conversion run? How should eth_getProof behave?

While we understand the benefits of Verkle tries, we believe more thought is needed regarding how third-party tools/contracts need to adapt and what impact the conversion will have on Layer 2 solutions, for example. Initially, we expressed skepticism about the migration strategy because it stipulated that Verkle tries should be updated when reading state from the existing MPT (Merkle Patricia Trie), but this no longer seems to be the case. Therefore, we support the overlay tree method as a viable migration path.

Documentation regarding the Verkle migration strategy seems to be outdated overall, as most resources still indicate that Verkle tries should be updated when reading state from the MPT, even though this is not the case. We would like to see key transition documents updated with the latest methods (e.g., https://notes.ethereum.org/@parithosh/verkle-transition). We also hope to see an EIP draft regarding transition strategies.

Thus, we still support a launch in 2025 but do not believe it should be deployed in the Prague fork.

L1 Gas Limits

We believe that increasing L1 gas limits due to derived demand will not be very effective in practice. We also believe that most clients can handle average load increases, but we want to remain vigilant about worst-case scenarios, so we cannot yet recommend increasing L1 gas limits. We believe that increasing Blob gas limits is a more promising solution in the short term.

Account Abstraction

We are open to including one or more EIPs (or incorporating ERCs), but we would prefer to see more comparisons of user experience and developer experience between each proposal to better understand the trade-offs and workload of tool integration. We are focused on the following EIPs/ERCs 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: Proxy 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 Fellowship

(https://ethereum-magicians.org/t/rip-7560-native-account-abstraction/16664)

We would like to remind that in the above content, "account abstraction" refers to "abstracting verification functionality, primarily aimed at achieving key rotation, making multi-signature a core feature of the blockchain, and providing us with an automatic quantum resistance path" (h/t VB), applicable only to the above 4337 and 7560, while other proposals fall into two categories: gas sponsorship and batch operations.