Paradigm's latest research: Where is Ethereum headed after the Cancun upgrade?

*Original: “What comes after Ethereum’s Cancun hard fork?”

By Georgios Konstantopoulos

Compiler: Odaily Moni

I. Overview

This article will analyze the Paradigm Reth team’s understanding of the important EIPs (Ethereum Network Improvement Protocol) contained in the Prague Hard Fork (the next execution layer Hard Fork after Cancun Cancun upgrade) and their views on the “EL Core Dev” plan in 2024.

The Prague Hard Fork is likely to take place on EthereumTestnet in the third quarter of 2024 and on Mainnet by the end of the year. Upgrades include:

1. It is recommended to include EIPs related to staking, such as EIP-7002, activate re-staking and staking pools that do not require external trust;

2. Independent EVM changes;

In addition, Paradigm is willing to work with all teams who want to further investigate the challenges of EL hard forks such as Prague and is happy to provide guidance on modifying the Reth codebase.

Direction that Paradigm agrees with:

1. Paradigm believes that the following EIPs should be prioritized: 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 that scope.

3. Paradigm is willing to add EIP-4844 Max Blob Gas, and will not comment too much on the correct number in it, but will invite data personnel to cooperate in investigating the EIP.

4. Paradigm is open to releasing the EIP-7547: Inclusion Lists version, which can help resist base layer censorship.

Directions that Paradigm disagrees with:

1. Paradigm does not support the Verkle Tries data structure used by the Prague Hard Fork, but supports the client team to start working on this in the second quarter of 2024, while promising to upgrade and release in Osaka in mid/late 2025.

2. Paradigm believes that the L1 execution gas limit or contract size should not be increased, but will invite data personnel to cooperate in investigating the impact of this practice on the Ethereum network. At the same time, Paradigm is willing to adjust its view, as past tests have shown that Reth Node can handle the increased load without any problems.

3. Paradigm believes that Wallet/Account Abstraction EIPs need more adversarial testing to better understand the trade-offs in cyberspace. If Wallet/Account Abstraction is not mutually exclusive, there will be a willingness to deploy multiple EIPs related to Account Abstraction in the future.

4. If the community agrees with the rumored NSA backdoor, Paradigm believes the line of EIP-7212 (secp 256 r 1) can be crossed.

5. Other roadmap topics: Paradigm has no practical 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 work of PeerDAS from the EL side as much as possible, and currently wants to avoid the introduction of SSZ roots (EIPs 6404, 6465, 6466). Finally, Paradigm believes that a long-term data archiving solution should be provided for expired blobs, history, and state, as neither EIP-4844 nor EIP-4444 indicates this, but it remains to be determined whether Ethereum is willing to provide such a solution.

Here are the details:

Direction that Paradigm agrees with

In the abstract, Paradigm mainly supports the following two aspects:

1. Further narrow the gap between the Consensus and Implementation layers;

2. EVM modifications can be performed as one-person jobs and can be 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, there is some truth to this EIP, which will at least enable existing staking pools to remove a layer of centralization from the Smart Contract that implements withdrawals.

In addition, the introduction of stateful precompilation into the EVM is also a feature that Paradigm agrees needs to be satisfied in the EVM implementation, but beyond that, Paradigm believes that this is an EIP that can be executed directly.

EIP-6110

The EIP introduces the deposit function in the state of the execution layer, simplifying the state management that needs to be done at the Consensus layer. In terms of implementation, this is similar to tracking Consensus layer withdrawals, so overall, Paradigm believes that this is also an easy-to-implement and stand-alone EIP.

EIP-2537

Currently, BLS 12-381 has multiple implementations and is a curve that is often used in many SNARKs, BLS Signature Algorithms, and EIP-4844. Paradigm believes that the BLS 12-381 implementation is less complex because it only exposes the verification algorithm of the curve through the precompiled interface, so the precompiled hash of the BLS 12-381 curve may also be required.

Ethereum Object Format (EOF)

In simple terms, EOF will support both Solidity and Vyper with a wider range of versions, and it makes sense to make code formatting and verification tweaks easier to analyze, and Paradigm recommends carefully considering anything beyond that and recommends some EIPs below, while also being willing to make further tweaks.

Good Aspects:

● EVM-only changes that can be tested using Ethereum/Testnet and implemented by a single person.

● EVM changes that Vyper and Solidity want.

● Helps to improve performance and increase contract size constraints.

● Eliminates the need for bytecode analysis at runtime for the EVM, which can take up to 50% of the analysis time without caching involved, and increases as the contract size increases.

● Enabling partial code loading, Zhejiang helps to execute large Smart Contracts.

● Devex: Will allow the “stack too deep” issue to be fixed with dupN/swapN and other tooling improvements.

● Applicable features in the future: New features for security across L2 can be introduced, and the tool will know which features are compatible.

Bad Aspects:

● Range and moving targets.

● There is no support for a significant push for its inclusion.

● Legacy code still needs to be supported.

● Prior to adoption, there was a temporary divergence between EthereumMainnet and other EVM chains.

Paradigm believes that the following EOF features should be deployed in 2024 and recommends scoping and committing to implementation as soon as possible. There are other issues that should be considered for subsequent deployments. Therefore, Paradigm recommends:

● EIP-3540 (EOF - EVM Object Format v1): Introduces code and data containers and adds structure and versioning to Ethereum bytecode.

● EIP-3670 (EOF - Code Validation): Rejects any contract that does not follow the EOF format when deploying, only more structured code can be executed, and disables invalid and undefined instructions.

● EIP-663 (Infinite SWAP and DUP Instructions): This EIP solves the “stack too deep” problem in Solidity, using JUMPDEST analysis as an instant value can have side effects, but this is a feature that EVM becomes a language that very much wants.

● EIP-4200 (EOF - Static Relative Jumps): Better static analysis with no uncertain jumps. Better AOT compilation, which is more conducive to code reusability than jumps.

● EIP-4750 (EOF – Functions): Requires a resolution of subroutines that can use dynamic jumps but not static jumps, and also allows some code to load, works well with Verkle data structures and increases the contract size limit.

● EIP-5450 (EOF - Stack Validation): Verify code and stack requirements. Removed runtime stack underflow and overflow checks for all instructions except CALLF (EIP-4750).

● EIP-7480 (EOF - Data Part Access Instruction): Allows access to the data portion of bytecode.

● EIP-7069 (Improved CALL Instruction) removes gas observability from CALL, making it easier to reprice gas in the future. While the EIP is independent of EOF, Paradigm sees this Hard Fork as a good opportunity to introduce the EIP.

Paradigm isn’t too sure about EIP-6206 (EOF-JUMPF and Non-Return Function), and while this EIP allows tail call optimization in EOF functions, Paradigm still needs to see the usefulness of linguistic analysis. If not, Paradigm believes it can be removed from scope and included in subsequent EOF updates.

Paradigm estimates the above workload to be approximately 1-2 person-months of full-time employment, and is willing to further narrow down the above if the workload assessed is larger.

Note on legacy bytecode:

● While it is possible to prohibit new legacy/non-EOF bytecode, it is not possible to deprecate existing legacy bytecode because it effectively acts as an EOF “v 0”. Legacy bytecode still requires JUMPDEST analysis after EOF and still requires special code handling to fragment it into blocks in Verkle Trys.

● To Paradigm’s knowledge, it is impossible 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 to force state migration to EOF.

Increase the number of EIP-4844 blobs

Paradigm is open to this change and will add “MAX_BLOB_GAS_PER_BLOCK and TARGET_BLOB_GAS_PER_BLOCK”

Select the values of TARGET_BLOB_GAS_PER_BLOCK and MAX_BLOB_GAS_PER_BLOCK corresponding to targets of 3 blobs (0.375 MB) each Block (up to 6 blobs, approximately 0.75 MB). These initial limits are not large, but they minimize the strain on the network caused by the EIP and can be increased in subsequent upgrades as the network demonstrates reliability in larger blocks.

Actually, the code changes won’t be too big, but Paradigm needs to investigate the actual impact of these higher on the txpool, so the EIP-4844 stress testing infrastructure can be reused. The Consensus layer may have a hard time propagating more blobs, so Paradigm also respects the opinions of the Consensus layer team.

Directions that Paradigm does not agree with

Verkle Tries

In simple terms, a Verkle deployment by the end of 2024/early 2025 seems unlikely, and Paradigm recommends that the team allocate resources for this in Q2 2024 and commit to deploying in the Osaka Hard Fork in Q2-Q3 2025.

Good Aspects:

● Lower-cost light clients with smaller storage proofs.

● Stateless execution by including read prestate in the block header, which may also lead to performance improvements due to static state access.

● Increase the contract size limit by chunking the bytecode and enabling partial code loading.

● Status expiration becomes more acceptable due to the lower cost of “restoring” the state.

Bad Aspects:

● The impact of changes and integration efforts for implementation and testing.

● Gas Accounting Changes: Verkle Tries introduced witness size into the gas calculation feature, and Paradigm was concerned that changes in storage pricing had not yet been explored (e.g., how much does it cost to head gas consumers 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 that more consideration needs to be given to how third-party tools/contracts need to fit in, and how the transition will affect Layer 2 solutions, etc. Initially Paradigm was skeptical about the migration strategy because it stated that Verkle Tries should be updated when state was read from pre-existing MPT, but that no longer seems to be the case. Therefore, Paradigm supports the overlay method as a feasible migration path.

The documentation of the Verkle migration strategy often seems outdated, 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 documentation updated with the latest methodology, which can be referenced. Paradigm would also like to see a draft eco-investment plan on a transition strategy.

Therefore, Paradigm still supports its launch in 2025, not in this Hard Fork.

L1 Gas Limit

Paradigm believes that there may be some “misdirection” on the demand side, and in reality, raising the L1 gas limit does not have much of an impact in practice. Paradigm also believes that most clients can handle an increase in average load, but Paradigm wants to be vigilant about the worst-case scenario and therefore does not recommend increasing the L1 gas limit at this time. Paradigm believes that increasing the blob gas limit in the short term is a more promising solution.

Paradigm wants to invite the community to collaborate on research in related directions, often around breaking the resource metering in the EVM. This paper published by Broken Meter should be a good starting point for this field of research.

Account Abstraction

Paradigm is willing to include 1 or more EIPs (or include ERCs) in a hard fork, but ideally would prefer to see more UX and developer experience comparisons between each proposal to better understand the trade-offs 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 Operation Code

ERC-4337: Account abstraction with Alt Mempool

● EIP-5806: Escrow Transaction

● EIP-5920 :P AY Operation Code

● EIP-6913: SETCODE command

● EIP-7377: Migration transactions

● RIP-7560: Native Account Abstraction - Core EIP - Fellowship of Ethereum Magicians

As a final reminder, “Account Abstraction” only applies to EIP-4337 and EIP-7560 above, while the other proposals focus on two areas: Gas Sponsorship and Bulk Operations. (“Account abstraction” is like abstracting a validation function, with the primary goal of enabling secret key rotation, making Multisig a key element and giving us a path to automatically achieve quantum resistance.) ）