Search Extension

API/RSS

Social

Paradigm CTO: Interpreting the Prague hard fork after the Ethereum Constantinople upgrade.

24-01-19 11:00

Read this article in 12 Minutes

Help to Trend

Clicking this button can increase the display frequency and priority of this content on the platform, allowing more users to see it.

AI summary

View the summary

Original Title: "What comes after Ethereum's Cancun hard fork?"

Original Author: Georgios Konstantopoulos, Paradigm CTO

Translated by: Luffy, Foresight News

The purpose of this article is to provide an overview of the Paradigm Reth team's views on which EIPs should be included in the Prague hard fork (the next important upgrade of Ethereum after the Constantinople hard fork), as well as our overall plan for "EL Core Dev" in 2024 (note: EL refers to the execution layer, and CL refers to the consensus layer). The following views are still evolving and only represent the current views of the Reth team, not necessarily the entire Paradigm team.

We believe that the Prague hard fork may be implemented on the Ethereum testnet in the third quarter of 2024 and completed on the mainnet by the end of the year. It should include:

· EIPs related to staking, such as EIP-7002 which supports re-staking and trustless staking pools.

· Individual EVM changes.

· We are willing to collaborate with any team interested in further researching Prague or other future EL hard forks, and are happy to provide guidance and assistance in modifying the Reth codebase.

要做什么： (Translation:

What to do:)

· We believe that the following EIPs must be given priority: 7002, 6110, 2537.

· We support the EOF described in the standard and hope to finalize the scope and create the meta EIP as soon as possible.

· We are willing to increase EIP-4844 Max Blob Gas. We have no opinion on the specific number, but we invite data personnel to work with us to study this topic.

· We are willing to release a version of EIP-7547: it includes a list that helps the underlying layer resist censorship.

Do not do the following:

· We do not support the inclusion of Verkle Tries in the Prague hard fork, but we support the client team's efforts to do so starting in Q2 2024, and promise to release it in the Osaka upgrade in 2025.

· We believe that there should not be an increase in L1 execution gas limit or contract size, but we invite data personnel to work with us to investigate its impact on the network.

· We are willing to change our views, as past tests have shown that Reth nodes can handle increased loads without any issues.

· We believe that wallet/account abstraction EIP needs to undergo more adversarial testing with each other to better understand the trade-offs.

· If they are not mutually exclusive, we will be willing to deploy multiple EIPs related to AA in the future.

· If the community agrees with the rumored NSA backdoor, we can bypass the line on EIP-7212 (secp256r1).

· Other roadmap themes: We have no practical understanding of the coupling of CL EIP or CL/EL forks, but EIP 7549 and 7251 look promising. We also hope to contribute as much as possible from the EL aspect to the work of PeerDAS. Currently, we hope to avoid introducing SSZ roots (EIP 6404, 6465, 6466). Finally, we have found an opportunity to provide long-term data archiving solutions for expired blobs, histories, and states, as EIP-4844 and EIP-4444 both explicitly state, whether Ethereum is willing to provide such solutions remains to be determined.

Expanded in detail below.

要做的事

translates to

Things to do

in English.In abstract terms, we support 1) further narrowing the gap between CL and EL, and 2) EVM modifications that can be executed as individual tasks and tested separately and in parallel.

EIP-7002

This EIP enables smart contracts on the EL side to control one or more validators on the CL side to unlock trustless re-staking and staking pools. In our view, it will at least eliminate one layer of centralization from smart contracts that enable withdrawals in existing staking pools.

Introducing stateful precompiles into EVM is a new abstraction that we need to achieve in EVM implementation. However, we believe that this is an EIP that can be executed directly.

EIP-6110

This EIP introduces deposits in the EL state, simplifying state management that would otherwise need to be done on the CL. In implementation, this is similar to tracking CL withdrawals, so overall we believe this is a simple and standalone EIP.

EIP-2537

Currently, there are multiple implementations of BLS12-381, which is a curve frequently used in many SNARK, BLS signature algorithms, and EIP-4844. We believe that its implementation complexity is low because it only exposes the curve's verification algorithm through a precompiled interface. We may also need the hash value of the BLS12-381 curve precompiled.

EOF

Translator's note: EOF, short for EVM Object Format, is a series of EIPs that promise to make Ethereum execution more efficient, consistent, and upgradeable. The early plan was to implement it during the Shanghai upgrade, but it was later removed.

EOF will support both Solidity and Vyper. Without a doubt, the code formatting and verification adjustments will make bytecode analysis easier, and we recommend careful consideration of other matters. We have recommended some EIPs below, but we are willing to make further adjustments.

Verkle Tries

· Application Integration: What should an application with a Merkle Patricia Trie verifier do when Overlay transition is running? How should eth_getProof behave?

Although we understand the benefits of Verkle Tries, we believe that more consideration needs to be given to how third-party tools/contracts will adapt and what impact it will have on Layer 2 during the transition period. Initially, we had concerns about the migration strategy as it stipulated that the Verkle trie should be updated when reading state from a pre-existing MPT, but this no longer seems to be the case. Therefore, we support the Overlay method as a viable migration path.

The document for Verkle migration strategy seems to be outdated as most resources still indicate updating the Verkle trie when reading state from MPT. We would like to see transition documents that adopt the latest methods, such as this excellent document. We also hope to see EIP drafts on transition strategies.

Therefore, we still support its launch in 2025 instead of deploying it in the Prague hard fork.

L1 Gas Restrictions

We believe that increasing the L1 Gas limit will not have a significant impact in practice. We also believe that most customers can handle an increase in average load, but we want to remain cautious about worst-case scenarios, so we currently do not recommend increasing the L1 Gas limit. We believe that increasing the blob Gas limit is a more promising short-term solution.

We invite others to collaborate with us on research in this area, usually focused on breaking resource metering in EVM. The paper Broken Meter is a great starting point for this type of research.

Account Abstraction

We are willing to include one or more EIPs, but we would like to see more user and developer experience comparisons between each proposal to better understand the trade-offs and workload of tool integration. We are currently keeping an eye on the following EIPs/ERCs, but please feel free to suggest others at any time:

· EIP-3074: AUTH and AUTHCALL opcodes

· ERC-4337: Account abstraction using Alt Mempool

· EIP-5806: Delegated Transactions

· EIP-5920: PAY Opcode

· EIP-6913: SETCODE Instruction

· EIP-7377: Migration Transaction

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

Above all, what we need to pay attention to is that "account abstraction" is like "abstract verification function, the main goal is to achieve key rotation, make multi-signature become critical, and provide us with an automatic path to achieve quantum resistance".