The Ethereum Cancun upgrade is approaching, reviewing the past, present and future of the Cancun upgrade

Author: Fat Bird Finance

past lives

Why is the Cancun upgrade needed?

The vision of Ethereum is to become more scalable and more secure under the premise of decentralization. The current upgrade of Ethereum is also committed to solving this trilemma, but it has been facing great challenges.

Problems with Ethereum:

At present, there are low TPS and performance, high gas fees and serious congestion. At the same time, the disk space required to run an Ethereum client is also growing rapidly. At the bottom, the workload of ensuring Ethereum security and decentralization The impact of the consensus algorithm on the entire environment is also becoming more and more significant.

Therefore, under the premise of decentralization, how to transmit more data and reduce gas to enhance scalability, and how to optimize the consensus algorithm to ensure security are all efforts that Ethereum is currently making.

In order to solve the trilemma of security, decentralization, and scalability, Ethereum has used the PoW-to-PoS mechanism to further reduce the node threshold, and is also planning to use the beacon chain to randomly assign verifiers to optimize security. In terms of scalability, Ethereum considers using sharding to reduce the workload of nodes, which also enables Ethereum to create multiple blocks at the same time and enhance its scalability.

At present, the space of each block of Ethereum is about 200~300KB, the minimum size of each transaction is about 100 bytes, about 2000 transactions, divided by the block time of 12 seconds, the upper limit of TPS of Ethereum is limited to about 100 . This data obviously cannot meet the needs of Ethereum.

Therefore, Ethereum Layer 2 focuses on how to put a large amount of data into the blockspace, and ensure security through fraud proofs and validity proofs. This is why the DA layer determines the upper limit of security, which is also the core content of the Cancun upgrade.

The iterative route of the Ethereum ecology cannot build the performance of the benchmark Solana (in terms of delay and throughput), and the fragmentation performance of Near will not be seen in the short term, nor the parallel execution performance of Sui and Aptos. In the short term, Ethereum can only Building a multi-layer structure with Rollup as the core, so the Cancun upgrade to solve TPS, gasfee and developer experience is crucial to the Ethereum roadmap.

How is the Ethereum roadmap planned?

Recent important upgrades and their goals

On December 1, 2020, the beacon chain was officially released, paving the way for POS upgrades

London upgrade on August 5, 2021, EIP1559 changed the economic model of Ethereum;

On September 15, 2022, the Paris upgrade (TheMerge) completed the POW switch to POS;

On April 12, 2023, Shanghai was upgraded to solve the problem of pledge withdrawal;

The economic model and POS-related upgrades have been completed, and the next few upgrades have solved the problems of Ethereum’s performance, TPS and developer experience;

The next step is focused on TheSurge in the Ethereum roadmap.

Goal: To achieve 100,000+ TPS in Rollup.

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

Off-chain solution: refers to Layer2, including rollup, etc.

On-chain scheme: refers to making changes directly in L1, which is a popular sharding scheme. A simple understanding of sharding is to divide all nodes into different areas and complete the tasks of each area, which will effectively increase the speed;

Fragmentation scheme analysis:

The dilemma of the sharding scheme: Sharding used to include state sharding, transaction sharding, etc., but the synchronization between different shards is a problem. At present, it is technically difficult to complete a large-scale network node data synchronization. Not only can it not solve the situation of MEV, but also a large number of patches may be needed to make up for various problems that may arise, which cannot be realized in the short term.

Danksharding is a new sharding design proposed for Ethereum. Its core idea is centralized block generation + decentralized verification + censorship resistance. This is also related to the data availability sampling (DAS) and block producers mentioned below. - Packager Separation (PBS) and Censorship Resistant Lists (Crlist) related. The greatest significance of Danksharding’s core idea is to turn Ethereum L1 into a unified settlement and data availability (DataAvailability) layer.

The sharding scheme is divided into 2 steps. At present, it is divided into Proto-danksharding and Fully-Rollup.

Proto-danksharding：

Introduction: By introducing blobs to help L2 reduce fees and increase throughput, it also paves the way for full sharding as a pre-scheme for danksharding. It is expected that after proto-danksharding, it will take 2-5 years for the implementation of danksharing.

Content: The main feature of proto-danksharding is to introduce a new type of blob transaction. Blob has the characteristics of large capacity and low cost. Adding such data packets to Ethereum can allow all rollup data to be stored in blob, greatly reducing the storage of the main chain Pressure, but also reduce the cost of rollup.

Fully-Rollup

Introduction: Rollup fully expands capacity, focusing on the utilization of data availability.

content:

P2P design of DAS: Some works and researches related to data sharding network connection problem;

Data availability sampling client: develop a lightweight client that can quickly determine whether data is available by randomly sampling a few kilobytes;

Efficient DA self-healing: able to efficiently rebuild all data under the worst network conditions (e.g. malicious validator attack, or long downtime of large block nodes).

Ethereum Core Developers Meeting

Every upgrade of Ethereum depends on the core developer meeting, through the joint discussion of the core contributors, and according to a series of proposals from the developers, the future development direction is determined

Definition: The core developer meeting is a weekly conference call held by the Ethereum development community, where core contributors from different organizations discuss technical issues and coordinate future work on Ethereum. They determine the future technical direction of the Ethereum protocol, and are also the authority that actually makes decisions about the upgrade of Ethereum. They are responsible for deciding whether EIP is included in the upgrade, whether it is necessary to change the roadmap and other important matters.

Core process: The upgrade process centered on EIP is roughly as follows. First, an EIP is initially accepted at the core developer conference (ACD for short), and then the client team will test it regardless of whether the EIP is included in the upgrade After the final test, review it again, and then decide whether to include it in the actual upgrade based on the discussion.

There are two types of meetings, namely the consensus layer meeting and the executive layer meeting, which are held alternately every other week:

Consensus Layer Conference (AllCore Developers Consensus - ACDC), focusing on the consensus layer of Ethereum (Proof of Stake, Beacon Chain, etc.);

Executive layer conference (AllCore Developers solution - ACDE), which focuses on the execution layer of Ethereum (EVM, Gas schedule, etc.).

There are three types of Ethereum core maintainers, mainly official organizations or volunteer forums that discuss proposals:

AllCoreDevs: code maintainers, responsible for ETH1 network client, upgrade, maintain Ethereum code and core architecture;

“Project Management” section: support Ethereum developers, coordinate hard forks, monitor EIP, etc., and directly help AllCoreDevs with communication and operations;

EthereumMagicians: A “forum” for wanting discussions around EIP and other technical topics.

Timeline of Cancun Escalation Related Meetings

According to the content of the discussion, this Cancun upgrade can be roughly divided into five stages.

The first stage - introducing the upgrade theme

Introduce new tasks proto-danksharding, EOF and “selfdestruct” opcodes, briefly discuss Shanghai upgrade content

After the merger of Ethereum was completed on September 15, 22, the developer meeting was suspended for 4 weeks, allowing developers to check the EIP discussed in the subsequent upgrade for one month;

On October 28, 22, the first developer meeting after the merger proposed the implementation of proto-danksharding, EOF and the “selfdestruct” opcode for the first time. At this time, the specific scope of proto-danksharding has not been determined, and some developers initially think that , the Shanghai upgrade can be divided into several small upgrades, such as enabling pledged ETH withdrawals first, and then upgrading EIP4844, but some developers think that it is more meaningful to implement a larger upgrade in one step.

Phase 2 - Determining the time frame and preparation for the KZG ceremony

At the end of 2022, the Ethereum conference will mainly focus on EOF and EIP4844. At the same time, we will continue to promote the pre-credible setup ceremony required by EIP4844 - the KZG ceremony. Developers will formally determine in which upgrade 4844 will appear in January 23

In November 22, EOF or proto-danksharding was mentioned in the conference call #149 of all core developers of Ethereum. At this time, the developers are still considering placing it in the Shanghai upgrade;

In the Consensus Layer meeting on 12/02/22, Trent Van Epps, head of the Ethereum ecosystem, updated on the progress of the trusted setup ceremony required for the implementation of EIP4844, which aims to generate a piece of secure code that will be used in EIP4844. VanEpps hopes that the ceremony will be one of the largest ever in the crypto space, collecting 8,000 to 10,000 contributions. The public contribution period of the ceremony will last about 2 months and start sometime in December;

In the core developer meeting on the same day, there was some discussion around EOF and deactivation of the selfdestruct opcode. A certain developer of the Ethereum Foundation objected to postponing EOF to Cancun, arguing that if the code changes are not included in Shanghai, it will enter The possibility of Cancun is very small. Regarding the selfdestruct code, some developers advocated advancing EIP4758 at the time, but directly disabling this opcode will break some applications. The developers believe that before creating an edge case to protect this type of contract, This EIP should be weighed again for a period of time;

In the core developer meeting on December 9, 22, the implementation of the KZG ceremony was promoted regarding the Cancun upgrade. At present, the credible setting ceremony required by EIP4844 is ready;

In the Consensus Layer meeting on 12/16/22, on the topic of EIP4844, the developers discussed merging two different pull requests (PRs) into the spec for proto-danksharding, one related to how nodes handle data pruned beyond One is that when information about blobs is missing on a certain block, a new error code will be introduced to alert nodes;

In the core developer meeting on January 5, 23, the developers reached a consensus on removing code modifications related to the EOF implementation from the Shanghai upgrade. At this time, Beiko suggested to decide whether EOF should be included in the hurdle after two weeks. Kun is being upgraded;

Phase 3 - Preliminary Discussion of the Scope of the Proposal

At the end of January 23, EOF was moved to Cancun for upgrade after being removed from Shanghai. In the following two months, discussions mainly focused on other proposals except EOF and EIP4844. At the same time, EOF was proposed to move out of Cancun. This period of time was mainly spent on delineating the scope of proposals for the upgrade of Cancún.

In the core developer meeting on January 20, 23, EOF was moved to Cancun for upgrade;

In the core developer meeting on March 6, 23, the preliminary proposals for the Cancun upgrade were: EIP4788 (public beacon chain state root), EIP2537 (efficiently perform operations such as BLS signature verification and SNARKs verification), EIP-5920 (introduction new opcode PAY), and a combined implementation of EIP6189 (for making SELFDESTRUCT compatible with Verkle trees) and EIP-6190 (changing the SELFDESTRUCT function to cause only a limited number of state changes);

In the core developer meeting on March 16, 23, in addition to EOF and EIP4844, the following proposals were considered for inclusion in Cancun: SSZ format, SELFDESTRUCT deletion, EIP2537, EVMMAX, EIP1153, unlimited SWAP and DUP instructions, introduction of PAY Beacon state root in code and EVM;

In the core developer meeting on March 30, 23, the proposal EIP-6780 on disabling SELFDESTRUCT was put forward for the first time, which is also the proposal to disable SELFDESTRUCT that Cancun finally decided to use. But regarding the implementation of EOF, a developer from the Erigon(EL) client team stated that EOF “has changed too much” to be combined with the Ethereum improvement proposal EIP4844 in the upcoming Cancun upgrade, which was proposed to be upgraded in Cancun Implement EOF in the hard fork shortly after;

The fourth stage - determine the clear direction of proposal upgrade and delete irrelevant proposals

In April 23, there was a clear direction for the proposals that should be covered by the Cancun upgrade. The key node was the developer meeting on April 13. This meeting proposed 9 EIPs, and Tim himself also had a more in-depth understanding of the alternate proposals. Discussion, in the meeting on April 27th, EIP6780, EIP6475 and EIP1153 were determined to be included in Cancun, while EOF and EVMMAX (the EIP subset related to EOF implementation) were removed from the Cancun upgrade, and the EOF upgrade can mainly help EVM Version control and multiple sets of contract rules can be run at the same time, which is conducive to the subsequent expansion of Ethereum. However, considering the feasibility of the entire upgrade, the EOF upgrade may be promoted with daily upgrades in the follow-up

On April 12, 23, the upgrade of Ethereum Shanghai was completed;

In addition to the core dev meeting on 13.04.23 where the developers discussed EIP4844 (for exposing data about the CL state root in the EL), there are at least nine other EIPs being considered for the upgrade, They are EIP4844, SELFDESTRUCT removal (EIP-6780, EIP4758, EIP6046, EIP6190), EIP5920, EIP1153, EIP2537, EIP4788, EVMMAXEIPs (EIP6601 and EIP6690), SSZchanges (EIP6475, EIP6493, EIP 6465, EIP6404 and EIP6466 ), EIP5656 and EIP6193 ;

In the core developer meeting on April 27, 23, several progress and trade-offs were focused on. First, EIP4844 continues to be identified for inclusion in the Cancun upgrade, while the following EIPs have been added: EIP6780 (changes functionality of the SELFDESTRUCT opcode), EIP6475 (a new Simple Serialization (SSZ) type to represent optional values), EIP1153 (adds new secondly, the EIPs that are being considered but not officially included in the upgrade are EIP6913 (introducing the SETCODE instruction), EIP6493 (defining the signature scheme for SSZ-encoded transactions), EIP4788 (disclosing the beacon chain root in the EL block header), EIP2537 (adds BLS12-381 curve as precompile) and EIP5656 (introduces new EVM instructions for copying memory regions); finally, EOF and EVMMAX (subset of EIP related to EOF implementation) were removed from the Cancun upgrade. The EOF upgrade was removed from the Shanghai upgrade at the Ethereum Developers Conference in early January 2023, and it was defaulted to appear in the Cancun upgrade from the end of January 2023 to the beginning of April 2023, but the development on April 29, 23 EOF is removed again during the meeting of the authors.

The fifth stage - final proposal determination and detail improvement

In May 23, the final proposal details were mainly streamlined and improved. The change of SSZ->RLP will mean that the two SSZEIPs in Cancun will no longer be needed, so EIPs6475 and 6493 will be moved out of Cancun for upgrade. Also at the caucus on the 26th, Tim Beiko suggested that future conversations around expanding the scope of Cancun be limited to the following five EIPs: EIP-5920, 5656, 7069, 4788, and 2530. The developers have now determined the full extent of the Cancun upgrade.

The Ethereum Core Consensus Meeting on May 5, 23 discussed EIP4788, which was mentioned last time, and added discussions on EIP6987 and EIP6475, which are about validators and SSZ transactions respectively;

In the 161st Ethereum executive layer meeting on May 11, 23, TimBeiko said that the scope of the Cancun upgrade can still be modified in the next few weeks, but if there is no clear suggestion from the developer, the scope of the Cancun upgrade will be Keep the “default” status, and the discussion about EIP-4844 shows that developers agree to remove SSZ from the EL implementation of EIP-4844, but it has not affected the continued advancement of 6475. In addition to this, the developers also briefly discussed two EIPs for consideration in Cancun, namely EIP6969 (a modified version of EIP1559) and EIP5656 (Efficient EVM instructions for copying memory regions);

The development of 4844 was briefly discussed in the Developer Consensus meeting on 18.05.23, such as allowing smart contract applications on EL to verify proofs of CL state;

Deactivation of SELFDESTRUCT, EIP-4844 specification changes, opcode management, and potential eventual Cancun additions were discussed in the 162nd Ethereum Core meeting on May 25, 2023. Tim Beiko suggested that future conversations around expanding the scope of Cancun be limited to the following five EIPs: EIP-5920, 5656, 7069, 4788, and 2530. The developer will determine the full range of Dencun (Deneb+Cancun) in the next few weeks;

At the 110th Ethereum Consensus Layer Meeting on June 1, 2023, a researcher from the Ethereum Foundation introduced the results of a data experiment on the ability of Ethereum mainnet nodes to disseminate large amounts of data. From this result, the researcher suggested that EIP4844 The specification increased from a maximum of 4 blobs to 6 per block. At the same time, developers are considering incorporating EIP4788 into the Cancun upgrade;

In the core developer meeting on June 13, 2023, the developers officially confirmed the scope of the upgrade, including EIP4844, EIP1153, EIP5656, EIP6780, and EIP4788;

In the consensus meeting on June 15, 2023, it was discussed which CL-centric EIPs to include in Deneb, among which, EIP-6988, EIP-7044, EIP-7045 were proposed to be added, and the CL client team agreed on the next Test the increased number of blobs on the EIP-4844 test network Devnet6, and make a final decision on this matter within two weeks. At the same time, Michael Neuder, a researcher at the Ethereum Foundation, proposed to cancel the 32 ETH pledge limit to help reduce the growth of the active validator set;

In the meeting on June 22, 2023, Tim proposed to move the precompiled address of 4844 to 0xA, pack them and move BLS to another address, although this precompiled was introduced through EIP2537, it will not be considered in Cancun plan;

In the consensus meeting on June 29, 2023, the developers continued to discuss the number of blobs, raised the target blob limit from 2 to 3, and raised the maximum blob limit from 4 to 6. At the same time, the 4844 testnet Devnet#7 will be launched soon.

this life

The core content is EIP4844, Proto-Danksharding

The final EIP ranges for the Cancun upgrade are: EIP4844, EIP1153, EIP5656, EIP6780, and EIP4788. At the same time, in the 111th Ethereum ACDC meeting on June 19, developers continued to discuss EIP6988, EIP7044, and EIP7045 for inclusion in Deneb. The developers said they plan to merge the three aforementioned EIPs into the Deneb specification in the coming weeks.

Analysis of key EIPs

EIP4844

Introduction:

The name of the EIP4844 proposal is Proto-Danksharding, which is the pre-sharding solution for the full version of Danksharding. The whole set of sharding schemes actually revolves around Rollup for on-chain expansion. The purpose of the solution is to expand the layer 2 Rollup - by helping L2 reduce fees and increase throughput, while paving the way for full sharding.

In the conference call in February 23, the Ethereum developers upgraded EIP4844 and named it Deneb, which is the name of a first-class star in Cygnus. That is, the name of EIP4844 on the relevant GitHub version will be updated to Deneb in the future; In the meeting on March 1, there were some changes in the next upgrade specification of Ethereum, which is called Deneb on the CL side and Cancun on the EL side;

In the developer meeting on June 23, 23, the developers were going to update the precompiled address of EIP4844. Currently, core developers have added 9 precompiles to the EVM, and will create two precompiles under “0xA” and “0xB” addresses by activating EIP4844 and 4788 respectively. In the consensus meeting on June 29, Devnet#7, a dedicated short-term test network for EIP4844, has been prepared.

EIP-4844 introduces a whole new transaction type - BlobTranscation.

Introduction to blobs:

Blob, similar to a plug-in data package, only has a storage space of 128KB at the beginning. At the beginning of the discussion of the proposal, the target and limit of Blob were 2/4. In the developer meeting on June 9, 23, it was adjusted to 3/6 . That is, at present, each transaction in Ethereum can carry up to three Blob transactions, which is 384KB, and the targetBlob capacity of each block is 6, which is 768KB, and can carry a maximum of 16 Blob transactions, which is 2MB;

It may have a certain impact on network stability, but the Ethereum development team still decided to test it first to avoid the need for subsequent hard forks to expand the blob block.

Blob uses KZGcommit Hash as Hash for data verification, similar to Merkle;

After the node synchronizes the BlobTransaction on the chain, the Blob part will expire and be deleted after a period of time, and the storage time is three weeks.

The role of Blob - improve the TPS of Ethereum while reducing costs

At present, the total data volume of the entire Ethereum is only about 1TB, and Blob can bring 2.5-5TB of additional data volume to Ethereum every year, which directly exceeds the ledger itself by several times;

For nodes, downloading 1MB to 2MB of blob data per block will not cause a bandwidth burden, and the storage space will only increase the fixed amount of blob data of about 200~400GB per month, which will not It affects the decentralization of the entire Ethereum node, but the expansion around Rollup is greatly improved;

And the node itself does not need to store all the blob data, because the blob is actually a temporary data package, so in fact, the node only needs to download a fixed amount of data for three weeks.

The role of EIP-4844 - opening the first chapter of the Danksharding narrative

High expansion: At present, EIP-4844 can initially expand the L2 capacity. The full version of Danksharding can expand the Blob data volume in EIP-4844 from 1MB to 2MB to 16MB to 32MB. High expansion;

Low fees: According to bernstein analysts, Proto-dank-sharding can reduce the fees of the layer 2 network to 10-100 times the current level;

The actual data:

The Opside test network has deployed 4844, and the current observation can reduce the cost of rollup by 50%;

EigenLayer’s DA technical solution does not disclose too much to evaluate its data;

Strictly speaking, Celestia has little to do with Ethereum, and its DA cost cannot be assessed now, depending on its specific technical solutions;

Ethstorage’s solution is to upload its Layer2 storage certificate, and its DA cost may be reduced to 5% of the original;

Topia expects to reduce costs by 100 to 1000 times, because the main network Danksharding also needs to take into account security and compatibility with Layer 1 P2P network broadcasting.

DA solution: Danksharding (a sharding solution for Ethereum expansion) currently may have problems with excessive node burden (above 16mb) and insufficient data availability (validity period of 30 days) if it continues to expand. Solution:

DataAvailability Sampling - reduces node burden

Cut the data in the Blob into data fragments, and let the nodes change from downloading the Blob data to randomly checking the Blob data fragments, so that the Blob data fragments are scattered in each node of the Ethereum, but the complete Blob data is stored in the entire Ethereum In Fang ledger, the premise is that the nodes need to be sufficient and decentralized;

DAS uses two technologies: erasure coding (ErasureCoding) and KZG polynomial commitment (KZGCommitment);

Proposer-packager separation (PBS) - solves the problem of the division of labor between nodes, allowing nodes with high performance configurations to be responsible for downloading all data for encoding and distribution, and allowing nodes with low performance configurations to be responsible for spot checks and verifications.

Nodes with high performance configurations can become builders. Builders only need to download blob data for encoding and create blocks, and then broadcast to other nodes for spot checks. For builders, Because the synchronization data volume and bandwidth requirements are high, it will be relatively centralized;

A node with low performance configuration can become a proposer (Proposer). The proposer only needs to verify the validity of the data and create and broadcast the block header (BlockHeader). However, for the proposer (Proposer), the amount of synchronous data and bandwidth requirements are relatively high. Low, so it will be decentralized.

Anti-censorship list (crList) - solves the problem that packagers can deliberately ignore certain transactions and insert transactions they want to obtain MEV because of their excessive review power.

Before the builder (Builder) packs block transactions, the proposer (Proposer) will first publish a review-resistant list (crList), which contains all transactions in the mempool;

The builder (Builder) can only choose to package and sort the transactions in crList, which means that the builder cannot insert his own private transaction to obtain MEV, nor can he deliberately reject a transaction (unless the Gaslimit is full);

After packing, the Builder broadcasts the final version of the transaction list Hash to the Proposer, and the Proposer selects one of the transaction lists to generate a block header (BlockHeader) and broadcast it;

When the node synchronizes data, it will obtain the block header from the proposer (Proposer), and then obtain the block body from the packager (Builder), to ensure that the block body is the final selected version.

Dual-slot PBS - solves the problem that centralized packagers are becoming more and more centralized by acquiring MEV

Use the bidding mode to determine the block:

The builder (Builder) creates the block header of the transaction list after getting the crList and bids;

The proposer (Proposer) selects the block header and the builder (Builder) that finally bid successfully, and the proposer unconditionally receives the winning bid fee (regardless of whether a valid block is generated);

The verification committee (Committees) confirms the winning block header;

The Builder discloses the body of the winning block;

The verification committee (Committees) confirms the body of the winning block and conducts a verification vote (if the block is passed, the block is produced, and if the packager deliberately does not give the block Body, it is considered that the block does not exist).

significance:

First of all, the builder (Builder) has more power to package transactions, but the crList mentioned above firstly limits the possibility of temporarily inserting transactions, and secondly, if the builder (Builder) wants to profit by changing the transaction order, its It is necessary to pay a large bidding cost at the beginning to ensure that it can obtain the qualification of the block head, then the MEV profit it obtains will be further reduced, and overall it will have an impact on the means and actual value of obtaining MEV;

However, in the early stage, only a small number of people may become packers (considering node performance issues), while most people only become proposers, which may lead to further centralization. At the same time, when the number of packers itself is very small Under certain circumstances, some experienced miners with MEV capabilities will be more likely to bid successfully, which will further affect the actual MEV solution effect;

This has implications for some MEV solutions that use MEV auctions.

significance:

EIP4844 is actually a super simplified version of Danksharding: it provides the same application interface as Danksharding, including a new opcode called DataHash; and a new data object called BinaryLarge Objects, which is Blob;

proto-danksharding is a “bracket” (that is, transaction format and verification rules) proposal to implement the complete Danksharding specification: however, no sharding has been implemented yet, and all verifiers and users still need to directly verify the availability of complete data;

Why do you choose proto-danksharding instead of EIP4488 to directly lower the layer2 fee in the long-term, because only a small adjustment is required when upgrading to a full shard in the future:

The main practical difference between EIP4488 and proto-danksharding is that EIP-4488 tries to minimize the changes that Ethereum needs to make today, while proto-danksharding makes more changes to Ethereum today in order to upgrade to Ethereum in the future. Minimal changes are required for full version sharding;

Although implementing full sharding (data availability sampling, etc.) is a very complex task, and there is still a lot of work to be done after implementing proto-danksharding, these complexities will be controlled on the consensus layer. Once proto-danksharding is deployed, the executive layer client team, rollup developers, and users do not need to do any additional work when transitioning to full sharding.

To achieve complete sharding, it is necessary to complete the actual implementation of PBS, delegated proof, and data availability sampling, but such modifications will be concentrated on the CL layer, and developers do not need to readjust: currently 4844 implements a new transaction type, which is similar to The transaction format, consensus cross-validation logic, and execution layer logic required in the complete sharding are exactly the same, and a self-adjusting independent gas pricing for blobs is also derived. In order to achieve complete sharding in the future, PBS and delegation certificates need to be completed And the actual implementation of data availability sampling, but these modifications are only at the CL layer, and do not require modifications by the EL layer or rollup developers, which is convenient for developers.

Followed by SELFDESTRUCTremoval, EIP-6780 was finally determined to be the most suitable solution, but at the developer meeting on the 26th, Tim proposed to add another opcode SETCODE to this proposal to allow programmatic accounts to still be updated

SELFDESTRUCTremoval EIP-6780：X

background:

In March 21, Vitalik proposed that SELFDESTRUCT does more harm than good to the Ethereum ecology. The main reason is that it is the only one that can change an infinite number of state objects in a single block, resulting in contract code changes, and can be modified without the consent of the account. The operation code of the account balance has a great hidden danger to the security of Ethereum;

The only way to remove a contract on-chain is SELFDESTRUCT. If you call the selfdestruct function in the contract, you can self-destruct the contract. The Ethereum stored in the contract will be sent to the designed address. The remaining code and storage variables will be removed in the state machine. In fact, the action of contract destruction sounds good in theory, but it is actually very dangerous. Although the selfdestruct function can help developers delete the smart contract and transfer the balance in the contract to the specified address in an emergency, this feature is also used by criminals, making it a means of attack.

In the core developer meeting on April 13, 23, four proposals on SELFDESTRUCT were introduced to participate in the discussion, namely 6780, 4758, 6046 and 6190, and the follow-up EIP6780 was determined as the final proposal.

Introduction: selfdestruct is the emergency button of the smart contract, which destroys the contract and transfers the remaining ETH to the designated account.

EIP6780: Disable SELFDESTRUCT unless they are in the same transaction in the contract.

UPDATE: On May 26th, tim proposed that in addition to removing SELFDESTRUCT, add another opcode - SETCODE, to allow programmatic accounts to still be updated. (That is, the update function is added, and the property in the smart contract is updated by means of update/upgrade), here is the advantage of EIP4758, which allows dapp to have room for upgrade.

Reason: Manipulating the SELFDESTRUCT code originally required extensive changes to the account state, such as deleting all codes and storage. This creates difficulties for using Verkle trees in the future: each account will be stored in many different account keys that will not be explicitly connected to the root account.

CHANGE: This EIP implements a change that removes SELFDESTRUCT, except in the following two cases

Apps that are only used to withdraw funds from SELFDESTRUCT will still work;

The SELFDESTRUCT used in the same transaction in the contract also does not need to be changed.

Significance: Improve safety

Previously, there was a contract on the mainnet that used SELFDESTRUCT to restrict who can initiate transactions through the contract;

To prevent users from continuing to deposit funds and trade in a vault after SELFDESTRUCT, then this vault may cause anyone to steal tokens in the vault during repeated use.

The three proposals below are proposals related to SELFDESTRUCT that were subsequently deleted. 6780 was officially selected in the core developer meeting on April 28, 23, and the remaining three proposals were abandoned because the Ethereum development team eventually wanted to completely delete the SELFDESTRUCT opcode , and the following three proposals are more amended by means of replacement.

EIP-4758 (DEPRECATED): Disable SELFDESTRUCT by changing SELFDESTRUCT to SENDALL, which restores all funds to the caller (sends all ether in the account to the caller), but does not delete any code or storage.

Reason: Same as above, previously manipulating SELFDESTRUCT codes required extensive changes to the account state, such as deleting all codes and storage. This creates difficulties for using Verkle trees in the future: each account will be stored in many different account keys that will not be explicitly connected to the root account.

Change:

Opcode SELFDESTRUCT renamed to SENDALL, now only moves all ETH in the account to the caller, the scheme no longer breaks code and storage, or changes nonces;

All related refunds SELFDESTRUCT have been deleted

significance:

The original functionality is preserved compared to EIP-6780, because some applications still/need to use the SELFDESTRUCT code.

EIP-6046 (deprecated): Replace SELFDESTRUCT with DEACTIVATE. Change SELFDESTRUCT to not delete the storage key and use a special value in the account nonce to indicate deactivation

Reason: Same as above, with Verkle trees, accounts will be organized differently: account properties (including storage) will have separate keys, but it will be impossible to traverse and find all used keys. However, manipulating SELFDESTRUCT codes required a large number of changes to the account state, which made it very difficult to continue using SELFDESTRUCT in Verkle trees.

Change:

Change the rules introduced by EIP-2681 so that regular nonce increments are bounded by 2^64-2 instead of 2^64-1;

SELFDESTRUCT is changed to:

Do not delete any storage keys and leave the account in place;

Transfer the account balance to target, and set the account balance to 0.

Set the account nonce to 2^64-1.

No refunds since EIP-3529;

The relevant rule SELFDESTRUCT of EIP-2929 remains unchanged.

significance:

This proposal has more flexibility than other behaviors that directly delete SELFDESTRUCT.

EIP-6190 (deprecated): Change SELFDESTRUCT, compatible with Verkle, so that it only causes a limited number of state changes

Reason: Same as above, with Verkle trees, accounts will be organized differently: account properties (including storage) will have separate keys, but it will be impossible to traverse and find all used keys. Manipulating SELFDESTRUCT codes previously required extensive changes to the account state, making it very difficult to continue using SELFDESTRUCT in Verkle trees.

Change: Instead of destroying the contract at the end of the transaction, the following happens at the end of the transaction that called it:

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

The 0th slot of the contract is set to the address that will be published when the contract uses the CREATE opcode (keccak256(contractAddress, nonce)). The random number is always 2^64-1.

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

The balance of the contract will all be transferred to the address at the top of the stack;

The top of the stack is popped.

significance:

Designed to allow SELFDESTRUCT to subsequently form Verkle trees with minimal changes;

Gas cost increased with EIP-2929 applied.

Then there is EIP1153, which saves gas and paves the way for future storage design

EIP1153X

Summary: Transient store opcodes, add opcodes for manipulating state that behaves the same as stores but discards after each transaction.

reason:

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

Currently, these frameworks can communicate in two ways: input/output via CALL instructions, and via store updates. Communication via I/O is unsafe if there is an intermediate framework belonging to another untrusted contract.

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

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

Transient storage is private to the contract that owns it, and like persistent storage, only the owning contract framework can access its ephemeral storage. When accessing storage, all frames access the same ephemeral storage in the same way as persistent storage, but differently from memory.

Potential use cases:

reentrancylock；

Computable CREATE2 addresses on-chain: constructor parameters are read from the factory contract, rather than being passed as part of the initialization code hash;

Single transaction EIP-20 approval, e.g. #temporaryApprove(addressspender, uint256 amount);

Transfer fee contract: pay a fee to the token contract to unlock transfers during transactions;

“Till” mode: Allows the user to perform all operations as part of the callback, and checks if “till” is balanced at the end;

Proxy call metadata: Pass additional metadata to implementing contracts without using call data, such as the values of immutable proxy constructor parameters.

significance:

Save gas and have simpler gas billing rules;

Solve the problem of inter-frame communication;

does not change the semantics of existing operations;

No need to clear the storage slot after use;

Future storage designs (such as Verkle trees) do not need to consider the issue of chargebacks for instantaneous storage.

Then there is 4788, which can reduce the trust assumption of the pledge pool

EIP4788：X

Brief: Beacon block roots in the EVM.

Update: In the developer meeting on 15.06.23, the developers proposed to make code changes to improve the staker experience, this EIP will disclose the root of the beacon chain block, which contains the EVM internal chain state information, for DApp developers trust-minimized access.

Changed: Submit the hash roots of each beacon chain block in the corresponding execution payload header, store these roots in a contract in execution state, and add a new opcode to read that contract.

Significance: This is a code modification proposal, which proposes to modify the Ethereum Virtual Machine (EVM) so that it can disclose the data of the contract layer (CL) state root in the execution layer (EL), which can make different protocols and applications in the Ethereum network Communication between programs is more efficient and secure. Allow more trustless designs for staking pools, bridging, and restaking protocols.

Finally there is the 5656, which provides an efficient new memory copy opcode, but is currently in a state of being temporarily included in an upgrade due to its testing bandwidth

EIP5656X

Introduction: MCOPY- memory copy instruction.

UPDATE: On 09.06.23, the development team stated that they were initially divided on MCOPY because while it solved the security issue, they were concerned about the implementation+testing bandwidth needed to add it to the upgrade, but finally agreed to include the EIP, However, if the developer encounters capacity issues in testing or on the client side, it will be considered for removal. As such, MCOPY is in a state of being temporarily included in the Cancun upgrade.

Changed: Provided an efficient EVM instruction to copy memory regions.

Significance: Memory copying is a fundamental operation, but there is a cost to implementing it on the EVM.

With the availability of the MCOPY instruction, code words and sentences can be copied more accurately, which will increase the memory copy performance by about 10.5%, which is very useful for various computationally intensive operations;

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

It can save a certain amount of gas cost for identity precompilation, but it cannot actually promote the realization of this part.

Candidate list EIP

On June 15, 23, the developer consensus meeting discussed which CL-centric EIPs to include in Deneb, among which, EIP6988, EIP7044, and EIP7045 were proposed to be added.

EIP6988：X

Summary: Prevents slashed validators from being elected as block proposers.

Significance: Increased penalties for violating nodes will benefit DVT.

EIP7044：X

Summary: Ensuring that signed validator exits are permanently valid.

Significance: It can improve the staker experience to a certain extent.

EIP7045：X

Summary: Extend the attestationslot inclusion range from a rolling window of one epoch to two epochs.

Significance: Enhance network security.

Delete the analysis of EIP

In the 160th Ethereum ACDE meeting on April 29, 23, EVMMAX and EOF were confirmed to be removed from this upgrade, and changes related to EOF may be introduced in subsequent daily upgrades

EVMMAXEIPs：

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

EIP6601: EVM Modular Arithmetic Extensions (EVMMAX)

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

6601 introduces a new EOF section type that stores the modulus, the precomputed Montgomery parameter, the number of values that will be used (runtime configurable modulus is still supported);

6601 uses a separate memory space for EVMMAX values, with new load/store opcodes to move values between EVM<->EVMMAX memory;

The 6601 supports operations on moduli up to 4096 bits (tentative limit mentioned in EIP).

Significance: EIP-5843 introduces efficient modular addition, subtraction, and multiplication for the Ethereum Virtual Machine, and EIP-6601 builds on this by introducing a setup section, a separate memory space, and new opcodes for modular arithmetic operations Provides better organization and flexibility while supporting larger modules and improving EVM performance.

As an EVM contract, enabling elliptic curve arithmetic operations on various curves, including BLS12-381;

MULMOD reduces the gas cost of operating on values up to 256 bits by 90-95% compared to existing opcodes ADDMOD;

Allows modexp precompilation to be implemented as EVM contracts;

Significantly reduce the cost of ZKP verification in algebraic hash functions (such as MiMC/Poseidon) and EVM.

EIP6690：

Change: EIP-6990 is a proposal adapted from EIP-6601 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 standalone solution. It provides a more simplified approach by removing the dependency on EOF.

Significance: It retains the core functionality of EIP-6601 to perform optimized modular arithmetic operations on odd moduli 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 EVM, which introduces new contract standards and some new opcodes. The traditional EVM bytecode (bytecode) is an unstructured sequence of instructions bytecode. EOF introduces the concept of a container, which implements structured bytecode. The container consists of a header and several sections to structure the bytecode. After the upgrade, the EVM will be able to perform version control and run multiple sets of contract rules at the same time.

EIP663：

Brief: Unlimited SWAP and DUP instructions

Significance: By introducing two new instructions: SWAPN and DUPN, which differ from SWAP and DUP by increasing the stack depth from 16 elements to 256 elements

EIP3540：

Introduction:

In the past, the EVM bytecode deployed on the chain did not have a pre-defined structure, and the code would only be verified before being run in the client. This is not only an indirect cost, but also hinders developers from introducing new functions. Or deprecate old functionality.

This EIP introduces a container that can be extended and version controlled for the EVM, and declares the format of the EOF contract. Based on this, the code can be verified when the EOF contract is deployed, that is, creationtime validation, which means that it can prevent unreasonable Contracts that conform to the EOF format are deployed. This change implements EOF version control, which will help to disable existing EVM instructions or introduce large-scale functions (such as account abstraction) in the future.

significance:

Version control is conducive to the introduction or deprecation of new functions in the future (such as the introduction of account abstraction);

The separation of contract code and data is beneficial to L2 verification (op), reducing the gas cost of L2 validators. At the same time, the separation of contract code and data is also more convenient for data analysis tools on the chain.

EIP3670：

Introduction: Based on EIP-3540, the purpose is to ensure that the code of the EOF contract conforms to the format and is valid. For contracts that do not conform to the format, its deployment will be prevented and Legacybytecode will not be affected.

Significance: Based on the container introduced by 3540, EIP-3670 ensures that the code in the EOF contract is valid, or prevents it from being deployed. This means that undefined opcodes cannot be deployed in EOF contracts, which has the added benefit of reducing the number of EOF versions that need to be added.

EIP4200：

Introduction:

The first EOF-specific opcodes are introduced: RJUMP, RJUMPI, and RJUMPV, which encode destinations as signed immediate values. Compilers can use these new JUMP opcodes to optimize the gas cost of deploying and executing JUMP because they eliminate the runtime required to do jumpdestanalysis for existing JUMP and JUMPI opcodes. This EIP is a complement to dynamicjump.

Compared with the traditional JUMP operation, the difference is that operations such as RJUMP do not specify a specific offset position, but specify a relative offset position (from dynamicjumps -> static jumps), because staticjumps are often enough.

Significance: optimize the network and reduce costs.

EIP4750：

Take the function of 4200 one step further: by introducing two new opcodes of CALLF and RETF, an alternative solution is realized for the situation that cannot be replaced by RJUMP, RJUMPI and RJUMPV, so that JUMPDEST is no longer needed in the EOF contract, that is, Therefore dynamicjump is disabled.

Significance: Optimize code by dividing code into several parts.

EIP5450：

Background: The background is still that the Ethereum contract is not checked when it is deployed, and only a series of checks are performed when it is running, whether the stack overflows (the upper limit is 1024), whether the gas is enough, and so on.

Content: Added another validity check for EOF contracts, this time around the stack. This EIP prevents situations where EOF contract deployments could lead to stack underflows/overflows. This way, clients can reduce the number of validity checks they do during execution of EOF contracts.

Significance: A major improvement is to make these checks that occur during execution as few as possible, and more checks occur when the contract is deployed.

After the developer meeting update on May 26, the change of transaction type from SSZ to RLP related to EIP4844 meant that the two SSZEIPs in Cancun were no longer needed, so EIPs6475 and 6493 were moved out of Cancun to upgrade

EIP6475X

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

UPDATE: During the 161st Ethereum Execution Layer Core Developers Meeting, discussions about the SSZ serialization format for EIP4844 revealed that initially developers tended to introduce early iterations of the SSZ format to EL via blob transactions, and eventually the developers plan to bring all The transaction type was upgraded from RLP to SSZ, but the developers have been weighing removing SSZ from EIP-4844 given its unclear path and certainly not being able to implement it on the Cancun upgrade. After many discussions, the developers agreed to remove SSZ from the EL implementation of EIP-4844, but they have not yet removed EIP6475. After the May 26 update, the SSZ->RLP change will mean that the two SSZEIPs in Cancun are no longer needed: thus EIPs 6475 and 6493 will be moved out of Cancun for upgrades.

EIP6493X

Introduction: SSZ transaction signature scheme. This EIP defines a signature scheme for Simple Serialization (SSZ) encoded transactions and will address how nodes should handle blob transaction types that are formatted in SSZ format on CL but encoded differently on EL. This EIP is part of an update to the Ethereum serialization format for cross-layer consistency;

Background: SSZchanges

Introduction: SimpleSerialiZe is the serialization method used on the beacon chain.

SSZchanges also includes three other supporting proposals, this time only 6465 was introduced.

EIP6465: SSZ withdrawal root, which defines the migration process of existing Merkle-PatriciaTrie (MPT) commitments to Simple Serialization (SSZ) withdrawals;

EIP6404/ EIP6466：

Both define a process for migrating existing Merkle-PatriciaTrie (MPT) commitments to Simple Serialization (SSZ).

EIP-6404— SSZ transaction root

EIP-6466— SSZ Receipt Base

Tim Beiko suggested in the core developer meeting on May 26 that future conversations around expanding the scope of Cancun be limited to the following five EIPs: EIP5920, 5656, 7069, 4788, and 2537, and that subsequent proposals will be generated within this scope. Subsequent EIP5656 and EIP4788 were confirmed as formal upgrade proposals, and 5920, 7069, and 2537 were removed. Among them, EIP5920 was due to developers’ concerns about potential side effects of the way of transferring ETH, as well as unfinished reasoning, testing, and security work. Removed from upgrade.

EIP5920：X

Introduction: payment opcode. Introduces new opcode PAY for Ethereum transfers, which sends Ether to an address without calling any of its functions.

Reason: Currently, sending ether to an address requires the user to call a function on that address, which has several problems:

First, it opens up a vector for reentrancy attacks, since the receiver can call back to the sender;

Second, it opens a DoS vector, so the parent function must be aware that the receiver may run out of gas or callback;

Finally, the CALL opcode is unnecessarily expensive for simple ether transfers, as it requires expanding memory and stack, loading the receiver’s full data, including code and memory, and finally needs to perform a call, possibly doing other unintentional operate.

Change:

A new opcode has been introduced: (PAY)PAY_OPCODE, where:

Pop two values from the stack: addrthenval.

Transfer wei from execution address val to address addr. If addr is zero address, valwei will be programmed from the execution address.

Potential pitfalls: Existing contracts will be used independently of the actual balance of their wallet, since it is already possible to send ether to an address without calling it.

Significance: save gas.

UPDATE: On 09.06.23, PAY was removed from the upgrade due to concerns about potential side effects that could exist in the way ETH is transferred, and the reasoning, testing, and security work required to pass the proposal.

EIP7069X

Introduction: Modified CALL instruction

Change: Introduced three new call instructions, CALL2, DELEGATECALL2, and STATICCALL2, which have the effect of simplifying the semantics. Aims to remove gas observability from the new directive and open the door to a new class of contracts that are not affected by repricing.

background:

63/64th rule: limit the call depth and ensure that the caller has remaining gas to make state changes after the callee returns;

Before rules 63/64 were introduced, the available gas to the caller needed to be calculated somewhat accurately. Solidity has a complex rule that tries to estimate the cost on the caller side of executing the call itself in order to set a reasonable gas value.

The 63/64th rule is currently introduced:

Removed call depth inspection;

Make sure to reserve at least 5000 gas before executing the called behavior;

Make sure at least 2300 gas is available for the called behavior.

Subsidy rules: such as the well-known 2300 subsidy, when a contract calls another contract, the called contract will get 2300gas to perform very limited operations (enough to do a little calculation and generate a log, but not enough to fill a storage slot) , since it sets a fixed amount of gas, as long as the gas price can be adjusted, people have no way to determine what type of calculation these gas can support.

Significance: Pave the way for the introduction of EOF in the future, and make it easier to run large contracts.

Remove gas optionality: the new command does not allow specifying the gas limit, but relies on the “63/64th rule” (mainly referring to the gas re-pricing for a large number of IO operations in EIP-150, which increases the gas consumption of specific operations) to Limiting gas, this important improvement is to simplify the rules around “subsidy”, no matter whether the value is sent or not, the caller does not need to perform calculations related to gas;

With the introduction of the new proposal, users can always overcome the Outof Gas error by sending more gas in the transaction (subject to the block gas limit, of course).

Some contracts that only sent a limited amount of gas to their calls were broken by the new costing mechanism when previously raising storage costs (eg EIP-1884 increased gas for certain opcodes). Previously some contracts had a gas cap that permanently limited the amount of gas they could spend, even if they sent it into their sub-calls it wouldn’t work out, no matter how much extra gas they sent, because the call would limit the amount sent .

Pave the way for the introduction of EOF: Once the EVM Object Format (EOF) is introduced, old call instructions can be rejected in the EOF contract, ensuring that they are largely immune to gas price changes. Since these operations are required to remove gas observability, EOF will require them in place of existing instructions;

More Convenience Status Return Codes: Convenience functions have been introduced that return more detailed status codes: success (0), revert (1), failure (2), and can be extended in the future.

EIP2537：X

Brief: A precompilation of BLS12-381 curve manipulation.

CHANGED: Added operations on the BLS12-381 curve as precompiles to the set necessary to efficiently perform operations such as BLS signature verification and perform SNARKs verification.

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

PR3175 was mentioned, but never shortlisted, no further discussion

PR3175：X

Summary: This proposal would prevent penalized validators from proposing blocks when dequeued. If more than 50% of validators are penalized for malicious behavior, those validators will still be able to propose blocks while being forcibly removed from the network. Changing this logic is a relatively minor CL layer change that provides protection against “high failure modes,” the developers say.

According to the 108th Ethereum Core Developers Consensus Meeting on May 4th, PR3175 is in the process of being formatted as EIP, and will be changed to EIP-6987, that is, for security reasons, to prevent slashed verification nodes from being selected is the block proposer.

future

Based on the above information, we have reached the following conclusions:

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

There is no doubt that expansion is the first priority (4844);

Safety and gas saving are the second priority (6780, 1153, 5656 and 7045), while taking into account a certain developer experience;

The third is interoperability, such as optimizing the connection, communication and interoperability between dapps (4788, 7044 and 6988);

Expected data: Testnet 4844 can reduce the cost of opsiderollup by 50%; the technical solutions of EigenLayer and Celestia have not disclosed too much, and their data cannot be evaluated; Ethstorage estimates that the cost of DA will drop to 5% of the original; Topia is expected to reduce the cost by 100~1000 times .

2. The next 2 to 5 years when Cancun is upgraded to Danksharding is the golden development period for DA layer projects

The security upper limit of Layer 2 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. V God mentioned that the purpose of the Ethereum consensus protocol is not to guarantee the permanent storage of all historical data. Instead, the intention is to provide a highly secure real-time bulletin board and leave room for other decentralized protocols for longer-term storage (The purpose of the Ethereum consensus protocol is not to guarantee storage of all historical data forever. Rather, the purpose is to provide a highly secure real-time bulletin board, and leave room for other decentralized protocols to do longer-term storage. );

Secondly, Danksharding reduces the cost of DA, but the actual landing time and data availability issues also need to be resolved.

DA cost reduction: Before this update, it was necessary to call calldata to release data from rollup to the Ethereum main chain, and the gas fee for calling this code was very expensive, which was the largest expenditure in layer2. EIP4844 introduces data blobs as rollups The unique additional data space will greatly reduce storage costs, thereby reducing DA costs.

The actual landing time is long, and the TPS that can be improved and the gas that can be reduced are still limited, so it is good for the continued development of DA layer projects in the future:

In polynya’s iablesecurity data sharding article on danksharding, it shows that it will take 2-5 years to implement;

Even if it lands, the TPS it can increase and the gas level it can reduce are still limited:

EIP4844 currently supports 6 blobs, and the future expansion problem can only be solved by Danksharding;

The current Ethereum block space is about 200KB. After Danksharding, the planned size in the specification is 32 megabytes, which is about a 100-fold improvement. At present, the TPS of Ethereum is about 15, and in an idealized state, it will be about 1500 after being increased by 100 times, which is not a big improvement in magnitude.

Therefore, long implementation time + limited actual changes will benefit DA layer projects. Some DA projects such as Celestia and Eigenda can still compete with Danksharding through cheaper costs and faster TPS. New DA projects such as ETHstoragetopia can also fill the ground previous market gap.

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

There are two main costs of DA, one is the cost of network bandwidth, the other is the cost of storage, and 4844 itself does not solve the storage problem and the bandwidth problem of the block chain

The blob will be stored on the Ethereum consensus layer for about 3 weeks and then deleted. If you want to store complete historical records and make all data available, the current solutions include: dapp itself stores data related to itself, and the Ethereum portal network (currently under development) under development) or third-party protocols such as block explorers, historical data in BitTorrent, or spontaneous storage by individual users.

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

The demand for calling historical data will lead to a new development channel for decentralized storage protocols or third-party index protocols;

Subsequent modular agreements can execute transactions through high-speed Rollup, the safe settlement layer is responsible for settlement, and the low-cost and large-capacity data availability layer is responsible for guarantee;

It is good for L1 storage expansion network, such as Ethstorage, which can provide a second-tier solution for programmable storage at a lower storage cost.

3. Cancun upgrade is good for L2 diversity, L3, RAAS and data availability and other tracks

L2 track analysis:

Top Layer 2, five projects such as ArbitrumOrbit, OPStack, Polygon2.0, FractalScaling (under StarkWare) and HyperChain (under zkSync) will benefit. The storage fee reduction brought by blob will greatly improve the previous series of cost and scalability problems that limited the development of layer2, and greatly enhance the data throughput. After solving the cost problem, the head layer2 will have the opportunity to continue to deploy specific functions, high-level Customized multi-chain concurrent L3 ecology;

The gap in operating costs between second-tier Layer 2 and mainstream Layer 2 will be narrowed, which will give some small projects more opportunities for development, such as Aztec, Metis, Boba, ZKspace, layer2.finance, etc.;

Although the real needs of modular blockchain projects are still to be verified, diverse programming languages are still possible, such as Starkware’s Cario, Move series languages, Wasm supported C, c++, C# and Go series languages, which can introduce more Many web2 developers.

Raas track analysis:

The advantage of Raas itself lies in its high degree of customization, customized requirements > pure cost and efficiency, so cost reduction is a big advantage of customized Rollup.

But the problem with the RAAS track is that it may be OverHype, and there are even doubts about the RAAS track itself. Facing the competition from the top 5 layer2s and the emergence of various new DAs, we have to put a question mark on whether the new projects can form a track.

First of all, the advantage of the deployment of the head layer2 application chain lies in the integrity of the network framework and the security of the inter-chain ecology, and the advantage of RAAS lies in its customization and freedom;

However, the RAAS technical barriers of the OP and ZK series are not strong at present, and they are still in the testnet stage in the short term, and there is no actual product interaction. Considering the actual progress of RAAS, technical forms, and the ecological advantages of layer3 in the future, the actual demand for RAAS is doubtful.

OP series: Although the bedrock upgrade +4844 of the OP stack has brought some small improvements in cost and efficiency, the attractiveness of the improvements is not strong;

ZK series: At present, many leading projects follow the ZKEVM route and pay more attention to the compatibility with Ethereum, so the circuit design will sacrifice certain efficiency, and it is not as targeted as the OP series. However, most of the ZKRAAS currently on the market still use leading projects (such as ZkSync) to fork the chain, and the barriers are still not strong.

Therefore, in the short term, OPRAAS still has some room for development before layer3 lands. In the long run, ZKRAAS and layer3 may be the future trend.

ZKRAAS has a greater cost disadvantage after 4844, and it consumes much more computing power than OP. Although the cost of uploading to L1 is less than that of OP, this is only a drop in the bucket compared to the cost of the proof process, while OP The advantage is that it can quickly build an ecology in a short period of time, and there is still room for development before layer3 lands;

For conventional DeFi applications and NFT markets, the transformation of rollup is not a rigid requirement. Only payment applications or games that require high efficiency have a stronger demand for rollup. In the future, defi projects may be on l2, social projects may be on l3 or off-chain, and finally core data and relationships are placed on l2. Gaming projects need to go to l3 or rollup, but considering that most of the current chain games are essentially Funds, and the inability of tokens to circulate externally have brought development bottlenecks, coupled with the emergence of games on the entire chain, the ecological appeal of l3 itself is far greater than that of rollup.

4. Cancun upgrade improves developer and user experience

The second important proposal of the Cancun upgrade, SELFDESTRUCTremoval, will further improve the security of Ethereum. At the same time, for the procedural account update problem that may exist after deletion, a new operation code SETCODE is prepared to improve this situation;

The third proposal EIP1153 upgraded by Cancun adds transient storage opcodes, which can firstly save gas, secondly solve the problem of inter-frame communication, and finally pave the way for future storage design, such as Verkle tree will not need to consider the refund of transient storage question;

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

The fifth proposal of the Cancun upgrade is EIP4788, which can make the communication between different protocols and applications in the Ethereum network more efficient and secure, and also allow more trustless designs for staking pools, bridging and restaking protocols;

The latest Cancun upgrade (June 15, 23) proposes to add CL-centric EIP upgrades: EIP6988, EIP7044, and EIP7045, which improve the security and usability of Ethereum in details, such as improving the pledger Experience and improve network security, etc.

Among the deleted proposals, the SSZ->RLP transition caused two SSZEIPs (EIP6475 and EIP6493) to be removed from the Cancun upgrade; EOF-related proposals were removed from the Cancun upgrade again after being removed from the Shanghai upgrade, and are currently considered possible It will be directly implemented in the later daily upgrades; EVMMAX is also removed from Cancun for upgrades together with EOF because it is a subset of EIP related to EOF implementation; considering the potential side effects that may exist in the way of transferring ETH, and the need to pass the proposal The reasoning, testing and security work, EIP5920 is removed from the upgrade.

5. Relationship with zkml and account abstraction

Little effect on zkml

ZKML is the combination of Zero Knowledge Proof (ZeroKnowledge) and Machine Learning (Machine Learning); the combination of blockchain and ML model solves the privacy protection and verifiability problems of machine learning:

Privacy protection: the confidentiality of input data, such as using a large amount of personal information as data to feed machines for training, the confidentiality of personal information is a major requirement; or model parameters, as the core competitiveness of the project, also need to be encrypted to maintain competition barriers. When trust issues such as these exist, ML models will be hindered from obtaining larger-scale data and applications.

Verifiability: Zero-knowledge proof technology has a wide range of applications, and ZKP allows users to know the correctness of information without verification. And because the machine learning model requires a lot of calculations, the ML model can generate proofs through ZK-SNARK, reducing the proof size and alleviating the computing power demand of ML.

The storage requirements of ZKML have little to do with DA: a separate storage structure like Space and Time is required, and its core technology is the new security protocol “SQL Proof”. Or connect on-chain and off-chain data in a simple SQL format and load the results directly into smart contracts;

ZK-SNARKs is the main form of ZK in ZKML, which can adapt to the computing power requirements of ML on the chain. With the development of cryptography, especially recursive SNARK proofs will benefit the implementation of ZKML on the chain:

ZK-SNARKs are characterized by high compactness. Using ZK-SNARKs allows the prover to generate a short proof, and the verifier does not need to interact and only needs to perform a small amount of calculation to verify its validity. This requires only one prover The nature of interacting with verifiers makes ZK-SNARKs efficient and practical in practical applications, and is more suitable for ML’s on-chain computing power requirements.

It is currently impossible to train on the chain, and only the results of off-chain calculations can be stored on the chain:

The current ML problem is more due to the unsatisfied computing power requirements and low performance caused by algorithm limitations (cannot be calculated in parallel). Large model ZK proves that higher computing power is required, which cannot be supported on the chain. The current popular ZK-SNARKs only support small The ML zero-knowledge proof of scale and small amount of calculation, that is, the limitation of computing power is a key factor affecting the development of ZKML blockchain applications, and the chain can only store the results of off-chain calculations.

Good account abstraction

First of all, the Cancun upgrade can reduce the cost of ZKrollup proof to a certain extent:

The current zkSync transaction fee depends on 3 aspects:

The fixed resource cost consumed by the verifier to generate the SNARK certificate and verify it is relatively high;

The gas fee when the verifier submits the SNARK proof to the Ethereum mainnet, this part of the fee will increase accordingly due to the congestion of the mainnet;

The service fee paid by the user to the verifier, including transaction confirmation, message broadcast, etc.

Therefore, if 4844 is introduced, the problem of increased gas fees caused by mainnet congestion will be alleviated, and the cost of ZKP proofs can be reduced to a certain extent. The development trend of the ZK series should not be underestimated.

Secondly, account abstraction transforms traditional tx transactions into useroperations, and then packs useroperations into blocks with ECDSA, which occupies more storage on the chain than before, so the storage requirements are higher;

Then, account abstraction and ZKrollup can complement each other:

At present, the problem of account abstraction is that GasFee is expensive. Because there are too many steps and smart contracts are involved, there is a lot of data, which makes GasFee expensive. The advantage of ZKRollup is that it can reduce data;

Account abstraction makes it difficult to guarantee security: Since AA involves multiple contracts, security is a problem. However, after L2 is gradually formed in the future, the consensus layer will no longer be changed, smart contracts will have more uses, and the security of account abstraction will also increase. It can be guaranteed, and with the trusted verification of ZKrollup, the security will be further improved.

Finally, considering the rise of AI technology, it can help enhance the security of on-chain contracts and optimize on-chain transactions or activity steps:

AI and security: AI technology can be used to enhance the security and privacy protection of on-chain transactions. For example, the Web3 security platform SeQure uses AI to detect and prevent malicious attacks, fraud and data leakage, and provides real-time monitoring and alarm mechanisms to ensure the security and stability of transactions on the chain;

Optimization of AI and on-chain activities: Activities on the blockchain include transactions, contract execution, and data storage. Through the intelligent analysis and prediction capabilities of AI, on-chain activities can be better optimized and overall efficiency and performance improved. AI can help identify transaction patterns, detect unusual activity, and provide real-time recommendations to optimize resource allocation for blockchain networks through data analysis and model training.

Therefore, the Cancun upgrade will gradually benefit the future development of account abstraction from the expansion of storage space, to the complementarity with ZKrollup, and then to the combination with AI technology.

6. Looking back at the Ethereum roadmap, what’s next

At present, Layer2 does not have performance similar to Solana (in terms of latency and throughput), nor does it have fragmentation performance like Near, nor does it have parallel execution performance like Sui and Aptos. The Cancun upgrade has improved Ethereum leadership as a leader;

After the Cancun upgrade, it is estimated that several major development times will be 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 (how many times have you seen the extension?).

TheScourge

Goal: Focus on solving MEV problems.

Solution: Minimize MEV at the application layer through “Proposer-Builder Separation (PBS)”. At this time, blobs may be optimized, and pre-confirmation services or pre-emption protection may be introduced.

PBS is the separation of block creators and sorters. The sorter is only responsible for sorting, regardless of the chain, and the block creator does not care about the transaction, and directly selects the package made by the sorter and puts it on the chain. This process will make the whole process more fair and alleviate the problem of MEV, which is the idea of externalizing MEV.

The degree of completion of PBS is still very low at present, and the more mature one is cooperation with external MEV solutions - mevboost of flashbots.

The advanced version of “Enshrined Proposer-Builder Separation (ePBS)” has a lower degree of completion and a longer cycle, and it is estimated that it will not be implemented in the short term. In addition, there are progressive versions of PEPC and Optimistic Relaying, which enhance the flexibility and adaptability of the PBS framework

TheVerge

Goal: Use the Verkel tree to replace Merkle, introduce a trust-minimization solution, enable light nodes to obtain the same security as full nodes, and make block verification as simple and portable as possible.

At the same time, the ZKization of L1 is clearly added to the Verge roadmap. ZK will be the general trend of future expansion and speed-up;

Solution: Introduce zk-SNARKs to replace the old proof system, including SNARK-based light clients; SNARKs with consensus state changes; EnshrinedRollups.

Verkle trees are a more efficient alternative to state-specific Merkle trees that do not need to provide a path from each sister node (nodes that share the same parent) to the chosen node, but only the path itself as proof In part, Verkle proofs are 3 times more efficient than Merkle proofs.

EnshrinedRollup refers to a Rollup that has some kind of consensus integration on L1. The advantage is that it inherits the consensus of L1 and does not need governance tokens to perform rollup upgrades. At the same time, by performing calculations outside the chain and only publishing the results to the blockchain, it can Increase the number of transactions, but the technical difficulty of implementation is relatively large. The combination of these rollups in the future will be able to meet most of the needs of the blockchain ecosystem in the next few decades.

Thepurge

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

state dormant. When it comes to handling state growth, there are two main goals: weak statelessness, which refers to the goal of only using the state to build blocks but not verify it; The state being accessed. State hibernation should reduce the state nodes need to store by a total of 20-50GB.

In the fifth stage of Purge, EIP4444 is explicitly written into the Roadmap. EIP-4444 requires the client to clear data older than one year. At the same time, there are some EVM optimization tasks in this stage, such as simplifying the mechanism of GAS and EVM precompilation, etc.;

TheSplurge

In the final sixth stage of Splurge, EIP4337 was also mentioned. As a long-term layout proposal for wallet ecology, account abstraction will further improve the ease of use of wallets in the future, including using stablecoins to pay for gas and social recovery wallets, etc.;