TL;DR

The goal of this post is to outline the Paradigm Reth team’s view on which EIPs should be included in Prague, the next EL hard-fork after Cancun, and our general 2024 “EL Core Dev” plans. The views below are evolving and represent only the Reth team's current view, and not necessarily the broader Paradigm team.

• We think the Prague hard fork is possible on Ethereum testnets by Q3 2024 and mainnet by end of year. It should include:
  • Any staking-related EIPs, such as EIP-7002 which enables re-staking & trustless staking pools.
  • Isolated EVM changes.
  • We are open to collaborating with any teams that want to further investigate any hard questions for Prague or other future EL hard forks, happy to mentor or provide guidance for where to modify the Reth codebase.
• Dos:
  • We think the following EIPs must be prioritized: 7002, 6110, 2537.
  • We are supportive of EOF as described in the spec, but would like scope to be finalized ASAP and a meta-EIP to be created committing to that scope.
  • We are open to increasing the EIP-4844 Max Blob Gas. We don’t have a view on the right number, but we invite data people to work with us on investigating the subject.
  • We are open to shipping a version of EIP-7547: Inclusion lists to help with base layer censorship resistance.
• Don’ts:
  • We are not supportive of Verkle Tries in Prague, but are supportive of client teams starting to work towards it in Q2 2024, and commit to shipping it in Osaka sometime mid/late 2025.
  • We do not think we should increase the L1 Execution Gas Limit or contract size, but we invite data people to work with us on investigating the impact on the network. We are open to revising our take here since past testing showed that Reth nodes can handle increased load without problems.
  • We think that Wallet / Account Abstraction EIPs need more battle-testing against each other to understand the tradeoff space better. If they’re not mutually exclusive then we would be open to deploying multiple AA-related EIPs in the future.
  • We could get over the line on EIP-7212 (secp256r1), if the community is OK with the rumored NSA backdoor.
  • Other Roadmap Topics: We do not have a hands-on view on CL EIPs or the coupling of CL/EL forks, but EIP 7549 and 7251 seem promising. We also would like to contribute to the work on PeerDAS, where possible from the EL side. We would like to avoid the introduction of SSZ roots (EIP 6404, 6465, 6466) at the moment. Finally, we observe that there is an opportunity for a long-term data archival solution for expired blobs, history and state, since neither EIP-4844 nor EIP-4444 specify that, and it’s TBD whether Ethereum wants to offer such a solution.

Reasoning below.

Dos

Abstractly, we are supportive of 1) further bridging the gap between CL and EL, 2) EVM modifications which can be executed as 1-person jobs and can be tested in isolation & in parallel.

EIP-7002

This EIP unlocks trustless re-staking and staking pools, by enabling smart contracts on the EL side to control 1 or more validators on the CL side. No-brainer EIP from our perspective as at a minimum it’ll enable existing staking pools to remove a layer of centralization from the smart contracts that implement their withdrawals.

Introducing the stateful precompile to the EVM is a new abstraction we need to capture in the EVM implementations, but beyond that we think this is a straightforward EIP to execute on.

EIP-6110

This introduces deposits in the EL State, simplifying the state management that needs to be done on the CL. Implementation wise, this is similar to tracking CL Withdrawals, so overall we think this is also an easy & isolated EIP to implement.

EIP-2537

There are multiple implementations of BLS12-381 by now in the wild, and it’s a frequently used curve in many SNARKs, BLS signing algorithms, and EIP-4844. We consider implementation complexity low, as it is merely exposing the curve’s verification algorithm over the precompile interface. It is possible we also want a Hash to BLS12-381 Curve precompile.

EOF

TL;DR: Supportive of a well-scoped version that Solidity & Vyper will adopt. Code format & verification adjustments that make analysis easier are a no-brainer, and we recommend anything beyond that to be carefully considered. We recommend a few EIPs below, but we are open to further trimming.

The good:

• EVM-only change which can be tested with ethereum/tests and implemented by 1 person.
• EVM-change that Vyper and Solidity want!
• Helps with performance & increases of contract size limit.
• Removes the need for bytecode analysis at runtime by EVMs, which can be as much as 50% of the time when there’s no caching involved, growing with the contract size.
• Enables partial code load which helps with executing smart contracts of large size.
• Devex: Will allow fixing “Stack Too deep” in solidity with dupN/swapN, and other tooling improvements.
• Future Proofing: Can safely introduce new features across L2s and tooling will know what is compatible.

The bad:

• Scope & moving targets.
• No champion pushing hard for its inclusion.
• Legacy code still needs to be supported
• Temporary divergence between Ethereum mainnet and other EVM chains until adopted.

We think the following EOF features should be deployed in 2024. We recommend finalizing the scope ASAP and committing to it. Anything else should be considered for follow-up deployments. Our recommendations:

• EIP-3540: EOF - EVM Object Format v1: Introduces code and data containers and adds structure and versioning to the ethereum bytecode.
• EIP-3670: EOF - Code Validation: Reject any contracts that do not follow the EOF format at deploy time. Enforce more structured code and disable invalid and undefined instructions.
• EIP-663: Unlimited SWAP and DUP instructions: This addresses “Stack Too Deep” in solidity, with JUMPDEST analysis as immediate value could have side-effects. Very desirable by evm langs.
• EIP-4200: EOF - Static relative jumps: Better static analysis, no uncertain jumps. Better aot compilation. relative jumps are better for code reusability.
• EIP-4750: EOF - Functions: Needed to address subroutines that were possible with dynamic jumps but not with static jumps. It also allows partial code load which works nicely with Verkle & increasing the contract size limit.
• EIP-5450: EOF - Stack Validation: Validates code and stack requirements. Removes runtime stack underflow and overflow check for all instruction except CALLF (EIP-4750)
• EIP-7480: EOF - Data section access instructions: Allow accessing the data section of the bytecode.
• EIP-7069: Revamped CALL instructions: enables removing gas observability from CALLs, which enables easier gas repricing in the future. While independent of EOF, we think it’s a good opportunity to introduce it.

We are less certain about EIP-6206: EOF - JUMPF and non-returning functions. While it allows for tail call optimizations in EOF functions, we still would need to see languages analyze its usefulness. If we don’t have that, we think it is fine to trim it from scope and include in follow-up EOF update.

We budget the above to 1-2 months of work by 1 person, full-time. We are open to further trimming the above mentioned scope if it means keeping momentum.

A note on legacy bytecode:

• While we can disallow new legacy/non-EOF bytecode, there is no way to deprecate existing legacy bytecode, which effectively acts as EOF “v0”. Legacy bytecode will still require JUMPDEST analysis post-EOF, and will still require special code handling for segmenting it into chunks in Verkle Tries.
• To the best of our knowledge there is no verifiable transformation from non-EOF bytecode to EOF without access to the source artifacts, but we are open to investigating mechanisms for facilitating such a transformation.
• Alternatively, we are open to exploring expiry methods which would force the migration of state to EOF.

Increasing EIP-4844 Blob Count

We are open to this change, which would correspond to an increase the MAX_BLOB_GAS_PER_BLOCK and TARGET_BLOB_GAS_PER_BLOCK, for context from EIP-4844:

> The values for TARGET_BLOB_GAS_PER_BLOCK and MAX_BLOB_GAS_PER_BLOCK are chosen to correspond to a target of 3 blobs (0.375 MB) and maximum of 6 blobs (0.75 MB) per block. These small initial limits are intended to minimize the strain on the network created by this EIP and are expected to be increased in future upgrades as the network demonstrates reliability under larger blocks.

In practice this is a small code change, we’d need to investigate the practical impacts of it in the txpool, but we think we can re-use the EIP-4844 stress testing infrastructure for this. It is possible that CLs have a harder time propagating more blobs; we defer to the CL teams’ opinion.

Don’ts

Verkle Tries

TL;DR: We do not see a path towards a late 2024/early 2025 deployment of Verkle tries. We recommend teams to allocate resources on this in Q2 2024 and commit to deploying in Q2-Q3 2025 in the Osaka hard fork.

The good:

• Cheaper light clients via smaller storage proofs.
• Stateless execution via inclusion of read pre-states in a block’s header, which may also result in performance improvements due to static state access.
• Raising the contract size limit by chunking bytecode and enabling partial code loading.
• State expiry becomes more palatable as the cost to “revive” state is lower.

The bad:

• Impact of changes & integration effort to implement & test.
• Gas Accounting Changes: Verkle Tries introduce the size of the witness into the gas calculation function. We worry that changes in storage pricing have not been explored yet (e.g. What’s the cost of the top gas guzzlers going to be post Verkle)?
• Application integrations: What should applications with Merkle Patricia Trie verifiers do while the Overlay transition is running? How should eth_getProof behave?

While we understand the benefits of Verkle Tries, we think more thought needs to be given to how 3rd party tooling/contracts would need to adapt, and what impact the transition would have on e.g. layer 2 solutions. Initially we had doubts about the migration strategy, since it stipulated that the Verkle trie should be updated when state was read from the pre-existing MPT, but this does not seem to be the case anymore. As such, we are supportive of the overlay tree method as a viable migration path.

The documentation for Verkle migration strategies generally seems to be outdated, as most resources still state that the Verkle trie should be updated when state is read from the MPT, even though this is not the case. We would like to see critical transition documentation updated with the latest approaches, such as this excellent doc. We would also like to see a draft EIP on the transition strategy.

As a result we remain supportive of its rollout in 2025, but do not see a path towards deployment in Prague.

L1 Gas Limit

We think that due to induced demand upping the L1 gas limit won’t do much in practice. We also think that most clients can handle the average case load increase, but we want to remain vigilant about the worst cases, so we cannot recommend an increase in the L1 gas limit yet. We see increasing blob gas limit as a more promising solution in the short run.

We invite people to collaborate with us on any research in that direction, and in general around breaking resource metering in the EVM. The Broken Metre paper is a great starting point for this line of research.

Account Abstraction

We are open to including 1 or more of these EIPs (or enshrining the ERCs), but we’d ideally like to see more UX and DevEx comparisons between each proposal to better understand the tradeoff space and effort for tool integration. We are paying attention to the following EIP/ERCs, but feel free to suggest us with more:

• EIP-3074: AUTH and AUTHCALL opcodes
• ERC-4337: Account Abstraction Using Alt Mempool
• EIP-5806: Delegate transaction
• EIP-5920: PAY opcode
• EIP-6913: SETCODE instruction
• EIP-7377: Migration Transaction
• RIP-7560: Native Account Abstraction - Core EIPs - Fellowship of Ethereum Magicians

We'd like to caveat that in the above, "account abstraction" as in "abstracting the validation function, with the primary goals being to enable key rotation, make multisigs first-class, and give us an automatic path to quantum-resistance" (h/t VB) only applies to 4337 and 7560 above, while other proposals are the others are in two buckets, gas sponsorship and batching of operations.