jakiro
The goal of this article is to outline the Paradigm Reth team[4]For Prague’s hard fork, Prague is the next EL hard fork after Cankun, and the overview of our 2024 “EL core development” plan.The following views are under development, and only the current view of the RETH team does not necessarily represent a broader Paradigm team.
We believe that Prague’s hard fork may be achieved on the Ethereum Testing Network in the third quarter of 2024, and it will be achieved on the main network at the end of the year.
It should include:
Any EIP related to pledge, such as EIP-7002, makes it possible for Re-Staking and Non-Trusting Pond.
Independent EVM changes.
We are willing to cooperate with any team that we want to further study Prague or other future EL hard splits, and be willing to guide or provide guidance to modify the location of the RETH code library.
support:
We believe that the following EIP must be given priority: 7002[5], 6110[6], 2537[7]Essence
We support EOF, such as specifications[8]In this, I hope to determine the scope as soon as possible and create a meta -EIP to promise to comply with the scope.
We are willing[9]Version.We have no opinion on the correct figures, but we invite data personnel to cooperate with us to investigate this issue.
We are willing to publish EIP-7547: include lists[10]The version to help the basic layer anti -review.
Not supported:
We don’t support using Verkle Tries in Prague[11]However, we support the client team to achieve it since the second quarter of 2024, and promise to be released in Osaka in the mid -2025 mid -2025.
We don’t think that the L1 execution GAS limit or contract size should be increased, but we invite data personnel to cooperate with us to investigate the impact on the network.We are willing to modify our views, because the past tests show that the RETH node can handle the increased load without problems.
We believe that wallet/account abstraction EIP requires more mutual confrontation tests to better understand the balance space.If they are not mutually exclusive, then we are willing to deploy multiple AA -related EIPs in the future.
If the community is in the rumor[12]NSA[13]back door[14]OK, we can accept EIP-7212 (SECP256R1).
Other route map themes: We have no specific views on the coupling of CL EIP or CL/EL splits, but EIP 7549[15]And 7251[16]It seems very promising.We also hope to contribute to Peerdas’s work as much as possible in EL.We hope to temporarily avoid the introduction of SSZ roots (EIP 6404, 6465, 6466).Finally, we noticed the opportunity to provide long-term data archive solutions for expired BLOB, history and status, because EIP-4844[17]And EIP-4444[18]Nothing is specified, and whether Ethereum is willing to provide such a solution.
The following is reasoning.
support
Abstract, we support 1) the gap between CL and EL further, 2) EVM modification can be performed as a single person work, and can be in isolation and parallel testing.
EIP-7002[19]
This EIP unlocked the re -pledged and pledge pool by controlling the CL side by controlling the CL side of the CL side.From our perspective, this is an EIP that does not need to think about, because at least it will enable the existing pledged pool to remove one layer of centralization from the smart contract that implements its withdrawal.
Introducing state pre -compilation in EVM implementation is a new abstraction that we need to capture in EVM implementation, but in addition, we think this is an EIP that can be directly executed.
EIP-6110[20]
This EIP introduces deposits in the EL state, simplifying the state management needed on the CL.In terms of implementation, this is similar to tracking CL withdrawal, so in general, we think that this is also an EIP that is easy to achieve and independent.
EIP-2537[twenty one]
Now there are multiple BLS12-381 implementation outside. It is a curve often used in many SNARKS, BLS signature algorithms and EIP-4844.We believe that the complexity is low, because it only discloses the verification algorithm of the curve through the pre -compilation interface.Maybe we also want a pre-compilation of a Hash to the BLS12-381 curve.
EOF[twenty two]Ethereum object format
TL; DR: Support a clear version of a solidity and vyper.It is a thing that makes it easier to analyze the code format and verification adjustment. We recommend further trimming.
benefit:
Only EVM changes can be tested by Ethereum/TESTS and implemented by one person.
Make the EVM changes you want Vyper and solidity!
It helps performance and improve the contract size.
EVM eliminates the needs of bytecode analysis during runtime. When there is no cache, this may account for 50%of time, and increases as the contract size increases.
It can be partially loaded to help execute large contracts.
DEVEX: It will be allowed to use Dupn/SWAPN to repair “Stack Too Deep” and other tools in Solidity.
Future verification: It can safely introduce new features to L2, and the tools will know what compatibility is.
insufficient:
Change the goal.
No supporters have tried to promote its addition.
Still need to support the old code
Until the adoption, there will be temporary differences between the Ethereum main network and other EVM chains.
We believe that the following EOF features should be deployed in 2024.We recommend determining the scope as soon as possible and promise to observe.Any other thing should consider subsequent deployment.Our suggestions:
EIP -3540: EOF -EVM object format V1[twenty three]: Introduce code and data containers, and add structures and versions to Ethereum bytes.
EIP -3670: EOF -Code Verification[twenty four]: Refuse any contracts that do not follow the EOF format during deployment.Mandatory and more structured code and disable invalid and unfarished instructions.
EIP-663: Unlimited SWAP and DUP instructions[25]: This solves the “Stack Too Deep” problem in Solidity, and it may have side effects through JumpDest analysis as a momentary value.The EVM language hopes to have such a function very much.
EIP -4200: EOF -Static relative jump[26]: Better static analysis, there is no uncertain jump.Better AOT compilation.Relaxed to the code for the code is better.
EIP -4750: EOF -Function[27]: You need to deal with sub -routines that may have dynamic jump but do not have static jump.It also allows some code to load, which is well used with Verkle and adds contract size restrictions.
EIP -5450: EOF -Stack Verification[28]: Verify code and stack requirements.All instructions except Callf (EIP-4750) have deleted the stack overflow and upfill inspection during runtime.
EIP -7480: EOF -Data segment access instruction[29]: Allow the data segment of the byte code.
EIP-7069: The improved call instruction[30]: Make the GAS in the calls disappear, so that the GAS will be re -priced in the future.Although independent of EOF, we think this is a good opportunity to introduce it.
We tip-6206: EOF-JUMPF and NON-RETURNING FUNCTIONS[31]It is indeed low.Although it allows tail calling optimization in the EOF function, we still need to see language analysis of its usefulness.If we do not have this, we think we can remove it from the range and include subsequent EOF updates.
We will have the above work budget for 1-2 months, which is completed by 1 person.If this means maintaining motivation, we are willing to further reduce the scope mentioned above.
Explanation of traditional bytecies:
Although we can prohibit new traditional/non -EOF bytecodes, it cannot abandon the existing traditional bytecode. It actually acts as EOF “V0”.The traditional bytecode still needs to perform JumpDest analysis after EOF, and it still needs a special code processing to segmented it into Verkle Tries.
As far as we know, there is no verification conversion from non -EOF bytecode to EOF without access to source workpieces, but we are willing to investigate the mechanism of promoting this conversion.
Alternatively, we are willing to explore the expiration method of migrating the state to EOF.
Increase the number of EIP-4844 blob
We are willing to accept this change, which will be rightMax_blob_gas_per_blockandTarget_blob_gas_per_blockIncrease, please refer to EIP-4844[32]The
Target_blob_gas_per_block and Max_blob_GAS_PER_BLOCK are selected as 3 Blob (0.375 MB) for each block, with a maximum of 6 BLOB (0.75 MB).These smaller initial restrictions are designed to maximize the pressure caused by the EIP to the network, and it is expected to increase the future upgrade so that the network can show reliability under larger blocks.*
In fact, this is a small code change. We need to investigate its actual impact in TXPOOL, but we believe that we can reuse the pressure test infrastructure of EIP-4844.The consensus layer may encounter difficulties when spreading more BLOB; we listen to the opinion of the CL team.
Not support
Verkle Tries[33]
TL; DR: We think there is no way to deploy Verkle Tries by the end of 2024/early 2025.We recommend that the team assign resources in the second quarter of 2024 and promise to deploy in the second quarter of 2025 to the third quarter of Osaka.
benefit:
A cheaper light client is achieved through smaller storage proof.
Realizing the stateless execution by the pre -state state in the block of the block, which may also be due to static state access.
Increase the contract size limit by loading the bytecode and enable part of the code.
Due to the low cost of the “resurrection” state, the state becomes more attractive.
insufficient:
Large workload: the impact, integration implementation, and testing of changes.
GAS billing change: Verkle Tries introduced the witness to the GAS calculation function.We are worried that the changes in storage pricing have not been explored (for example, what is the cost of the top GAS consumers after Verkle)?
Application integration: When the Overlay transition is running, what should the application with Merkle Patricia Trie verification device do?eth_getProofWhat should be like?
Although we understand the benefits of Verkle Tries, we think we need more thinking to understand how third -party tools/contracts need to be adapt to, and the impact of transition on such as the second layer solution.Initially, we were skeptical of migration strategy because it stipulated that Verkle Trie should be updated when reading status from the existing MPT, but it seems that this is not the case now.Therefore, we support the Overlay tree method as a feasible migration path.
The document of the Verkle migration strategy seems to be generally outdated, because most resources still point out that Verkle Trie should be updated when reading the state from MPT, although the situation is not the case.We hope to see the key transition document update to the latest method, such as this excellent document[34]EssenceWe also hope to see a draft of the transition strategy EIP.
Therefore, we still support the launch of Verkle in 2025, but we did not see the deployment path at the Prague upgrade.
L1 Gas Limit
We believe that raising L1 GAS restrictions from the perspective of demand will not have much effect in practice.We also think that most clients can handle the increase in the average load, but we hope to be vigilant about the worst situation, so we do not recommend increasing L1 GAS limit for the time being.We believe that adding Blob Gas limit in the short term is a more promising solution.
We invite everyone to cooperate with us to conduct any research on this direction and the way to measure the resource metering around EVM.Broken Metre Paper[35]It is a good starting point in this research direction.
Account abstraction
We are willing to include 1 or more EIP (or protocol implementation ERCS), but we hope to see more user experience and development experience comparison more to better understand the weighing space and tool integration work of each proposal.quantity.We are paying attention to the following EIP/ERCS, but please suggest to us at any time:
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 want to explain that in the above content, “account abstraction” refers to the “abstract verification function, the main goal is to enable the key rotation, make multiple signatures a first -class function, and provide us with an automatic quantum resistance path” (h “/T VB), only suitable for 4337 and 7560, while other proposals are divided into two categories, namely GAS sponsorship and operation batch processing.
author:
>
Georgios Konstantopoulos[43]
Georgios Konstantopoulos is the chief technology officer and research partner of Paradigm, focusing on the research of Paradigm’s investment portfolio and open source protocol.Earlier, Georgios was an independent consultant and researcher.
