What should be the next upgrade after Ethereum’s Cancun hard fork?

The goal of this article is to outline the Paradigm Reth team's ^[4] views on the Prague hard fork, the next one after Cancun The EL hard fork, and an overview of our 2024 “EL Core Development” plans. The views below are under development and represent the current views of the Reth team and do not necessarily represent the broader Paradigm team.

It should include:

Any EIP related to the pledge, such as EIP-7002, It enables re-staking and trustless staking pools.

Independent EVM changes.

We are open to working with any team wishing to further investigate Bragg or other future EL hard forks, and are happy to guide or provide guidance on modifying the location of the Reth codebase.

Support:

We believe that the following EIP must be given priority: 7002^{[5 ]}, 6110^[6], 2537^[7].

We support EOF as described in the specification ^[8], but would like to scope it out soon and create a meta-EIP that commits Adhere to this range.

We are willing to increase the version of EIP-4844 Maximum Blob Gas^[9]. We have no opinion on the correct number, but we invite data people to work with us to investigate this issue.

We would like to release EIP-7547: a version containing the list ^[10] to help make the base layer censorship resistant.

Not supported:

We do not support Verkle Tries in Prague^{[ 11]}, but we support the client team working towards it starting in Q2 2024, with a mid/late 2025 release in Osaka promised.

We do not believe that L1 execution gas limits or contract sizes should be increased, but we invite data people to work with us to investigate the impact on the network. We're willing to revise our opinion because past testing has shown that Reth nodes can handle the increased load without issue.

We believe the wallet/account abstraction EIP needs more testing against each other to better understand the trade-off space. We are willing to deploy multiple AA-related EIPs in the future if they are not mutually exclusive.

If the community is concerned about the rumored ^[12] NSA ^[13] backdoor ^{[14 ]} OK, we can accept EIP-7212 (secp256r1).

Other roadmap topics: We have no specific views on CL EIP or coupling of CL/EL forks, but EIP 7549^[15] and 7251^[16] seem promising. We also hope to contribute as much as possible to the work of PeerDAS on the EL side. We want to avoid the introduction of SSZ roots (EIP 6404, 6465, 6466) for now. Finally, we note the opportunity to provide a long-term data archiving solution for expired blobs, history and state, as EIP-4844^[17] and EIP-4444^[18] Neither specifies this, nor whether Ethereum is willing to provide such a solution.

The following is the reasoning.

Support

Abstractly speaking, we support 1) further bridging the gap between CL and EL gap, 2) EVM modifications can be performed as a single-person job and can be tested in isolation and in parallel.

EIP-7002^[19]

This EIP passed Enabling the smart contract on the EL side to control one or more validators on the CL side unlocks trustless re-staking and staking pools. From our perspective, this is a no-brainer EIP because at least it will enable existing staking pools to remove a layer of centralization from the smart contracts that implement their withdrawals.

Introducing stateful precompilation in the EVM implementation is a new abstraction that we need to capture in the EVM implementation, but other than that, we think it is a EIP that can be executed directly.

EIP-6110^[20]

This EIP is in Deposits are introduced in the EL state, simplifying the state management required on the CL. Implementation-wise, this is similar to tracking CL withdrawals, so overall we think this is also an easy-to-implement and self-contained EIP.

EIP-2537^[21]

There are now Multiple implementations of BLS12-381, which is a commonly used curve in many SNARKs, BLS signature algorithms, and EIP-4844. We consider the implementation complexity to be low since it only exposes the verification algorithm of the curve through a precompiled interface. Maybe we also want a pre-compile of Hash to BLS12-381 curves.

EOF^[22] Ethereum Object Format

TL ;DR: Support a well-scoped version that Solidity and Vyper will adopt. Code formatting and verification adjustments that make analysis easier are a no-brainer and we recommend further pruning.

Benefits:

Only EVM changes can be made through Ethereum/tests for testing and implementation by one person.

Make the EVM changes Vyper and Solidity want!

Helps with performance and improves contract limit size.

Eliminates the need for analysis of bytecode at runtime via the EVM, which can take up to 50% of the time when there is no cache, depending on the contract size increases with the increase.

Code can be partially loaded, helping to execute large contracts.

Devex: Will allow "Stack Too deep" fix using dupN/swapN in Solidity, among other tooling improvements.

Future-proof: New features can be safely introduced to L2 and the tools will know what is compatible.

Weaknesses:

Changed goals.

No supporters pushed hard for its inclusion.

Old code still needs to be supported

Until adopted, Ethereum mainnet and other EVMs There will be temporary divergences between chains.

We believe the following EOF features should be deployed in 2024. We recommend defining the scope as quickly as possible and committing to it. Anything else should be considered for subsequent deployment. Our recommendation:

EIP-3540: EOF - EVM Object Format v1^[23]: Introduce code and data containers, and provide Ethereum bytecode adds structure and versioning.

EIP-3670: EOF - Code Verification ^[24]: Reject any contract that does not follow the EOF format when deployed. Forces more structured code and disables invalid and undefined directives.

EIP-663: Unlimited SWAP and DUP instructions ^[25]: This solves the "Stack Too Deep" issue in Solidity , parsing via JUMPDEST as an immediate value may have side effects. The EVM language very much hopes to have such a feature.

EIP-4200: EOF - Static relative jumps^[26]: better static analysis, no uncertain jumps . Better aot compilation. Relative jumps are better for code reusability.

EIP-4750: EOF - Function ^[27]: Need to handle subclasses that may have dynamic jumps but not static jumps routine. It also allows partial code loading, which works well with Verkle and increases the contract size limit.

EIP-5450: EOF - Stack Verification^[28]: Verify code and stack requirements. Runtime stack underflow and overflow checks have been removed for all instructions except CALLF (EIP-4750).

EIP-7480: EOF - Data segment access instruction ^[29]: Allows access to the data segment of bytecode.

EIP-7069: Improved CALL instruction ^[30]: Make gas observability disappear in CALLs, making it easier in the future Perform gas repricing. While independent of EOF, we thought this was a good opportunity to introduce it.

We are less certain about EIP-6206: EOF - JUMPF and non-returning functions^[31]. While it allows tail call optimization in EOF functions, we still need to see language analysis for its usefulness. If we don't have this, we think it can be taken out of scope and included in subsequent EOF updates.

We budget the above work to take 1-2 months and be completed by one person full-time. We are willing to further reduce the range mentioned above if it means maintaining momentum.

A note about traditional bytecode:

Although we can prohibit new traditional/ Non-EOF bytecode, but existing legacy bytecode cannot be deprecated, it effectively acts as EOF "v0". Traditional bytecode still requires JUMPDEST analysis after EOF, and special code handling is still required to segment it into Verkle Tries.

To our knowledge, there is no verifiable conversion from non-EOF bytecode to EOF without requiring access to the source artifacts, but we are open to investigating ways to facilitate the mechanism of this conversion.

Alternatively, we are willing to explore expiration methods that force state migration to EOF.

Increase the number of EIP-4844 blobs

We are willing to accept this change, which will MAX_BLOB_GAS_PER_BLOCK and TARGET_BLOB_GAS_PER_BLOCK are increased, for context, see EIP-4844^[32]:

The values ​​for TARGET_BLOB_GAS_PER_BLOCK and MAX_BLOB_GAS_PER_BLOCK were chosen to target 3 blobs (0.375 MB) per block, with a maximum of 6 blobs (0.75 MB). These smaller initial limits are intended to minimize the stress this EIP places on the network, and are expected to be increased in future upgrades so that the network can demonstrate reliability at larger blocks. *

Actually, this is a small code change and we need to investigate its actual impact in txpool, but we think we can reuse Stress testing infrastructure for EIP-4844. The consensus layer may have difficulty propagating more blobs; we're listening to the CL team.

Not supported

Verkle Tries^[33]

TL;DR: We see no way to deploy Verkle tries in late 2024/early 2025. We recommend that the team allocate resources in Q2 2024 and commit to deployment in the Osaka hard fork in Q2-Q3 2025.

Benefits:

Achieved through smaller storage proofs Cheaper light client.

Enables stateless execution by including read pre-state 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.

Due to the lower cost of "resurrecting" a state, state expiration becomes more attractive.

Weaknesses:

High workload: impact of changes , integration work implementation and testing.

Gas billing changes: Verkle Tries introduces the witness size into the gas calculation function. We are concerned about changes in storage pricing that have not yet been explored (e.g., what will the cost be for top gas consumers post-Verkle)?

App Integration: What should an application with a Merkle Patricia Trie validator do when the Overlay transition is running? How should eth_getProof behave?

While we understand the benefits of Verkle Tries, we believe more thought is needed to understand how third-party tools/contracts need to adapt, and transitional examples such as Impact of 2-tier solutions. Initially, we were skeptical about the migration policy because it stipulated that the Verkle trie should be updated when state is read from the existing MPT, but this does not appear to be the case now. Therefore, we support the overlay tree approach as a viable migration path.

The documentation for Verkle's migration strategy seems generally out of date, as most resources still state that the Verkle trie should be updated when state is read from MPT, even though this is not the case. We'd like to see key transition documents updated to the latest methods, such as this excellent document ^[34] . We would also like to see a draft EIP on the transition strategy.

Therefore, we still support the launch of Verkle in 2025, but do not see a deployment path for the Prague upgrade.

L1 Gas Limit

We believe that from the perspective of inducing demand, increasing the L1 gas limit is It won't do much in practice. We also believe that most clients can handle the increase in load average, but we want to remain wary of worst-case scenarios, so we are not recommending increasing the L1 gas limit for the time being. We believe increasing the blob gas limit is a more promising solution in the short term.

We invite everyone to collaborate with us on any research in this direction and around breaking out of resource metering in EVM. The Broken Meter paper^[35] is a good starting point for this research direction.

Account abstraction

We are willing to include 1 or more of these EIPs (or protocol implementations ERCs), but we would ideally like to see more user experience and development experience comparisons to better understand the tradeoff space and tool integration effort of individual proposals. We are following the following EIPs/ERCs, but please feel free to suggest more to us:

EIP-3074: AUTH and AUTHCALL opcodes^[36]

ERC-4337: Account Abstraction Using Alt Mempool^[37]

EIP-5806: Delegate transaction^[38]

EIP-5920: PAY opcode^[39]

EIP-6913: SETCODE instruction^[40]

EIP-7377: Migration Transaction^[41]

RIP-7560: Native Account Abstraction - Core EIPs - Fellowship of Ethereum Magicians^[42]

We would like to clarify that in the above content, "account abstraction" refers to "abstract verification function , the main goal is to enable key rotation, make multi-signature a first-class feature, and give us an automated path to quantum resistance" (h/t VB), only applies to 4337 and 7560, while other proposals are divided into two categories , i.e. gas sponsorship and operation batch processing.

Author:

Georgios Konstantopoulos^[43]

Georgios Konstantopoulos is Paradigm's Chief Technology Officer and Research Partner, focusing on Paradigm's portfolio companies and open source protocols. Previously, Georgios worked as an independent consultant and researcher.