Author: Fat Bird Finance

Previous Life

Why is the Cancun upgrade needed?

The vision of Ethereum is to become more scalable and secure under the premise of decentralization. The current upgrade of Ethereum also aims to address this trilemma, but has been facing significant challenges.

Issues with Ethereum:

Currently, there are problems with low TPS and performance, high gas fees, and severe congestion. At the same time, the disk space required to run an Ethereum client is rapidly increasing. At the underlying level, the impact of the consensus algorithm's workload on the entire environment to ensure the security and decentralization of Ethereum is becoming increasingly significant.

Therefore, under the premise of decentralization, efforts are being made to transmit more data and reduce gas fees to enhance scalability, as well as to optimize the consensus algorithm to ensure security.

In order to solve the trilemma of security, decentralization, and scalability, Ethereum has previously used the PoW to PoS mechanism to further lower the entry barrier for nodes, and is also preparing to optimize security by using the beacon chain to randomly allocate validators. In terms of scalability, Ethereum is considering using sharding to reduce the workload of nodes, which can also allow Ethereum to create multiple blocks simultaneously, enhancing its scalability.

Currently, each Ethereum block has a space of approximately 200-300KB, with each transaction being a minimum of about 100 bytes. With around 2000 transactions per block and a block time of 12 seconds, Ethereum's TPS limit is restricted to around 100. This data clearly cannot meet the needs of Ethereum.

Therefore, Ethereum Layer2 focuses on how to put a large amount of data into the blockspace, ensuring security through fraud proofs and validity proofs. This is also why the DA layer has determined the security upper limit, and it is the core content of the Cancun upgrade.

The iterative roadmap of the Ethereum ecosystem cannot build performance comparable to Solana (in terms of latency and throughput) in the short term, nor can it see the sharding performance of Near in the short term, nor the parallel execution performance of Sui and Aptos. In the short term, Ethereum can only build a multi-layer structure with Rollup as the core. Therefore, solving the TPS, gas fee, and developer experience issues is crucial for the Ethereum roadmap.

How is the Ethereum roadmap planned?

Recent important upgrades and their goals

December 1, 2020: The beacon chain was officially launched, laying the groundwork for the POS upgrade.

August 5, 2021: The London upgrade, EIP1559 changed Ethereum's economic model.

September 15, 2022: The Paris upgrade (The Merge), completed the transition from POW to POS.

April 12, 2023: The Shanghai upgrade, resolved the staking withdrawal issue.

The upgrades related to the economic model and POS have been completed. The next few upgrades will address Ethereum's performance, TPS, and developer experience issues.

The next focus is The Surge in the Ethereum roadmap.

Goal: Achieve 100,000+ TPS in Rollup.

There are mainly 2 approaches, on-chain and off-chain:

Off-chain approach: Refers to Layer2, including rollup, etc.

On-chain approach: Refers to making changes directly in L1, which is the popular sharding approach. Sharding can be understood as dividing all nodes into different shards to complete the tasks of each shard, which will effectively improve speed.

Analysis of sharding approach:

The dilemma of sharding: Previous sharding included state sharding, transaction sharding, etc., but the synchronization between different shards is a challenge. Currently, achieving large-scale network node data synchronization is technically difficult. It not only cannot solve the MEV situation, but may also require a large number of patches to compensate for various potential problems, which cannot be achieved in the short term.

Danksharding is a new sharding design proposed for Ethereum, with the core idea of centralized block production + decentralized validation + resistance to censorship. This is also related to the upcoming data availability sampling (DAS), block producer-sealer separation (PBS), and anti-censorship list (Crlist) mentioned below. The greatest significance of the core idea of Danksharding is to turn Ethereum L1 into a unified settlement and data availability layer.

The sharding approach is divided into 2 steps, currently divided into Proto-danksharding and Fully-Rollup.

Proto-danksharding:

Introduction: By introducing blob to help L2 reduce fees and increase throughput, while serving as a pre-sharding solution for the full implementation of sharding. It is expected that after proto-danksharding, it will take 2-5 years for the implementation of danksharding.

Content: The main feature of proto-danksharding is the introduction of a new blob transaction type. Blob has the characteristics of large capacity and low cost, allowing Ethereum to store all rollup data in blob, greatly relieving the storage pressure on the main chain, and also reducing the cost of rollup.

Fully-Rollup

Introduction: Comprehensive expansion of rollup, focusing on the utilization of data availability.

Content:

P2P design of DAS: Involves some work and research on data sharding network connections.

Data availability sampling client: Developing lightweight clients that can quickly determine the availability of data through random sampling of several thousand bytes.

Effective self-recovery of DA: Able to effectively rebuild all data under the worst network conditions (such as malicious validator attacks, or long-term downtime of large nodes).

Ethereum Core Developer Meetings

Every upgrade of Ethereum depends on core developer meetings, where core contributors discuss technical issues and coordinate the future work of Ethereum based on a series of proposals from developers. They are responsible for making decisions on the future direction of the Ethereum protocol, as well as making decisions on whether EIPs should be included in upgrades and whether roadmap changes are needed.

Definition: The core developer meeting is a weekly telephone meeting held by the Ethereum development community, where core contributors from different organizations discuss technical issues and coordinate the future work of Ethereum. They determine the future technical direction of the Ethereum protocol and are the real decision-making body for Ethereum upgrades, responsible for decisions, whether EIPs are included in upgrades, and the need for roadmap changes.

Core process: The upgrade process centered around EIPs is roughly as follows. First, a new EIP is preliminarily accepted at the core developer meeting (referred to as ACD). Then, regardless of whether the EIP is included in the upgrade, the client team tests it, and after the final testing, it is reviewed again, and the final decision on whether to include it in the actual upgrade is made based on the discussion.

There are 2 types of meetings, consensus layer meetings and execution layer meetings, which are held alternately every other week:

Consensus Layer Meeting (AllCore Developers Consensus - ACDC), focusing on the Ethereum consensus layer (proof of stake, beacon chain, etc.);

Execution Layer Meeting (AllCore Developers Execution - ACDE), the latter focusing on the Ethereum execution layer (EVM, gas schedule, etc.).

There are 3 main types of Ethereum core maintainers, mainly official organizations or volunteer forums for discussing proposals:

AllCoreDevs: Code maintainers responsible for ETH1 network clients, upgrades, and maintaining Ethereum code and core architecture;

"Project Management" section: Supporting Ethereum developers, coordinating hard forks, monitoring EIPs, and directly assisting AllCoreDevs in communication and operations;

EthereumMagicians: A forum for discussing EIPs and other technical topics.

Timeline of Cancun Upgrade-related Meetings

Based on the discussion content, the Cancun upgrade can be roughly divided into 5 stages.

First Stage - Introducing the Upgrade Theme

Introducing new tasks proto-danksharding, EOF, and the "selfdestruct" opcode, and briefly discussing the content of the Shanghai upgrade.

After Ethereum completed the merge on September 15, 2022, the developer meetings were suspended for 4 weeks, allowing developers a month to review the EIPs discussed for subsequent upgrades.

On October 28, 2022, the first developer meeting after the merge, proto-danksharding, the implementation of EOF, and the "selfdestruct" opcode were first proposed. At this time, the specific scope of proto-danksharding was not determined. Some developers initially believed that the Shanghai upgrade could be divided into several small upgrades, such as enabling the withdrawal of staked ETH first, and then upgrading EIP4844. However, another group of developers believed that implementing a larger upgrade in one step would be more meaningful.

Second Stage - Determining the Time Range and Preparing for the KZG Ceremony

At the end of 2022, Ethereum meetings mainly focused on discussing EOF and EIP4844, while also advancing the preliminary trusted setup ceremony required for EIP4844 - the KZG ceremony. Developers would officially determine when EIP4844 would be introduced in an upgrade in January 2023.

In November 2022, during Ethereum's AllCore Developers call #149, EOF or proto-danksharding was mentioned. At this time, developers were still considering placing them in the Shanghai upgrade.

During the consensus layer meeting on December 2, 2022, Trent Van Epps, responsible for the Ethereum ecosystem, updated the progress of the trusted setup ceremony required for the implementation of EIP4844. The ceremony aims to generate secure code to be used in EIP4844. Van Epps hoped that the ceremony would be one of the largest in the history of the crypto field, collecting 8000 to 10000 contributions. The public contribution period for the ceremony would last for about 2 months and would begin at some point in December.

During the core developer meeting on the same day, there was a certain discussion about EOF and the deactivation of the selfdestruct opcode. A developer from the Ethereum Foundation opposed delaying EOF to Cancun, believing that if the code changes were not included in Shanghai, the likelihood of it being included in Cancun was very small. Regarding the selfdestruct opcode, at that time, some developers advocated for the advancement of EIP4758. However, directly deactivating this opcode would disrupt certain applications. Developers believed that the EIP should be reconsidered for some time before creating an edge case to protect this type of contract.

During the core developer meeting on December 9, 2022, the implementation of the KZG ceremony for the Cancun upgrade was discussed. The required trusted setup ceremony for EIP4844 was ready at that time.

During the consensus layer meeting on December 16, 2022, developers discussed merging two different pull requests (PR) into the specification of proto-danksharding. One was related to how nodes handle data that exceeds a specific point after data pruning, and the other was to introduce new error codes to alert nodes when there is missing information about blob on a block.

During the core developer meeting on January 5, 2023, developers reached a consensus to remove the code modifications related to EOF implementation from the Shanghai upgrade and include them in the Cancun upgrade two weeks later.

Third Stage - Preliminary Discussion of the Scope of Proposals

At the end of January 2023, after EOF was moved from the Shanghai upgrade to the Cancun upgrade, the next two months mainly focused on discussing proposals other than EOF and EIP4844, while EOF was proposed to be removed from Cancun again. During this time, the scope of proposals for the Cancun upgrade was mainly defined.

During the core developer meeting on January 20, 2023, EOF was moved into the Cancun upgrade.

Current Life

Key EIP Analysis

EIP4844

Introduction:

The EIP4844 proposal, named Proto-Danksharding, is a pre-sharding solution for the full-scale sharding expansion Danksharding. The entire sharding solution is actually centered around Rollup for on-chain scalability. The purpose of the proposal is to expand the Layer 2 Rollup by helping L2 reduce fees and increase throughput, while paving the way for full sharding.

In a February phone meeting, Ethereum developers named the EIP4844 upgrade Deneb, after a first-magnitude star in the constellation Cygnus. This means that the naming of EIP4844 on related GitHub versions will be updated to Deneb. In the meeting on June 1, 2023, there were some changes to the next Ethereum upgrade specification, referred to as Deneb on the CL side and Cancun on the EL side.

In the developer meeting on June 23, 2023, developers prepared to update the precompile addresses for EIP4844. Currently, the core developers have added 9 precompiles to the EVM and will create two precompiles under the addresses "0xA" and "0xB" by activating EIP4844 and 4788, respectively. In the consensus meeting on June 29, 2023, a dedicated short-term test network, Devnet#7, for EIP4844 was ready to be launched.

EIP-4844 introduces a new transaction type called BlobTransaction.

Blob Introduction:

Blob is similar to an external data packet, initially with a storage space of only 128KB. At the beginning of the proposal discussion, the target and limit for Blob were 2/4. In the developer meeting on June 9, 2023, it was adjusted to 3/6. This means that currently, each transaction in Ethereum can carry a maximum of three Blob transactions, totaling 384KB. The target Blob capacity for each block is 6, totaling 768KB, and the maximum capacity is 16 Blobs, totaling 2MB.

This may have a certain impact on network stability, but the Ethereum development team has decided to proceed with testing to avoid the need for a hard fork to expand the Blob block in the future.

Blob uses KZG commit Hash for data verification, similar to the role of Merkle.

After nodes synchronize the BlobTransaction on the chain, the Blob part will expire and be deleted after a period of time, with a storage time of three weeks.

Role of Blob - Increase Ethereum's TPS while reducing costs

The total data size of Ethereum is currently only about 1TB, while Blob can bring an additional data volume of 2.5 to 5TB to Ethereum each year, directly exceeding the ledger itself by several times.

This concludes the translation of the provided content. If you have any more text that needs to be translated or any other requests, feel free to submit them!

For nodes, downloading 1MB to 2MB of Blob data per block does not impose a significant bandwidth burden, and it only adds a fixed amount of about 200 to 400GB of Blob data per month in terms of storage space. This does not affect the decentralization of the entire Ethereum node, but the scalability achieved through Rollup is significant.

Moreover, nodes do not need to store all Blob data because Blob is temporary. Therefore, nodes only need to download a fixed amount of data for three weeks.

The role of EIP-4844 - Opening the prelude to Danksharding

High Scalability: Currently, EIP-4844 can initially scale L2. The full version of Danksharding can expand the Blob data volume from 1MB to 2MB in EIP-4844 to 16MB to 32MB, ensuring decentralization and security while achieving higher scalability.

Low Fees: Analyst Bernstein stated that Proto-dank-sharding can reduce the fees of the Layer 2 network to 10-100 times the current level.

Actual Data:

Opside test network deployment of 4844 observed a 50% cost reduction in rollup.

EigenLayer's DA technical solution has not disclosed much, making it difficult to evaluate its data.

Celestia, strictly speaking, has little relevance to Ethereum, and its DA cost cannot be evaluated at present, depending on its specific technical solution.

Ethstorage's solution involves uploading Layer 2 storage proofs, which may reduce DA costs to 5% of the original.

Topia expects a cost reduction of 100 to 1000 times because the main network Danksharding needs to consider security and compatibility with Layer 1 P2P network broadcasting.

DA Solution: Danksharding (Ethereum's sharding solution for scalability) may face issues of excessive node burden (above 16MB) and insufficient data availability (30-day validity) if it continues to scale. Solutions include:

Data Availability Sampling - Reducing node burden

Cutting Blob data into fragments and transitioning nodes from downloading Blob data to randomly sampling Blob data fragments, dispersing Blob data fragments across every Ethereum node. Complete Blob data is stored in the entire Ethereum ledger, assuming there are enough decentralized nodes.

DAS uses two technologies: Erasure Coding and KZG Commitment.

Proposal-Builder Separation (PBS) - Addressing the division of labor issue for nodes, with high-performance nodes responsible for downloading and distributing all data for encoding, and low-performance nodes responsible for random sampling and verification.

High-performance nodes can become builders, responsible for downloading Blob data for encoding and creating blocks, then broadcasting for random sampling by other nodes. Due to the high data synchronization and bandwidth requirements, builders may be relatively centralized.

Low-performance nodes can become proposers, responsible for verifying data validity and creating and broadcasting block headers. Due to lower data synchronization and bandwidth requirements, proposers may be decentralized.

Censorship-Resistant List (crList) - Addressing the issue of excessive censorship power for builders, allowing them to ignore certain transactions and insert their own to gain MEV.

Before builders create block transactions, proposers publish a crList containing all transactions in the mempool.

Builders can only select and sort transactions from the crList, preventing them from inserting private transactions to gain MEV or intentionally rejecting transactions (unless the Gas limit is reached).

After creating the block, builders broadcast the final version of the transaction list hash to proposers, who select one to generate a block header and broadcast it.

Nodes synchronize data by obtaining block headers from proposers and block bodies from builders, ensuring the block body is the final selected version.

Dual-Slot PBS - Addressing the increasing centralization of builders through MEV acquisition.

Using a bidding model to determine block production:

Builders create block headers and bid after receiving the crList.

Proposers select the winning block header and builder, with proposers unconditionally receiving the winning fee (regardless of whether a valid block is generated).

Committees confirm the winning block header.

Builders disclose the winning block body.

Committees confirm the winning block body and conduct verification voting (if the builder intentionally does not provide the block body, it is considered as a non-existent block).

Significance:

Builders have greater power to pack transactions, but the crList limits their ability to temporarily insert transactions. Additionally, if builders attempt to profit by changing the transaction order, they need to pay a significant bidding cost upfront to ensure they can qualify for the block header, reducing their MEV profits. Overall, this affects the means and actual value of MEV acquisition.

Initially, only a few people may become builders (considering node performance issues), while most people become proposers, potentially leading to further centralization. Additionally, in a situation where there are few builders, experienced miners with MEV capabilities are more likely to win bids, further affecting the actual effectiveness of MEV solutions.

This concludes the translation of the provided content. If you have any more text that needs to be translated or any other requests, feel free to submit them!

Reason: The original operation of the SELFDESTRUCT opcode required a significant change to the account state, such as deleting all code and storage. This posed difficulties for future use of the Verkle tree: each account would be stored in many different account keys, which would not be explicitly linked to the root account.

Change: This EIP implements a change to remove SELFDESTRUCT, except in the following two cases:

Applications that only use SELFDESTRUCT to retrieve funds can still use it;

SELFDESTRUCT used in the same transaction within a contract does not require a change.

Significance: Enhanced security

Previously, there were cases on the mainnet where contracts used SELFDESTRUCT to restrict who could initiate transactions through the contract;

Prevents users from continuing to deposit funds and transact after SELFDESTRUCTing a treasury, potentially allowing anyone to steal tokens from the treasury through repeated exploitation.

The following three proposals are subsequent proposals related to SELFDESTRUCT that were officially selected in the core developer meeting on April 28, 2023. EIP-6780 was chosen, while the other three proposals were deprecated. The Ethereum development team ultimately wants to completely remove the SELFDESTRUCT opcode, while the following three proposals are more corrective in nature.

EIP-4758 (deprecated): Disables SELFDESTRUCT by changing it to SENDALL, which can return all funds to the caller (sends all ether in the account to the caller) without deleting any code or storage.

Reason: Similar to the above, the original operation of the SELFDESTRUCT opcode required a significant change to the account state, such as deleting all code and storage. This posed difficulties for future use of the Verkle tree: each account would be stored in many different account keys, which would not be explicitly linked to the root account.

Change:

The SELFDESTRUCT opcode is renamed to SENDALL, which now only moves all ETH in the account to the caller, without destroying code and storage or changing the nonce;

All refund-related SELFDESTRUCTs have been removed.

Significance:

Compared to EIP-6780, it preserves the original functionality because some applications still use/need the SELFDESTRUCT opcode.

EIP-6046 (deprecated): Replaces SELFDESTRUCT with DEACTIVATE. Changes SELFDESTRUCT to not delete storage keys and uses a special value in the account nonce to indicate deactivation.

Reason: Similar to the above, using the Verkle tree, accounts will be organized in different ways: account properties (including storage) will have separate keys, but it will not be possible to traverse and find all used keys. The original operation of the SELFDESTRUCT opcode required a significant change to the account state, making it very difficult to continue using SELFDESTRUCT in the Verkle tree.

Change:

Changes the rules introduced by EIP-2681 to constrain regular nonces to 2^64-2 instead of 2^64-1;

SELFDESTRUCT is changed to:

Not delete any storage keys and leave the account in place;

Move the account balance to the target and set the account balance to 0.

Set the account nonce to 2^64-1.

No refunds since EIP-3529;

The rules of SELFDESTRUCT from EIP-2929 remain unchanged.

Significance:

This proposal offers more flexibility compared to directly removing SELFDESTRUCT.

EIP-6190 (deprecated): Changes SELFDESTRUCT to be compatible with Verkle, causing a limited number of state changes.

Reason: Similar to the above, using the Verkle tree, accounts will be organized in different ways: account properties (including storage) will have separate keys, but it will not be possible to traverse and find all used keys. The original operation of the SELFDESTRUCT opcode required a significant change to the account state, making it very difficult to continue using SELFDESTRUCT in the Verkle tree.

Change: Instead of destroying the contract at the end of the transaction, the following occurs at the end of the transaction that calls it:

The contract code is set to 0x1, and the nonce is set to 2^64-1.

The 0th storage slot of the contract is set to the address published when the contract was created using the CREATE opcode (keccak256(contractAddress, nonce)). The nonce always remains at 2^64-1.

If the contract self-destructs after being forwarded by one or more alias contracts, the 0th storage slot of the alias contract is set to the address calculated in step 2;

The contract's balance is moved to the address at the top of the stack;

The top of the stack is popped.

Significance:

Intended to allow SELFDESTRUCT to be compatible with the Verkle tree while making minimal changes;

Applies the gas cost increase from EIP-2929.

Next is EIP1153, paving the way for future storage design while saving gas.

EIP1153X

Introduction: Transient storage opcodes, adding opcodes for operations that behave like storage but are discarded after each transaction.

Reason:

Executing transactions on Ethereum can generate multiple nested execution frames, each created by a CALL (or similar) instruction. Contracts can be re-entered within the same transaction, in which case more than one frame belongs to a contract.

Currently, these frames can communicate in two ways: through input/output passed by the CALL instruction, and through storage updates. If there is an intermediate frame belonging to another untrusted contract, communication through input/output is insecure.

For example, reentrancylock cannot rely on intermediate frames to pass the lock state: SSTORE communication through storage SLOAD is expensive, and transient storage is a dedicated and gas-efficient solution to the inter-frame communication problem.

Change: Two new opcodes, TLOAD (0xb3) and TSTORE (0xb4), are added to the EVM.

Transient storage is private to the contract that owns it, just like persistent storage, and only the contract frame can access its transient storage. When accessing storage, all frames access the same transient storage in the same way as persistent storage, but different from memory.

Potential use cases:

reentrancylock;

On-chain computable CREATE2 addresses: Construct function parameters are read from the factory contract instead of being passed as part of the initialization code hash;

Single transaction EIP-20 approvals, such as #temporaryApprove(address spender, uint256 amount);

Transfer fee contracts: Paying fees to a token contract to unlock transfers during a transaction;

"Till" pattern: Allows users to perform all operations as part of a callback and check the "till" balance at the end;

Proxy call metadata: Passing additional metadata to the implementing contract without using call data, such as the value of immutable proxy constructor parameters.

Significance:

Saves gas, with simpler gas charging rules;

Addresses the inter-frame communication problem;

Does not change the semantics of existing operations;

No need to clear storage slots after use;

Future storage designs (such as Verkle trees) do not need to consider refunding for transient storage.

Next is EIP4788, which can reduce the trust assumptions on the staking pool.

EIP4788: X

Introduction: Beacon block root in the EVM.

Update: In the developer meeting on June 15, 2023, developers proposed code changes to improve the staker experience. This EIP will expose the root of the public beacon chain block, which contains internal chain state information for minimal-trust access by DApp developers.

Change: Submit the hash root of each beacon chain block in the corresponding execution payload header, store these roots in a contract in an executing state, and add a new opcode to read from this contract.

Significance: This is a code modification proposal that suggests modifying the Ethereum Virtual Machine (EVM) to allow it to expose contract layer (CL) state roots to data in the execution layer (EL), making communication between different protocols and applications in the Ethereum network more efficient and secure. It allows staking pools, bridging, and restaking protocols to have more trustless designs.

Finally, there is EIP5656, which provides an efficient new memory copy opcode, but considering its testing bandwidth, it is currently in a temporary inclusion status in the upgrade.

EIP5656X

Introduction: MCOPY - Memory copy instruction.

Update: On June 9, 2023, the development team expressed initial disagreements about MCOPY because, although it solves security issues, there were concerns about adding it to the upgrade requiring implementation + testing bandwidth. However, it was ultimately agreed to include this EIP, but it will be considered for removal if developers encounter capacity issues during testing or client implementation. Therefore, MCOPY is in a temporary inclusion status in the Cancun upgrade.

Change: Provides an efficient EVM instruction to copy memory regions.

Significance: Memory copy is a basic operation, but implementing it on the EVM incurs costs.

With the availability of the MCOPY instruction, it will be possible to copy code phrases more precisely, improving memory copy performance by about 10.5%, which is very useful for various computationally intensive operations;

It will be useful for compilers to generate more efficient and smaller bytecode;

It can save a certain amount of gas fees for identity precompiles, but it does not actually advance the implementation of this part.

EIP Candidates

On June 15, 2023, the developer consensus meeting discussed which CL-centric EIPs to include in Deneb, where EIP6988, EIP7044, and EIP7045 were proposed for inclusion.

EIP6988: X

Introduction: Prevents penalized validators from being selected as block proposers.

Significance: Increases penalties for violating nodes, benefiting DVT.

EIP7044: X

Introduction: Ensures the permanent validity of signed validators' exits.

Significance: Can improve the staker experience to some extent.

EIP7045: X

Introduction: Extends the attestation slot inclusion range from a rolling window of one epoch to two epochs.

Significance: Strengthens network security.

Analysis of Deleted EIPs

At the 160th Ethereum ACDE meeting on April 29, 2023, EVMMAX and EOF were confirmed to be removed from the upcoming upgrade, and changes related to EOF may be introduced in subsequent routine upgrades.

EVMMAXEIPs:

Introduction: EVMMAX aims to bring greater flexibility to arithmetic operations and signature schemes on Ethereum. Currently, there are two EVMMAX proposals, one with EOF and the other without EOF.

EIP6601: EVM Modular Arithmetic Extension (EVMMAX)

Change: It is an iteration of EIP5843, with the difference from EIP5843 being:

6601 introduces a new EOF section type, storing the modulus, precomputed Montgomery parameters, and the number of values to be used (still supports runtime-configurable moduli);

6601 uses a separate memory space for EVMMAX values, moving values between EVM->EVMMAX memory using new load/store opcodes.

This concludes the translation of the provided content. If you have any more text that needs to be translated or any other requests, feel free to submit them!

6601 supports operations on moduli of up to 4096 bits (a provisional limit mentioned in the EIP).

Significance: EIP-5843 introduced efficient modular addition, subtraction, and multiplication for the Ethereum Virtual Machine (EVM). EIP-6601 further upgrades this by introducing a settings section, separate memory space, and new opcodes to provide better organization and flexibility for modular arithmetic operations, while also supporting larger moduli and improving EVM performance.

Enabling elliptic curve arithmetic operations on various curves (including BLS12-381) as EVM contracts;

Reducing gas costs for MULMOD operations on values of up to 256 bits compared to existing opcodes like ADDMOD;

Allowing modexp to be precompiled as an EVM contract;

Significantly reducing the cost of algebraic hash functions (e.g., MiMC/Poseidon) and ZKP verification in the EVM.

EIP6690:

Change: EIP-6990 is a proposal adapted from EIP-6601, aiming to introduce optimized modular arithmetic operations to the EVM without relying on EOF. While EIP-6601 requires EIP-4750 and EIP-3670 as dependencies, EIP-6990 provides a more independent solution by eliminating the dependency on EOF, offering a simplified approach.

Significance: It retains the core functionality of EIP-6601, allowing optimized modular arithmetic operations on moduli of up to 4096 bits. This simplification allows for more efficient implementation and adoption while still providing the benefits associated with EIP-6601.

EOFchanges:

Introduction: EOF is an upgrade to the EVM, introducing new contract standards and some new opcodes. Traditional EVM bytecode is an unstructured sequence of instructions. EOF introduces the concept of containers, implementing structured bytecode. A container consists of a header and several sections to achieve structured bytecode. After the upgrade, the EVM will be able to undergo version control and run multiple sets of contract rules simultaneously.

EIP663:

Introduction: Unrestricted SWAP and DUP instructions.

Significance: Introduces two new instructions, SWAPN and DUPN, which increase the stack depth from 16 elements to 256 elements compared to SWAP and DUP.

EIP3540:

Introduction: EIP-3540 introduces a container that can be extended and version-controlled for the EVM, declaring the format of EOF contracts. This enables validation of code during the deployment of EOF contracts, known as creation-time validation, preventing deployment of contracts that do not conform to the EOF format. This change implements EOF version control, which will be beneficial for future deprecation of existing EVM instructions or introduction of large-scale features, such as account abstraction.

Significance: Version control facilitates the introduction or deprecation of new features (e.g., account abstraction). Separation of contract code and data is beneficial for L2 validation, reducing gas costs for L2 validators, and also facilitates the work of on-chain data analysis tools.

EIP3670:

Introduction: Based on EIP-3540, the purpose is to ensure that the code in EOF contracts is valid and prevent deployment of contracts that do not conform to the format, without affecting Legacy bytecode.

Significance: Building on the container introduced by EIP-3540, EIP-3670 ensures that the code in EOF contracts is valid or prevents its deployment. This means that undefined opcodes cannot be deployed in EOF contracts, with the additional benefit of reducing the number of required EOF versions.

EIP4200:

Introduction: Introduces the first EOF-specific opcode: RJUMP, RJUMPI, and RJUMPV, which encode destinations as signed immediate values. Compilers can use these new JUMP opcodes to optimize the deployment and execution gas costs of JUMP, as they eliminate the runtime required for jumpdest analysis with existing JUMP and JUMPI opcodes. This EIP is a supplement to dynamic jump.

The difference from traditional JUMP operations is that RJUMP and similar operations do not specify a specific offset position, but rather a relative offset position (from dynamic jumps to static jumps), as static jumps are often sufficient.

Significance: Optimizes the network and reduces costs.

EIP4750:

Takes the functionality of 4200 further by introducing two new opcodes, CALLF and RETF, as alternatives for cases where RJUMP, RJUMPI, and RJUMPV cannot be used, thus eliminating the need for JUMPDEST in EOF contracts and prohibiting dynamic jumps.

Significance: Optimizes code by dividing it into several parts.

EIP5450:

Background: Currently, Ethereum contracts are not checked during deployment; checks are only performed during execution, such as for stack underflows/overflows and gas availability.

Content: Adds another validity check for EOF contracts, this time related to the stack. This EIP prevents the deployment of EOF contracts that could lead to stack underflows or overflows, reducing the number of validity checks performed by clients during the execution of EOF contracts.

Significance: A major improvement is to minimize checks that occur during execution, with more checks taking place during contract deployment.

After the developer meeting update on May 26, the change in transaction type from SSZ to RLP related to EIP4844 means that the two SSZEIPs for Cancun are no longer needed, so EIPs6475 and 6493 have been removed from the Cancun upgrade.

EIP6475X

Introduction: A complementary proposal to EIP4844. Proto-danksharding introduces a new transaction type using SSZ encoding instead of the RLP encoding used by other transaction types.

Update: In the 161st Ethereum Execution Layer Core Developer Meeting, discussions about the SSZ serialization format of EIP4844 showed that developers initially leaned towards introducing an early iteration of the SSZ format to the EL through blob transactions. Ultimately, developers plan to upgrade all transaction types from RLP to SSZ. However, given the unclear path and the certainty that it cannot be implemented in the Cancun upgrade, developers have been weighing the removal of SSZ from EIP-4844. After several discussions, developers agreed to remove SSZ from the EL implementation of EIP-4844, but there has been no action to remove EIP6475 at this time. After the update on May 26, the change from SSZ to RLP means that the two SSZEIPs for Cancun are no longer needed, resulting in the removal of EIPs6475 and 6493 from the Cancun upgrade.

EIP6493X

Introduction: SSZ transaction signature scheme. This EIP defines a signature scheme for transactions encoded in Simple Serialize (SSZ), addressing how nodes should handle blob transaction types formatted in SSZ on the CL but encoded differently on the EL. This EIP is part of updating Ethereum serialization formats to achieve cross-layer consistency.

Background: SSZ changes

Introduction: Simple Serialize (SSZ) is the serialization method used on the beacon chain.

SSZ changes also include three other complementary proposals, with only 6465 being introduced this time.

EIP6465: SSZ withdrawal root, defines the migration process from existing Merkle-Patricia Trie (MPT) commitments to withdrawals in Simple Serialize (SSZ);

EIP6404/ EIP6466:

Both define a process to migrate existing Merkle-Patricia Trie (MPT) commitments to Simple Serialize (SSZ).

EIP-6404— SSZ transaction root

EIP-6466— SSZ receipt root

Tim Beiko suggested in the core developer meeting on May 26 that future discussions around expanding the Cancun scope should be limited to the following five EIPs: EIP5920, 5656, 7069, 4788, and 2537, with subsequent proposals emerging within this scope. Subsequently, EIP5656 and EIP4788 were confirmed as formal upgrade proposals, while 5920, 7069, and 2537 were removed. EIP5920 was removed due to developer concerns about potential side effects of transferring ETH and incomplete reasoning, testing, and security work, leading to its removal from the upgrade.

EIP5920: X

Introduction: Payment opcode. Introduces a new opcode, PAY, for transferring ether on Ethereum without invoking any functions.

Reason: Currently, sending ether to an address requires the user to call a function at that address, which presents several issues:

First, it opens up a vector for reentrancy attacks, as the receiver can callback to the sender;

Second, it opens up a DoS vector, as the calling function must recognize that the receiver may exhaust gas or callback;

Finally, the CALL opcode is unnecessarily expensive for simple ether transfers, as it requires expanding memory and stack, loading all data of the receiver, including code and memory, and finally executing a call, which may perform other unintended operations.

Change:

Introduces a new opcode: (PAY) PAY_OPCODE, where:

Two values, addrthenval, are popped from the stack.

Transfers wei from the executing address to address addr with a value of val. If addr is the zero address, val wei is burned from the executing address.

Potential risk: Existing contracts will no longer rely on their actual balance in their wallets, as it is now possible to send ether to an address without invoking it.

Significance: Saves gas.

Update: On June 9, due to concerns about potential side effects of transferring ETH and incomplete reasoning, testing, and security work, PAY was removed from the upgrade.

EIP7069X

Introduction: Modified CALL instructions.

Change: Introduces three new call instructions, CALL2, DELEGATECALL2, and STATICCALL2, with simplified semantics. The aim is to remove gas observability from the new instructions and open the door for a new class of contracts unaffected by repricing.

Background:

63/64th rule: Limits call depth and ensures that the caller has remaining gas for state changes after the callee returns.

Before the introduction of the 63/64th rule, it was necessary to calculate the available gas for the caller more accurately. Solidity has a complex rule that attempts to estimate the cost of the caller's execution of the call itself in order to set a reasonable gas value.

Current introduction of the 63/64th rule:

Removal of call depth check;

Ensuring a minimum of 5000 gas is left before executing the call;

Ensuring a minimum of 2300 gas is available for the called behavior.

Allowance rule: Known as the 2300 allowance, when one contract calls another contract, the called contract receives 2300 gas to perform very limited operations (enough to do some computation and generate a log, but not enough to fill a storage slot). Since it sets a fixed amount of gas, people cannot determine what type of computation these gas can support as long as gas prices can be adjusted.

Significance: Paving the way for the future introduction of EOF, while also facilitating the operation of large contracts.

Removal of gas optionality: The new instructions do not allow specifying a gas limit, but rely on the "63/64th rule" (mainly referring to Gas repricing for heavy IO operations in EIP-150, increasing the gas consumption of specific operations) to limit gas. This important improvement simplifies the rules around the "allowance," and callers do not need to perform gas calculations regardless of whether they send the value or not.

After the introduction of the new proposal, users can always overcome Out of Gas errors by sending more gas in transactions (of course, subject to block gas limits).

Previously, some contracts that only sent a limited amount of gas to their calls were broken by the new cost accounting mechanism when increasing storage costs (such as EIP-1884 increasing gas for certain opcodes). Some contracts had a gas limit that permanently restricted the amount of gas they could spend, even if they sent it to their sub-calls, as the call would limit the amount sent.

Paving the way for the introduction of EOF: Once the EVM object format (EOF) is introduced, old call instructions can be rejected in EOF contracts, ensuring that they are essentially unaffected by gas price changes. Since these operations are necessary to eliminate gas observability, EOF will require them to replace existing instructions.

More convenient status return codes: Introduces the convenience of returning more detailed status codes: success (0), revert (1), failure (2), and can be expanded in the future.

EIP2537: X

Introduction: Precompile for BLS12-381 curve operations.

Change: Adds operations on the BLS12-381 curve as a precompile to the set necessary for efficient execution of BLS signature verification and SNARKs verification.

Significance: Ethereum can create more secure cryptographic proofs and allow better interoperability with the beacon chain.

PR3175 was mentioned but was not included in the candidate list, and there has been no further discussion.

PR3175: X

Introduction: This proposal will prevent penalized validators from proposing blocks when exiting the queue. If more than 50% of validators are penalized for malicious behavior, they can still propose blocks even when being forcibly expelled from the network. Changing this logic is a relatively minor CL layer change that can provide protection against "high-fault mode" for security reasons, according to the May 4th 108th Ethereum Core Developer Consensus Meeting. PR3175 is being formatted as EIP-6987, to prevent slashed validators from being selected as block proposers for security reasons.

Future

Based on the above information, the following conclusions can be drawn:

1. The main goals of the Cancun upgrade, in order of priority, are scalability, security, gas savings, and interoperability:

Scalability is undoubtedly the top priority (4844);

Security and gas savings are the second priority (6780, 1153, 5656, and 7045), while also considering developer experience;

The third priority is interoperability, such as optimizing connections, communication, and interoperability between dApps (4788, 7044, and 6988);

Expected data: Testnet 4844 can reduce the cost of opsiderollup by 50%; the technical solutions for EigenLayer and Celestia have not been disclosed, so their data cannot be evaluated; Ethstorage is expected to reduce DA costs to 5% of the original; Topia is expected to reduce costs by 100-1000 times.

2. The Cancun upgrade to Danksharding will be the golden period for DA layer projects in the next 2-5 years

The security ceiling of Layer2 depends on the DA layer it adopts. Proto-Danksharding will benefit storage protocols, modular protocols, and L1 storage expansion networks through cheaper state data storage.

First, Danksharding returns to the essence of the Ethereum state machine. Vitalik Buterin mentioned that the purpose of the Ethereum consensus protocol is not to guarantee the storage of all historical data forever. Instead, the purpose is to provide a highly secure real-time bulletin board and leave room for other decentralized protocols to do longer-term storage.

Second, Danksharding reduces DA costs, but the actual landing time and data availability issues also need to be addressed.

DA cost reduction: Before this update, transferring data from rollup to the Ethereum main chain required a call data, and the gas fee for calling this code was very expensive, being the largest expense in layer2. EIP4844 greatly reduces storage costs by introducing data blobs as additional data space unique to rollups, thereby reducing DA costs.

Long landing time and limited TPS improvement and gas reduction will benefit DA layer projects in subsequent continuous development:

In Polynya's article on danksharding's Variablesecurity data sharding, it indicates that it will take 2-5 years to land;

Even after landing, the level of TPS improvement and gas reduction is limited:

EIP4844 currently supports 6 blobs, and future scalability issues will rely on Danksharding to solve them;

The current Ethereum block space is approximately 200KB. After Danksharding, the planned size in the specification is 32 megabytes, about 100 times the increase. Currently, Ethereum's TPS is around 15, and ideally, after a 100-fold increase, it would be around 1500, which is not a significant improvement in terms of magnitude.

Therefore, the long landing time and limited actual changes will benefit DA layer projects. Some new DA projects such as Celestia, Eigenda, can still compete with Danksharding in the future through lower costs and faster TPS, and new DA projects like Ethstorage and Topia can fill the market gap before landing.

Technical issues, such as data storage and data availability, also need to be addressed:

The main costs of DA are network bandwidth costs and storage costs, and EIP4844 itself does not solve the storage problem and the bandwidth problem of on-chain blocks.

Blobs will be deleted from the Ethereum consensus layer after about 3 weeks, and to achieve complete historical record storage and full data availability, current solutions include: dApps storing data related to themselves, Ethereum portal networks (currently under development), or third-party protocols such as block browsers for storage, and storing historical data or personal user-initiated storage in BitTorrent.

Therefore, Proto-Danksharding will benefit storage protocols, modular protocols, and L1 storage expansion networks:

The demand for historical data calls will provide a new development channel for decentralized storage protocols or third-party indexing protocols;

Subsequent modular protocols can ensure high-speed Rollup execution, secure settlement at the settlement layer, and low-cost, high-capacity data availability layers;

L1 storage expansion networks, such as Ethstorage, can provide second-layer solutions with programmable storage at lower storage costs.

3. The Cancun upgrade benefits L2 diversity, L3, RAAS, and data availability tracks

L2 track analysis:

Leading Layer2 projects such as ArbitrumOrbit, OPStack, Polygon2.0, FractalScaling (under StarkWare), and HyperChain (under zkSync) will benefit. The reduction in storage costs brought about by blobs will greatly improve the cost and scalability issues that previously limited the development of Layer2, greatly enhancing data throughput. After solving the cost issue, leading Layer2 will have the opportunity to continue deploying L3 ecosystems tailored for specific functions and highly customized multi-chain concurrency.

The gap in operating costs between second-tier Layer2 and mainstream Layer2 will be narrowed, giving smaller projects more development opportunities, such as Aztec, Metis, Boba, ZKspace, layer2.finance, etc.

Although the real demand for modular blockchain projects still needs to be verified, the possibility of diverse programming languages remains, such as Starkware's Cario, Move language series, and Wasm-supported C, C++, C#, and Go series languages, which can attract more web2 developers.

RAAS track analysis:

The advantage of RAAS itself lies in its high degree of customization, where customization needs > pure cost and efficiency, so cost reduction is a significant advantage for customized Rollup.

However, the RAAS track may have been overhyped, and there are even doubts about the RAAS track itself. Faced with competition from 5 leading Layer2 projects and various new DAs, it is questionable whether new projects can form a track.

First, the deployment advantage of leading Layer2 application chains lies in the completeness of the network framework and the security of the inter-chain ecosystem, while the advantage of RAAS lies in its customization and freedom;

However, the OP and ZK series of RAAS have weak technical barriers, and they are still in the testnet stage in the short term, with no actual product interaction. Considering the actual progress of RAAS, the form of technology, and the future ecological advantages of Layer3, the actual demand for RAAS is questionable.

OP series: Although the bedrock upgrade and 4844 launch of OP stack have brought a small improvement in cost and efficiency, the attractiveness of this improvement is not strong.

ZK Series: Currently, there are more leading projects taking the ZKEVM route, with a greater focus on compatibility with Ethereum. Therefore, circuit design may sacrifice some efficiency and may not be as targeted as the OP series. However, most ZKRAAS projects on the market still use leading projects (such as ZkSync) to fork chains, and the barriers are not strong.

Therefore, in the short term, OPRAAS still has some room for development before the landing of Layer3. In the long term, ZKRAAS and Layer3 may be the future trend.

ZKRAAS has a greater cost disadvantage after 4844, consuming much more computational power than OP. Although its cost of uploading to L1 is less compared to OP, this is only a drop in the bucket compared to the cost of the proof generation process. The advantage of OP lies in its ability to quickly build an ecosystem in the short term, and it still has some room for development before the landing of Layer3.

For conventional DeFi applications and the NFT market, transitioning to rollup is not a strict requirement. It is only for payment applications or games with high efficiency requirements that there is a stronger demand for rollup. In the future, DeFi projects may operate on L2, while social activities may occur on L3 or off-chain. Core data and relationships may be stored on L2, and gaming projects may have a demand for L3 or rollup. However, considering that most chain games are essentially financial schemes and tokens cannot circulate externally, this has created a bottleneck for development. Additionally, the emergence of fully on-chain games makes the ecosystem of L3 far more attractive than rollup.

4. Improvements in Developer and User Experience from the Cancun Upgrade

The second important proposal of the Cancun upgrade, SELFDESTRUCT removal, will further enhance the security of Ethereum. It also prepares to introduce a new opcode, SETCODE, to address potential issues with deleted programmatic accounts.

The third proposal of the Cancun upgrade, EIP1153, introduces transient storage opcodes, which can save gas, solve inter-frame communication issues, and pave the way for future storage designs, such as Verkle trees, which will not need to consider the refunding of transient storage.

The fourth proposal of the Cancun upgrade, EIP5656, introduces the MCOPY memory copy instruction, which can more accurately copy code words and improve memory copy performance by about 10%.

The fifth proposal, EIP4788, makes communication between different protocols and applications in the Ethereum network more efficient and secure. It also allows staking pools, bridging, and restaking protocols to have more trustless designs.

The latest (as of June 15, 23) CL-centric EIP upgrades proposed for the Cancun upgrade include EIP6988, EIP7044, and EIP7045, which respectively improve the security and usability of Ethereum in detail, such as improving the staker experience and enhancing network security.

Deleted proposals include the transition from SSZ to RLP, which resulted in the removal of two SSZEIPs (EIP6475 and EIP6493) from the Cancun upgrade. EOF-related proposals were removed from the Cancun upgrade after being removed from the Shanghai upgrade, and are currently being considered for implementation in later regular upgrades. EVMMAX, being a subset of EIPs related to EOF implementation, was also removed from the Cancun upgrade. Considering the potential side effects of transferring ETH and the reasoning, testing, and security work required through proposals, EIP5920 was removed from the upgrade.

5. Relationship with zkML and Account Abstraction

Impact on zkML

ZKML, the combination of Zero-Knowledge Proof (ZKP) and Machine Learning (ML), aims to solve privacy and verifiability issues in machine learning. The storage requirements of ZKML are not closely related to DA: it requires a separate storage structure similar to Space and Time, which is a new secure protocol for "SQL proof." In simple terms, it is a data warehouse located next to the blockchain, allowing developers to connect on-chain and off-chain data in a simple SQL format and load the results directly into smart contracts.

ZK-SNARKs, a major form of ZK in ZKML, can adapt to the on-chain computational requirements of ML. With the development of cryptography, especially recursive SNARK proofs, ZKML's landing on the blockchain will be favored. ZK-SNARKs are highly compact and efficient, allowing for short proofs and minimal interaction between provers and verifiers, making them practical and efficient for real-world applications.

Currently, on-chain training is not possible, and the blockchain can only store the results of off-chain computations. The limitations of computational power and the inability to support large-scale ZK proofs on-chain are key factors affecting the development of ZKML blockchain applications.

Benefits of Account Abstraction

First, the Cancun upgrade can reduce the cost of ZK rollup proofs to a certain extent. The transaction fees of zkSync depend on three aspects: the fixed resource cost consumed by validators to generate and verify SNARK proofs, the gas fees when validators submit SNARK proofs to the Ethereum mainnet, and the service fees paid by users to validators. Therefore, the congestion-related gas fee increase issue will be alleviated after the introduction of 4844, reducing the cost of ZKP proofs to a certain extent.

Second, account abstraction will transform traditional tx transactions into user operations, which will then be packed into blocks using ECDSA. This will increase on-chain storage compared to before, so there will be higher storage requirements.

Furthermore, account abstraction and ZK rollup can complement each other. The current issues with account abstraction include expensive Gas Fees due to multiple steps and involvement of smart contracts, resulting in high data volume and expensive Gas Fees. The advantage of ZK rollup is its ability to reduce data. Account abstraction leads to security challenges due to the involvement of multiple contracts, but as L2 gradually matures, the consensus layer will no longer be modified, and smart contracts will have more utility. The security of account abstraction can be guaranteed, and with the help of trusted verification in ZK rollup, security will be greatly enhanced.

Finally, considering the rise of AI technology, it can help enhance the security of on-chain contracts and optimize on-chain transactions or activities. AI can be used to enhance the security and privacy of on-chain transactions, detect and prevent malicious attacks, fraud, and data leaks, and provide real-time monitoring and alert mechanisms to ensure the security and stability of on-chain transactions. AI can also optimize on-chain activities, including transactions, contract execution, and data storage, by analyzing and predicting data to improve overall efficiency and performance.

Therefore, the Cancun upgrade will gradually benefit the future development of account abstraction, from expanding storage space to complementing ZK rollup, and then integrating with AI technology.

6. Looking Back at the Ethereum Roadmap, What's Next

Currently, Layer2 does not have the performance of Solana in terms of latency and throughput, nor does it have the sharding performance of Near, or the parallel execution performance of Sui and Aptos. The Cancun upgrade has enhanced Ethereum's leading position as a leader.

After the Cancun upgrade, several major development timelines are estimated: Fully-Danksharding (2-5 years), MEV and PBS landing (1-3 years), account abstraction (1-2 years), ZK everything (3-6 years), EOF and developer experience (multiple delays?).

The Scourge

Objective: The main focus is to solve the MEV problem.

Solution: Achieve application-level MEV minimization through "Proposer-Builder Separation (PBS)." This may involve optimizing blobs and introducing pre-confirmation services or front-running protection.

PBS separates block proposers from sorters. Sorters are only responsible for sorting and do not handle on-chain transactions, while block proposers do not handle transactions and directly select sorters to package transactions for on-chain submission. This process makes the entire process more fair and alleviates the MEV problem, representing an approach to externalize MEV.

The completion level of PBS is still low, and the more mature solution for external MEV is the collaboration with flashbots' mevboost.

The advanced version of "Enshrined Proposer-Builder Separation (ePBS)" has a lower completion level and a longer cycle, and it is unlikely to be implemented in the short term. There are also progressive versions of PEPC and Optimistic Relaying, which enhance the flexibility and adaptability of the PBS framework.

The Verge

Objective: Use Verkle trees to replace Merkle trees and introduce a trust-minimized solution to provide lightweight nodes with the same security as full nodes, making block verification as simple and lightweight as possible.

Additionally, the ZK-ification of L1 has been explicitly included in the Verge roadmap. ZK will be the future trend for scalability and speed improvement.

Solution: Introduce zk-SNARKs to replace the old proof systems, including SNARK-based light clients, consensus state change SNARKs, and Enshrined Rollups.

Verkle trees are a more efficient alternative to Merkle trees specifically designed for state. They do not need to provide the path from each sibling node (nodes sharing the same parent node) to the selected node, but only provide the path itself as part of the proof. Verkle proofs are three times more efficient than Merkle proofs.

Enshrined Rollup refers to a Rollup with some form of integrated consensus on L1. Its advantage lies in inheriting L1's consensus, not requiring governance tokens to execute rollup upgrades, and increasing transaction volume by performing computations off-chain and only publishing results to the blockchain. However, the technical difficulty of implementation is high. In the future, these rollups combined will meet most of the needs of the blockchain ecosystem for the next few decades.

The Purge

ThePurge refers to the goal of simplifying the protocol by reducing the storage requirements for participating in the validation network. This is mainly achieved through the hibernation and management of historical and state data. Historical data hibernation (EIP-4444) allows clients to prune historical data older than one year and stop providing services at the P2P level.

State hibernation. When it comes to dealing with state growth, there are two main objectives: weak statelessness, which means only using the state to build blocks without verifying it, and state hibernation, which involves removing state that has not been accessed within a specified time (1 year). State hibernation should reduce the total state storage required by nodes by 20-50GB.

In the fifth stage of ThePurge, EIP4444 is explicitly written into the Roadmap. EIP-4444 requires clients to clear data older than 1 year, and this stage also includes some EVM optimization work, such as simplifying the GAS mechanism and EVM precompilation.

TheSplurge

In the final sixth stage, TheSplurge, EIP4337 is also mentioned as a long-term layout proposal for the wallet ecosystem. Account abstraction will further improve wallet usability, including using stablecoins to pay gas and social recovery wallets.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。