Paradigm: What's Next After Ethereum's Cancun Upgrade?
TechFlow Selected TechFlow Selected
Paradigm: What's Next After Ethereum's Cancun Upgrade?
Due to induced demand, increasing the L1 gas limit won't actually have much effect.
Navigating Web3 tides with focused insightsAuthor: Georgios Konstantopoulos
Translation: TechFlow
Introduction
This article aims to outline the views of Paradigm's Reth team on which EIPs (Ethereum Improvement Proposals) should be included in the Prague hard fork—the next EL hard fork following Cancun—as well as their perspective on the 2024 "EL core development" roadmap. The opinions expressed here represent the current stance of the Reth team and do not necessarily reflect the views of the broader Paradigm team.
Summary
We believe the Prague hard fork could be implemented on Ethereum testnets in Q3 2024 and on mainnet by year-end. It should include:
-
Any staking-related EIPs, such as EIP-7002, which enables restaking and trustless staking pools.
-
Independent EVM changes.
-
We are open to collaborating with any team to further investigate challenges related to Prague or future EL hard forks, and are happy to provide guidance or assist with adapting the Reth codebase.
Recommended Actions:
-
We believe the following EIPs should be prioritized: 7002, 6110, and 2537.
-
We support the specification of EOF (EVM Object Format), but urge that its scope be finalized soon and a meta-EIP established to govern it.
-
We are open to increasing the maximum Blob Gas limit in EIP-4844. We have no specific number in mind, but welcome data analysts to collaborate with us on investigating this topic.
-
We are open to deploying a version of EIP-7547: inclusion lists, to help grassroots censorship resistance.
Not Recommended:
-
We do not support introducing Verkle Tries in Prague, but support client teams beginning implementation efforts in Q2 2024, with commitment to ship it during the Osaka hard fork in mid-to-late 2025.
-
We believe L1 execution gas limits or contract size should not be increased, though we invite data analysts to work with us on studying network impact. We remain open to revising our position based on prior test results showing Reth nodes can handle increased load.
-
We believe wallet/account abstraction EIPs require more real-world testing to better understand trade-offs between them. If they are not mutually exclusive, we are open to deploying multiple AA-related EIPs in the future.
-
We may make a decision on EIP-7212 (secp256r1) if the community shows acceptance toward rumors about a potential NSA backdoor.
-
Other roadmap topics: We have no direct opinion on CL EIPs or CL/EL fork coupling, but EIPs 7549 and 7251 appear promising. We are also willing to contribute from the EL side to PeerDAS efforts where possible. We currently prefer to avoid introducing SSZ roots (EIPs 6404, 6465, 6466). Finally, we note an opportunity to develop long-term data archiving solutions for expired blobs, history, and state—neither EIP-4844 nor EIP-4444 specifies this, and it remains unclear whether Ethereum intends to provide such a solution.
Below is a detailed breakdown.
Recommended Actions:
In short, we support:
-
Further narrowing the gap between CL and EL.
-
EVM modifications that can be executed independently and tested in parallel.
EIP-7002
This EIP allows smart contracts on the EL side to control one or more validators on the CL side, enabling trustless restaking and staking pools. From our perspective, this is a low-hanging fruit EIP, as it would at minimum allow existing staking pools to remove a layer of centralization from withdrawal-reliant smart contracts.
Introducing stateful precompiles into the EVM represents a new abstraction we need to capture in EVM implementations, but otherwise, we view this as a straightforward EIP to implement directly.
EIP-6110
This EIP introduces deposits into EL state, simplifying state management required on the CL side. In practice, this is analogous to tracking CL withdrawals, so overall we consider this another relatively easy and independently implementable EIP.
EIP-2537
Multiple implementations of BLS12-381 already exist, and it is a curve frequently used in many SNARKs, BLS signature schemes, and EIP-4844. We believe implementation complexity is low, as it simply exposes verification algorithms of the curve via precompile interfaces. We may also need a hash interface for the BLS12-381 precompile.
EOF
In brief: Support a well-defined version that Solidity and Vyper will adopt. Code formatting and validation adjustments clearly improve analyzability—we support these—but recommend caution beyond that. We suggest adopting the following EIPs, though remain open to further trimming.
Pros:
-
Changes only to the EVM, testable via ethereum/tests, and implementable by a single person.
-
Changes desired by both Vyper and Solidity.
-
Improves performance and increases contract size limits.
-
Eliminates the need for EVM to perform bytecode analysis at runtime—analysis time can reach up to 50% without caching, and grows with contract size.
-
Supports partial code loading, beneficial for executing large smart contracts.
-
Developer experience: Will allow fixing "stack too deep" issues via dupN/swapN and other tool improvements.
-
Future-proofing: Enables safe introduction of new features in L2s, with tools knowing what is compatible.
Cons:
-
Scope creep and moving targets.
-
Lack of strong champions driving inclusion.
-
Legacy code will still need to be supported.
-
Temporary divergence between Ethereum mainnet and other EVM chains before adoption.
We believe the following EOF features should be deployed in 2024. We urge that scope be finalized quickly and commitments made. Other items should be considered for later deployment. Our recommendations include:
-
EIP-3540: EOF - EVM Object Format v1: Introduces code and data containers, adding structure and versioning to Ethereum bytecode.
-
EIP-3670: EOF - Code Validation: Reject deployment of any contract not conforming to EOF format. Enforces more structured code and disables invalid and undefined instructions.
-
EIP-663: Unlimited SWAP and DUP Instructions: Resolves Solidity's "stack too deep" issue. JUMPDEST analysis with immediate value may have side effects. Highly attractive for EVM languages.
-
EIP-4200: EOF - Static Relative Jumps: Better static analysis, no indeterminate jumps. Relative jumps enhance code reusability.
-
EIP-4750: EOF - Functions: Addresses subroutine issues when using static instead of dynamic jumps. Also enables partial code loading, which pairs well with Verkle and increases contract size limits.
-
EIP-5450: EOF - Stack Validation: Validates code and stack requirements. Removes runtime stack underflow and overflow checks for all instructions except CALLF (from EIP-4750).
-
EIP-7480: EOF - Data Section Access Instructions: Allows access to the data section of bytecode.
-
EIP-7069: Improved CALL Instruction: Removes gas observability from CALL, making future gas repricing easier. While independent of EOF, we believe this is a good opportunity to introduce it.
We are less certain about EIP-6206: EOF - JUMPF and Non-Returning Functions. While it enables tail-call optimization in EOF functions, we still need to see language-level analysis demonstrating its utility. If lacking, we believe it can be removed from scope and included in a future EOF update.
We estimate the above work requires 1 full-time engineer for 1–2 months. If needed to maintain momentum, we are willing to further narrow this scope.
Notes on legacy bytecode:
-
While we could ban new legacy/non-EOF bytecode, we cannot deprecate existing legacy bytecode, which would effectively become EOF "v0". Legacy bytecode will still require JUMPDEST analysis post-EOF, and special handling to segment it into Verkle Tries.
-
To our knowledge, there is no verifiable method to convert non-EOF bytecode to EOF without source code, but we are open to exploring mechanisms to facilitate such conversion.
-
We are also open to exploring expiration mechanisms to enforce migration of state to EOF.
Increase EIP-4844 Blob Count
We are open to this modification, which in the context of EIP-4844 means increasing MAX_BLOB_GAS_PER_BLOCK and TARGET_BLOB_GAS_PER_BLOCK:
-
The target values for TARGET_BLOB_GAS_PER_BLOCK and MAX_BLOB_GAS_PER_BLOCK are 3 blobs per block (0.375 MB) and up to 6 blobs (0.75 MB), respectively. These conservative initial limits aim to minimize network strain; increases are expected in future upgrades as network reliability under larger blocks is demonstrated.
-
In practice, this is a minor code change. We need to study its real-world impact on the txpool, but believe we can reuse EIP-4844 stress-testing infrastructure for this. CL clients may find blob propagation harder—we defer to CL teams' judgment.
Not Recommended
Verkle Tries
In short, we do not see a viable path to deploying Verkle tries by end-of-2024 or early-2025. We recommend teams allocate resources in Q2 2024 and commit to deployment during the Osaka hard fork in Q2–Q3 2025.
Pros:
-
Cheaper light clients via smaller storage proofs.
-
Stateless execution enabled by including pre-state reads in block headers, improving performance through static state access.
-
Increased contract size limits via bytecode chunking and partial code loading.
-
State expiry becomes more acceptable due to lower cost of state recovery.
Cons:
-
Magnitude of change and integration effort for implementation and testing.
-
Gas accounting changes: Verkle Tries introduce witness size into gas calculation. We are concerned storage pricing changes remain unexplored (e.g., how much will top gas consumers cost post-Verkle?).
-
Application integration: How should apps with MPT (Merkle Patricia Trie) verifiers behave during overlay transition? What should eth_getProof return?
While we recognize the benefits of Verkle Tries, we believe more consideration is needed regarding how third-party tools/contracts must adapt, and implications for Layer 2 solutions. Initially skeptical of migration strategies requiring Verkle tree updates during MPT state reads, we now believe this concern has been addressed. Thus, we support the overlay tree approach as a viable migration path.
Documentation on Verkle migration strategies is generally outdated—most resources still claim Verkle trees should be updated when reading from MPT, though this is no longer accurate. We hope to see key transition documents updated, such as this excellent write-up. We also hope to see a draft EIP on migration strategy published.
Therefore, while we continue to support its 2025 rollout, we do not believe deployment in Prague is feasible.
L1 Gas Limit
We believe raising the L1 gas limit will have limited effect due to induced demand. We also believe most clients can handle increased average load, but remain cautious about worst-case scenarios, so we cannot currently recommend increasing the L1 gas limit. We view increasing blob gas limits in the near term as a more promising solution.
We invite collaboration on research in this area, particularly around breaking resource metering in the EVM. The paper "Broken Metre" is an excellent starting point.
Account Abstraction
We are open to including one or more of these EIPs (or ERCs), but ideally would like to see more comparative analysis on user and developer experience across proposals, to better understand integration trade-offs and workload. We are tracking the following EIPs/ERCs, but welcome additional suggestions:
It should be noted that in the above, "account abstraction" refers to "abstracting the validation function," with the primary goal of enabling key rotation, making multisig a first-class feature, and providing an automatic quantum-resistant path—applicable only to 4337 and 7560. Other proposals fall into two categories: gas sponsorship and batch operations.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
Paradigm
