Jan 17, 2024 | Georgios Konstantopoulos
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.
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.
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.
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.
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.
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.
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:
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:
We are open to this change, which would correspond to an increase the
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.
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.
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.
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.
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:
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.
Disclaimer: This post is for general information purposes only. It does not constitute investment advice or a recommendation or solicitation to buy or sell any investment and should not be used in the evaluation of the merits of making any investment decision. It should not be relied upon for accounting, legal or tax advice or investment recommendations. This post reflects the current opinions of the authors and is not made on behalf of Paradigm or its affiliates and does not necessarily reflect the opinions of Paradigm, its affiliates or individuals associated with Paradigm. The opinions reflected herein are subject to change without being updated.