The vision of Ethereum is to become more scalable and safer 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, the TPS and performance are low, the gas fee is high and the congestion is serious. At the same time, the disk space required to run an Ethereum client is also growing rapidly. At the bottom, the work of ensuring the security and decentralization of Ethereum The impact of the volume 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.
The current space of each block of Ethereum is about 200~300
KB, 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 block
In the space, security is guaranteed through fraud proofs and validity proofs, which 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 build a multi-layer structure with Rollup as the core, so Cancun upgrades to solve TPS, gas
Fees and developer experience are critical to the Ethereum roadmap.
**How is the Ethereum roadmap planned? **
The last few important upgrades and their goals
2020year12month1*
Beacon chain is officially released, paving the way for POS upgrade*
2021**8month5**
London upgrade, EIP1559 changes the economic model of Ethereum;
2022year9month15*
Paris upgrade (The
Merge), completed POW switching POS;*
2023year4month12*
Upgraded in Shanghai, solved the pledge withdrawal problem;*
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 to focus on the Ethereum roadmapThe
Surge。
Target:
Achieve 100,000+ TPS in Rollup.
There are 2 schemes, 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;
Sharding scheme analysis:
The dilemma of the sharding scheme: Sharding used to include state sharding, transaction sharding, etc., but synchronization between different shards is a problem. At present, it is difficult to complete a large-scale network node data synchronization. , not only cannot solve the MEV situation, but also may require a large number of patches 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 production+Decentralized verification+ **Resistance to censorship,**This is also related to the data availability mentioned below Sampling (DAS), Block Producer-Packer Separation (PBS) and Censorship Resistance List (Crlist). The greatest significance of Danksharding's core idea lies in turning Ethereum L1 into a unified settlement (settlement) and data availability (Data availability)
Availability）层。
The sharding scheme is divided into 2 steps, currently it is divided into Proto-
sharding andFully-Rollup*****. ***
Therefore-
danksharding**：**
introduce:
Help L2 fee reduction and increase throughput by introducing blobs
, at the same time as a pre-sharding solution to pave the way for full sharding. It is expected that after proto-danksharding, the implementation of danksharing will take 2-5 years.
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 burden on the main chain. Storage pressure can also reduce the cost of rollup.
Fully-Rollup
Introduction: Rollup is fully expanded, focusing on the utilization of data availability.
content:
P2P design of DAS: some work and research involving data sharding network connection problems;
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 (eg, malicious validator attack, or long-term 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 meeting (ACD for short), and then the client team will test it regardless of whether the EIP is included in the upgrade or not, and After the final test, review it again, and then decide whether to include it in the actual upgrade based on the discussion.
Conferences are divided into 2 categories, which are the consensus layer meeting and the executive layer meeting, which are held alternately every other week:
** Consensus layer meeting (All
Core Developers Consensus - ACDC), focusing on the Ethereum consensus layer (proof of stake, beacon chain, etc.);**
Executive level meeting (All
Core Developers solution - ACDE**), which focuses on the execution layer of Ethereum (EVM, **Gasschedule, etc.).
There are 3 types of Ethereum core maintainers, mainly official organizations or volunteer forums discussing 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;
Ethereum
Magicians: A "forum" that wants 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 5 stages. ***
Phase 1 - Introducing Upgrade Themes
Introduce new tasksproto-danksharding***,EOF and "selfdestruct"Opcode, superficial discussion of 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 are preliminary In my opinion, the Shanghai upgrade can be divided into several small upgrades, such as enabling pledged ETH withdrawals first, and then upgrading EIP
4844, but another group of developers think it makes more sense to implement a larger upgrade in one step.
Phase 2 - Determining the timeframe and preparing for the KZG ceremony
At the end of 2022**, the Ethereum conference mainly revolves around ***EOF and EIP
4844 Discussion, while continuing to promote EIP
4844 The pre-credible setting ceremony required for ***—KZG ceremony, the developers will be on ***23 Year **** 1 **** month officially confirmed which upgrade **** 4844 **** will appear in ***
In November 22, EOF or proto-danksharding has been mentioned in the conference call #149 of all core developers of Ethereum. At this time, developers are still considering placing it in the Shanghai upgrade;
In the consensus layer meeting on December 2, 22, Trent, the head of the Ethereum ecosystem
Van Epps updated the EIP
4844 Progress in implementing the required trusted setup ceremony to generate a
Security code used in 4844. Van
Epps hopes the ceremony will be one of the largest ever in the crypto space, collecting 8,000 to 10,000 contributions, and the public contribution period for the ceremony will last about 2 months and begin 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 developer of the Ethereum Foundation objected to postponing EOF to Cancun, arguing that if the code changes were not included in Shanghai, it would The possibility of entering Cancun is very small, regarding the selfdestruct code, there are developers who advocate advancing the EIP at the time
4758, but disabling this opcode directly will break some applications, and the developer believes that this EIP should be weighed again for a while before creating an edge case to protect this type of contract;
In the core developer meeting on December 9, 22, the implementation of the KZG ceremony was promoted regarding the Cancun upgrade, and the current EIP
4844 The required trusted setup ceremony is ready;
In the consensus layer meeting on December 16, 22, about EIP
4844, the developers discussed merging two different pull requests (PRs) into proto-danksharding's spec, one related to how nodes handle data availability beyond a certain point after data pruning, and one when a block New error codes will be introduced to alert nodes when information about blobs is missing on
During the core dev meeting on 5 Jan 23, the devs reached a consensus to remove code modifications related to EOF implementation from the Shanghai upgrade, Beiko at this time suggested to decide after two weeks whether EOF should be included in Cancun is being upgraded;
Phase III - Preliminary discussion of the scope of the proposal
At the end of 231EOF moved into Cancun for promotion after being moved from Shanghai promotion , since then 2 months mainly revolve around except for EOF and EIP
Other proposals other than 4844* were discussed, and 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 proposal for the Cancun upgrade was: EIP
4788 (public beacon chain state root), EIP
2537 (Efficiently perform operations such as BLS signature verification and SNARKs verification), EIP-5920 (introduces new opcode PAY), and EIP
A combined implementation of 6189 (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, except for EOF and EIP
4844, the following proposals were considered for inclusion in Cancun: SSZ format, SELFDESTRUCT deletion, EIP
2537、EVMMAX、EIP
Unlimited SWAP and DUP instructions, introducing PAY codes and beacon state roots in the 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 disabling SELFDESTRUCT that Cancun finally decided to use. But regarding the implementation of EOF, from Erigon
(EL) A developer on the client team said EOF
'Too Much Change' to Compete with Ethereum Improvement Proposal EIP in Upcoming Cancún Upgrade
4844, there was a proposal to implement EOF in the hard fork shortly after the Cancun upgrade;
The fourth stage - determine the clear direction of proposal upgrade and delete irrelevant proposals
In 234month, there is a clear direction for the proposals that should be covered by the Cancun upgrade, and the key nodes are in 4 ********************************************************************************************************** EIP, and tim also had a more in-depth discussion on the alternate proposals, in 4month In the meeting on 27,EIP
6780、EIP
6475 andEIP
1153** is determined to be included in Cancun, and at the same time *EOF and EVMMAX (with ****EOF **implementation related EIP subset) was removed from Cancun upgrade, EOF upgrade mainly helps EVM performs version control, and can run multiple sets of contract rules at the same time, which will help the subsequent expansion of Ethereum, but considering the feasibility of the entire upgrade, *** EOFThe upgrade may be carried forward with the daily upgrade
23****4month12****, the upgrade of Ethereum Shanghai has been completed;
During the core dev meeting on 13.04.23, the devs discussed the EIP
4844 (for exposing data about the CL state root in the EL), there are at least nine other EIPs being considered for the upgrade, namely EIP
4844**, SELFDESTRUCTREMOVE (EIP-6780, EIP
4758、EIP
6046、EIP
6190）、EIP
5920、EIP
1153、EIP
2537、EIP
4788、EVMMAX
EIPs（EIP
6601 and EIP
6690), SS
changes（EIP
6475、EIP
6493、EIP
6465、EIP
6404 and EIP
6466 ）、EIP
5656 and****EIP
6193**；
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, with the addition of the following EIPs: EIP
6780 (Changes functionality of SELFDESTRUCT opcode), EIP
6475 (A new Simple Serialization (SSZ) type to represent optional values), EIP
1153 (add a new opcode to operate status); secondly, the EIP that is being considered but not officially included in the upgrade is EIP
6913 (introduction of SETCODE instruction), EIP
6493 (Define a signature scheme for SSZ-encoded transactions), EIP
4788 (Expose beacon chain block root in EL block header), EIP
2537 (adds BLS12-381 curve as precompile) and EIP
5656 (introduces new EVM instructions for copying memory regions); finally, EOF ** and ** EVMMAX** (** EOF ** implementation dependent ** * EIP* subset) was removed from the Cancun upgrade. **EOFThe upgrade was moved out of Shanghai at the Ethereum Developers Conference at the beginning of ****2023****1****, and was subsequently upgraded from **** From the end of 1 to the beginning of 4 in 23****, it will appear in the Cancun upgrade by default, but in 23 **EOF **was removed again in the developer meeting on 29, 4. **
The fifth stage - final proposal determination and detail improvement
235month mainly streamlines and improves the details of the final proposal,SSZ->
The RLP changes will mean that the twoSSZs in Cancun are no longer needed
EIPs**, soEIPs
6475 and 6493 will be moved out of Cancun for upgrades. At the same time, in the core meeting on the 26 day, Tim
Beiko recommends that future conversations around expanding the reach of Cancun be limited to the following fiveEIP:EIP-5920 ,5656,7069,4788 and ****2530 *****. The developers have now determined the full extent of the Cancun upgrade. ***
*Ethereum Core Consensus meeting on 5/5/23, discussing the last mentioned EIP
4788, while adding the EIP
6987 and EIP
Discussion in 6475, these two proposals are about verifiers and SSZ transactions respectively;
In the 161st Ethereum executive layer meeting on May 11, 23, Tim
Beiko said that the scope of the Cancun upgrade can still be modified in the next few weeks, but without explicit advice from the developers, the scope of the Cancun upgrade will remain in the "default" state, and the discussion about EIP-4844 shows that the development The author agreed to remove SSZ from the EL implementation of EIP-4844, **but it has not yet affected the continued progress of ** 6475 **. **In addition to this, the developers also briefly discussed two EIPs for consideration in Cancun, namely EIP
6969（EIP
and EIP
5656 (efficient EVM instructions for copying memory regions);
Developments in 4844 were briefly discussed in the Developer Consensus meeting on 18-May-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 final Cancun additions were discussed in the 162nd Ethereum Core meeting on May 25, 2023. Tim
Beiko recommends that future conversations around expanding the reach of Cancun be limited to the following five EIPs: EIP-5920**, 5656, 7069,*** 4788* ** and ** 2530**. The devs will confirm in the next few weeks ** Dencun** (****Deneb
the full range of Cancun****);**
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 the EIP
The 4844 specification increased from a maximum of 4 blobs to 6 per block. At the same time, developers are considering the EIP
4788 included in the Cancun upgrade;
In the core developer meeting on June 13, 2023, developers officially confirmed the upgrade scope, including EIP
4844、EIP
1153、EIP
5656、EIP
6780、EIP
4788；
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 to the following An EIP-4844 test network Devnet6 will test the increased number of blobs and make a final decision on the matter within two weeks, while Ethereum Foundation researcher Michael
Neuder proposed removing the 32 ETH staking cap 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 the BLS to another address, although the precompiled via EIP
2537, but it will not be considered in Cancun;
In the consensus meeting on June 29, 2023, the developers continued to discuss the number of blobs, limiting the target blob
Increased from 2 to 3, increased the maximum blob limit from 4 to 6, and 4844 test network Devnet
#7 is coming soon.
this life
The core content is EIP
4844，即Proto-Danksharding
The final EIP range for this Cancun upgrade is: EIP
4844**、EIP
1153、EIP
5656、EIP
6780、EIP
4788. Meanwhile, at the 111th Ethereum ACDC meeting on June 19th, developers continued to discuss EIP
6988、** EIP
7044**、**EIP
7045 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 KeyEIP
EIP
4844
Introduction:
The name of the EIP4844 proposal is Proto-Danksharding, which is the pre-protocol of the full version of sharding expansion Danksharding. The whole set of sharding schemes actually revolves around Rollup for on-chain expansion. **The purpose of the program is to expand the ** 2layer **Rollup——****By helping L2 reduce fees and increase throughput
, while paving the way for full sharding (sharding). **
In the February 23 conference call, Ethereum developers will EIP
The 4844 upgrade is named Deneb, which is the name of a first-magnitude star in the constellation Cygnus, which is the EIP on the relevant GitHub version in the future
The name of 4844 will be updated to Deneb; in the meeting on June 1, 23, there will be 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 prepared to update the EIP
The precompiled address of 4844. Currently, the core developers have added 9 precompiles to the EVM and will activate the EIP by
4844 and 4788 create two precompiles under "0xA" and "0xB" addresses respectively. In the consensus meeting on June 29, EIP is ready to be launched
4844's dedicated short-term test network Devnet
#7。
EIP-4844** introduces a brand new transaction type - Blob
Transcation。**
*Blob profile:
Blob, similar to a plug-in data packet, only 128 at the beginning
The storage space of KB, at the beginning of the discussion of the proposal, the target and limit of Blob was 2/4, and it was adjusted to 3/6 in the developer meeting on June 9, 23. That is, currently each transaction in Ethereum can carry up to three Blob transactions, that is, 384
KB, the target of each block
Blob capacity is 6, that is 768
KB, which can carry up to 16 blobs, which is 2MB;
It may have a certain impact on network stability, but the Ethereum development team still decided to test first to avoid the need for subsequent hard forks to expand the blob block.
Blob **in ** KZG
commit HashAs a ** Hash, used for data verification, the function is similar to ** Merkle;
The node synchronizes the Blob on the chain
After the Transaction, the blob part will expire and be deleted after a period of time, and the storage time is three weeks.
Blob function - 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, directly far exceeding the ledger itself by several times;
For nodes, downloading an additional 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 does not It will affect the decentralization of the entire Ethereum node, but the expansion around Rollup is greatly improved;
In fact, 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** - to open the first chapter of the Danksharding narrative**
**High capacity 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, ensuring decentralization and security While achieving higher expansion;
**Low fees: **Bernstein analysts show that 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, which can reduce the cost of rollup by 50% according to current observations;
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 the cost by 100~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 the expansion of Ethereum) at present, if the expansion continues, the node burden may be too large (16mb above) and insufficient data availability (30 days validity). Solution: **
Data availability sampling (Data
Availability Sampling) - reduces the burden on nodes
Cut the data in the Blob into data fragments, and let the node 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 In the Ethereum ledger, the premise is that the nodes need to be sufficient and decentralized;
DAS uses two technologies: erasure code (Erasure
Coding) and KZG Polynomial Commitment (KZG
Commitment）；
Proposer-Packager Separation (PBS)——Solved the problem of the division of labor of the nodes, let the nodes with high performance configuration be responsible for downloading all data for encoding distribution, and let the nodes with low performance configuration be responsible for spot check verification.
A node with high performance configuration can become a builder. The builder only needs to download the blob data for encoding and create a block (Block), and then broadcast it to other nodes for spot checks. For builders , because the synchronization data volume and bandwidth requirements are high, so it will be relatively centralized;
A node with low performance configuration can become a proposer (Proposer), and the proposer only needs to verify the validity of the data and create and broadcast the block header (Block
Header), but for the proposer (Proposer), the synchronization data volume and bandwidth requirements are low, so it will be decentralized.
Anti-censorship list (crList) - solves the problem that packagers can deliberately ignore certain transactions and randomly sort 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 Gas
limit 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 the block header (Block
Header) and broadcast;
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 getting 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 will be produced, and if the packager deliberately does not give the block Body, the block will be considered as non-existent).
Meaning:
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 order of transactions, then It needs to pay a lot of bidding costs 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, the number of packers is very small In the case of , some experienced miners with MEV capabilities will be more likely to bid successfully, which will affect the actual MEV solution effect more;
Has some impact on some MEV solutions using MEV auctions.
Meaning:
EIP
4844Actually a super simplified versionDanksharding**: **It provides the same application interface as Danksharding, including a new opcode called Data
Hash; and a new data object called Binary
Large Objects, that is, Blob;
proto-danksharding ** is used to implement the complete ** Danksharding ** specification "bracket"** (** is the transaction format and verification rules****)* * Proposal: However, no sharding has been implemented yet, and all verifiers and users still need to directly verify the availability of complete data;
Why the long-term perspective choosesproto-dankshardingnotEIP
4488 ** directly reduces the fee of ** layer2, because only a small adjustment is required when upgrading to a full shard in the future:
EIP
The main practical difference between 4488 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 it is a very complex task to achieve complete sharding (with data availability sampling, etc.), and there is still a lot of work to be done after proto-danksharding is implemented, these complexities will be controlled on the consensus layer. Once proto-danksharding is deployed, the execution layer client team, rollup developers, and users do not need to do any additional work to transition to full sharding.
To achieve complete sharding, it is necessary to complete the actual implementation of ** PBS, delegation proof and data availability sampling, but such modifications will be concentrated in the ** CL ** layer, There is no need for developers to readjust **: 4844 currently implements a new transaction type, which is exactly the same as the transaction format, consensus cross-validation logic, and execution layer logic required in the complete shard, and also derived for blobs , self-adjusting independent gas pricing, in order to achieve complete sharding in the future, it is necessary to complete the actual implementation of PBS, delegation proof and data availability sampling, but these modifications are only at the CL layer, and do not require EL layer or rollup developers to modify, which is convenient for development By.
followed bySELFDESTRUCT
removal***,EIP-6780 was finally determined to be the most suitable solution, but the developer on 26** In the meeting tim** proposed adding another opcode to this proposalSETCODE to allow programmatic accounts to still be updated***
SELF DESTRUCT
removalEIP-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 changes in contract codes, and can be used without account consent. can modify the operation code of the account balance, which has great hidden dangers in 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 subsequent EIP
6780 was set 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.
EIP
6780: 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 absorption of EIP
The advantages of 4758, which can give dapp room to upgrade.
Reason: Manipulating the SELFDESTRUCT code originally required extensive changes to the account state, such as deleting all codes and storage. This poses a difficulty for using Verkle trees in the future: each account will be stored in many different account keys that will not be explicitly linked to the root account.
CHANGED: This EIP implements changes to remove SELFDESTRUCT, except in the following two cases
Apps that are only used for SELFDESTRUCT to withdraw funds will still work;
SELFDESTRUCT used in the same transaction in the contract does not need to be changed.
Significance: Increased security
Previously, there was a contract on the mainnet that used SELFDESTRUCT to restrict who can initiate transactions through the contract;
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 the proposals about SELFDESTRUCT that were subsequently deleted, in 23year*****4 ***6780 was officially selected in the core developer meeting on **28, and the other three proposals were abandoned. The reason is that the Ethereum development team eventually wants to completely delete the SELFDESTRUCT opcode, and the following three proposals are mostly modified by 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 the SELFDESTRUCT code required extensive changes to the account state, such as deleting all codes and storage. This poses a difficulty for using Verkle trees in the future: each account will be stored in many different account keys that will not be explicitly linked to the root account.
Change:
Opcode SELFDESTRUCT renamed to SENDALL, now only moves all ETH in the account to the caller, this scheme no longer destroys code and storage, or changes random numbers;
All refunds related to SELFDESTRUCT have been deleted
Meaning:
Preserved the original functionality 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 a Verkle tree, 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:
Change the rules introduced by EIP-2681 so that the regular nonce increase is 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 **, **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.
Meaning:
This proposal has more flexibility than other direct deletion of SELFDESTRUCT.
EIP-6190 (DEPRECATED): Changed SELFDESTRUCT, compatible with Verkle, so that it only causes a limited number of state changes
Reason: Same as above, with a Verkle tree, 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.
CHANGED: Instead of destroying the contract at the end of a 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 storage slot of the contract is set to the contract using the CREATE opcode ( keccak256(contractAddress,
nonce)) will be issued when the address. 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 be fully transferred to the address at the top of the stack;
The top of the stack is popped.
Meaning:
Designed to allow SELFDESTRUCT to subsequently form Verkle trees with minimal changes;
Gas cost increased with EIP-2929 applied.
Followed byEIP
1153***, while savinggas, paving the way for future storage design***
EIP
1153X
Brief: 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 frames 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.
with reentrancy
lock as an example, it cannot rely on intermediate frames to communicate the state of the lock: SSTORE communication through storage SLOAD is expensive, and transient storage is a dedicated and gas-efficient solution to the problem of inter-frame communication.
Changed: Two new opcodes, TLOAD ( 0xb3 ) and TSTORE ( 0xb4 ), were added to the EVM.
Transient storage is private to the contract that owns it, just like persistent storage, only the owning contract framework can access its temporary 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:
reentrancy
lock；
On-chain computable CREATE2 addresses: constructor parameters are read from the factory contract, rather than passed as part of the initialization code hash;
Single transaction EIP-20 approval, e.g. #temporaryApprove(address
spender, 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 actions 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.
Meaning:
Savegas**, with simpler** gasbilling rules;
** Solve the problem of inter-frame communication; **
** Do not change the semantics of existing operations; **
No need to clear storage tank after use;
** Future storage designs (such as ** Verkle ** trees) do not need to consider refunds for instantaneous storage. **
Followed by 4788, it can reduce the trust assumption on the pledge pool**
EIP
4788**：**X
Introduction: Beacon block root in EVM.
*Update: In the developer meeting on June 15, 23, developers proposed to make code changes to improve staker experience, this EIP will disclose the root of the beacon chain block, which contains EVM internal chain state information, for DApp development The author's trust minimizes access.
CHANGED: Commit the hash roots of each beacon chain block in the corresponding execution payload header, store those roots in a contract in execution state, and add a new opcode to read that contract.
Significance: This is a code modification proposal that proposes to modify the Ethereum Virtual Machine (EVM) so that it can expose the contract layer (CL) state root Data at the execution layer (EL) can make communication between different protocols and applications in the Ethereum network more efficient and secure**. **Allow more trustless designs for staking pools, bridging and restaking protocols.
The last is5656***, which provides an efficient new memory copy opcode, but is currently in a state of being temporarily included in the upgrade due to its testing bandwidth** *
EIP
5656X
Introduction: MCOPY
Memory copy instruction.
Update: 09.06.23, the development team stated that they were initially divided on MCOPY because while it solved the security issue, they were still concerned about adding it to the implementation+testing bandwidth required for the upgrade, but finally agreed to include the EIP , but will be considered for removal if the developer encounters capacity issues in testing or on the client side. Therefore, 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 basic 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 precisely, which will increase the memory copy performance by about 10.5%, which is very useful for various calculation-intensive operations;
It will also be useful for compilers to generate more efficient and smaller bytecode;
It can save a certain amount of identity precompiled gas costs, but it cannot actually promote the implementation of this part.
Shortlist****EIP
On 236month15**, the developer consensus meeting discussed in *** Which EIP** centered on CL are included in Deneb, where **** EIP
6988****、EIP
7044、******EIP
7045 *** *** is proposed to join. ***
EIP
6988**：**X
Brief: Prevent slashed validators from being elected as block proposers.
Significance: Increased penalties for violating nodes will benefit DVT.
EIP
7044**：**X
Summary: Ensuring that signed validator exits are permanently valid.
Significance: It can improve the experience of stakers to a certain extent.
EIP
7045**：**X
Introduction: will attestation
The slot inclusion range extends from a rolling window of one epoch to two epochs.
Significance: Enhance network security.
Delete analysis of EIP
On the **** day of 29************************************************************************** In 160ACDE meeting of Ethereum, EVMMAX and **** EOF* is confirmed to be removed from this upgrade, changes related to EOF** may be introduced in subsequent daily upgrades***
EVMMAX
EIPs**：**
Brief: 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.
Change: is EIP
5843 iterations, with EIP
The difference of 5843 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, EIP-6601 further upgrades on this basis, by introducing a setup section, a separate memory space and new opcodes, for modular arithmetic Operations provide better organization and flexibility while supporting larger modulus 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 operations on values up to 256 bits by 90-95% compared to existing opcodes ADDMOD;
Allows modexp precompilation to be implemented as an EVM contract;
Significantly reduces the cost of ZKP verification in algebraic hash functions (eg MiMC/Poseidon) and EVM.
EIP
6690：
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 independent solution. It provides a more simplified approach by removing the dependency on EOF.
Significance: It retains the core functionality of EIP-6601, which can 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 benefit.
EOF
changes**：**
Introduction: EOF is an upgrade to EVM, which introduces new contract standards and some new opcodes. The traditional EVM bytecode (bytecode) is an unstructured instruction sequence (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.
EIP
663：
Brief: Unrestricted 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
EIP
3540：
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 features or deprecated old features.
This EIP introduces a container that can be expanded and version controlled for EVM, and declares the format of the EOF contract. Based on this, the code can be verified when deploying the EOF contract, that is, creation
Time validation means that contracts that do not conform to the EOF format can be prevented from being 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.
Meaning:
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 the work of on-chain data analysis tools.
EIP
3670：
Introduction: Based on EIP-3540, the purpose is to ensure that the code of the EOF contract conforms to the format and is valid, and the deployment of contracts that do not conform to the format will be prevented without affecting Legacy
bytecode。
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.
EIP
4200：
Introduction:
Introduced the first EOF-specific opcodes: RJUMP, RJUMPI and RJUMPV, which encode
destinations as signed immediate values. Compilers can use these new JUMP opcodes to optimize the gas cost when deploying and executing JUMP, since they eliminate the need for the existing JUMP and JUMPI opcodes to do jumpdest
The running time required for analysis. This EIP is for dynamic
The addition of jump.
Compared with traditional JUMP operations, the difference is that operations such as RJUMP do not specify a specific offset position, but specify a relative offset position (from dynamic
jumps -> static jumps), because many times static
jumps are enough.
Significance: optimize the network and reduce costs.
EIP
4750：
Take the function of 4200 one step further: by introducing CALLF
The two new opcodes of and RETF implement an alternative solution for the situation that cannot be replaced by RJUMP, RJUMPI and RJUMPV, so that JUMPDEST is no longer needed in the EOF contract, so dynamic is prohibited
jump。
Significance: optimize the code by dividing the code into several parts.
EIP
5450：
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 deployment may cause stack underflow or overflow (stack
underflows/overflows). This way, clients can reduce the number of validity checks they do during execution of EOF contracts.
Significance: A big improvement is to make these checks that occur during execution as few as possible, and more checks occur when the contract is deployed.
5month26*********************************************************************************************************************
4844Related transaction type change fromSSZ****** toRLPmeans that Cancun’s two aSSZ
EIPs, soEIPs
6475 and 6493** are moved out of Cancun for upgrade***
EIP
6475X
Introduction: EIP
Companion proposal to 4844. 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 Executive Layer Core Developers Meeting, there was a discussion about the EIP
Discussion of the SSZ serialization format for 4844 showed that initially the developers favored introducing an early iteration of the SSZ format to EL via blob transactions, and eventually the developers planned to upgrade all transaction types from RLP to SSZ, but given its unclear path and certainly not Implemented on the Cancun upgrade, developers have been weighing removing SSZ from EIP-4844. After much discussion, the developers agreed to remove SSZ from the EL implementation of EIP-4844,** but there is no removal of EIP6475****. **SSZ->
The RLP changes will mean the two SSZs in Cancun are no longer needed
EIPs: ** ThereforeEIPs
6475 and 6493 will be moved out of Cancun for upgrades. **
EIP
6493X
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: SSZ
changes
Introduction: Simple
SerialiZe, is the serialization method used on the beacon chain.
SS
The changes also include three other supporting proposals, this time only 6465 was introduced.
EIP
6465: SSZ withdrawal root, defines existing Merkle-Patricia
Migration of Trie (MPT) commitments to Simple Serialization (SSZ) withdrawals;
EIP
6404
/ EIP
6466：
Both define an existing Merkle-Patricia
Trie (MPT) promises are in the process of migrating to Simple Serialization (SSZ).
EIP-6404
— SSZ transaction root
EIP-6466
— SSZ receipt basis
Tim
Beiko** suggested future developments around expanding Cancun in a core developer meeting on 5month26*** Conversations are limited to the following fiveEIP:EIP
5920,5656,7069,4788 and 2537, follow-up proposals will be generated within this scope. Follow-upEIP
5656*** andEIP
4788 was confirmed as an official upgrade proposal,5920,7069 and2537 removed whereEIP
5920 is due to the developer's concern about the potential side effects of the way to transfer ETH**, as well as the unfinished reasoning, testing and security work, so from the upgrade remove. ***
EIP
5920**：**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 things unintentionally operation.
Change:
A new opcode is introduced: ( PAY) PAY_OPCODE where:
Pop two values from the stack: addrthen val.
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.
Meaning: savegas**. **
*Update: 09.06.23 PAY was removed from the upgrade due to concerns about potential side effects of the way ETH is transferred, and the reasoning, testing and security work required to pass the proposal.
EIP
7069X
Introduction: Modified CALL instruction
CHANGED: 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, a slightly more accurate calculation of the caller's available gas was required. 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.
**Currently introducing **63/64thRules:
Deleted call depth inspection;
Make sure to reserve at least 5000 gas before executing the called behavior;
Make sure there is at least 2300 gas 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 2300
gas is used to perform very limited operations (enough to do a little calculation and generate a log, but not enough to fill a storage slot), and since it sets a fixed amount of gas, there is no way for people to determine these as long as the gas price can be adjusted What type of calculations can gas support?
Significance: ** Paves the way for the introduction of ** EOF ** in the future, and it is more convenient for the operation of large contracts. **
Removed gas optionality: new directives do not allow specifying gas
limit, but rely 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 limit gas. This important improvement simplifies the process around " Allowance" rule, no matter whether the value is sent or not, the caller does not need to perform calculations related to gas;
After introducing the new proposal, users can always overcome Out by sending more gas in the transaction (of course, subject to the block gas limit)
of Gas error.
Previously when raising storage costs (eg EIP-1884 increased gas for certain opcodes) some contracts that only sent a limited amount of gas to their calls were broken by the new costing mechanism. 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 necessary to remove gas observability, EOF will require them in place of existing instructions;
More convenient status return codes: Convenience functions have been introduced that return more detailed status codes: success (0), restore (1), failure (2), and can be extended in the future.
EIP
2537**：**X
Introduction: Precompilation of BLS12-381 curve manipulation.
Changed: Added operations on the BLS12-381 curve as precompiled to the set required to efficiently perform BLS signature verification and perform SNARKs verification etc. operations.
Significance: Ethereum can create more secure cryptographic proofs and allow for better interoperability with the beacon chain**. **
PR
3175 *** Mentioned but not shortlisted, no further discussion ***
PR
3175**：**X
Brief: 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, PR
3175 is in the process of being formatted as an EIP and will be changed to EIP-6987, which is for security reasons to prevent slashed validators from being elected as block proposers.
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, capacity expansion, security, saving gas 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 opside
50% of the cost of rollup; 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 expects to reduce the cost by 100~1000 times.
2.** Cancun upgrade
In the future 2~5 years of Danksharding**, it is the golden development period of DA layer projects****
Layer
The security upper limit of 2 depends on the DA layer it adopts. Proto-Danksharding will benefit storage protocol, modular protocol and L1 storage expansion network through cheaper state data storage.
**First, **Dankshardingreturns 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 publish data from rollup to the Ethereum main chain, and the gas fee for calling this code was very expensive, which is layer
The largest payout of 2, the EIP
4844 introduces data blob as an additional data space unique to rollups, which will greatly reduce storage costs, thereby reducing DA costs.
The actual landing time is long, and the improved ** TPS ** and reduced ** gas ** are still limited, so it is good for ** DA ** layer projects in Subsequent continued development:
iable about danksharding in polynya
In the security data sharding article, it is indicated that it will take 2-5 years to implement;
** Even if it lands, it can increase ** TPS ** and reduce ** gas ** magnitudes are still limited:**
EIP
4844 currently supports 6 blobs, and the future expansion problem can only be solved by Danksharding;
The current Ethereum block space is about 200
KB. After Danksharding, the planned size in the specification is 32 megabytes, which is about a 100-fold increase. At present, the TPS of Ethereum is about 15. 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 time to land+Limited actual changes will benefitDALayer projects, some such as Celestia,** Eigenda** ** ** DA ** project can still pass cheaper cost and faster ** TPS ** to compete with ** Danksharding ** in the future , ETHstorage
Topia* and other new DA projects can also fill the market gap before landing. **
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, the Ethereum portal network (currently 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 protocol, modular protocol and L1 storage expansion network:
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;
Good L1 storage expansion network, such as Eth
storage, which can provide a second-tier solution for programmable storage at a lower storage cost.
**3.**Cancun upgrade benefits L2diversity, L3, RAAS and
Data Availability and Other Tracks
L2 track analysis:
Head Layer2, such as Arbitrum
Orbit、OP
Stack、Polygon2.0、Fractal
5 projects including Scaling (under StarkWare) and HyperChain (under zkSync) will benefit. The storage fee reduction brought by blob will make the previous series of restricted layer
2 The cost of development and scalability issues have been greatly improved, and the data throughput has been greatly enhanced. After solving the cost problem, the head layer
2 There will be an opportunity to continue to deploy a highly customized multi-chain concurrent L3 ecology for specific functions;
The gap in operating costs between second-tier Layer2 and mainstream Layer2 will be narrowed, giving 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, C, c++, C# and Go series languages supported by Wasm, which can introduce More 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 of ** 5 ** heads** layer2 **, the emergence of various new ** DA **, can new projects constitute a We have to put a question mark on the track. **
First, the header layer
2 The advantage of the deployment of the application chain lies in the integrity of the network framework and the security of the ecology between the chains, 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 of RAAS is doubtful.
OP Department: Although OP
stack's bedrock upgrade+
The launch of 4844 has brought about a small increase in cost and efficiency, but the increase is not very attractive;
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. But the ZK currently on the market
Most RAAS still use leading projects (such as ZkSync) to fork the chain, and the barriers are still not strong.
SO, short term OP
RAAS** **There is still room for development before ** layer3 ** lands. In the long run, ** ZK
RAAS ** and ** layer3 ** may be the future trend. **
ZK
RAAS 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
Cancun upgrades the second important proposal SELFDESTRUCT
removal will further improve the security of Ethereum. At the same time, for the possible programmatic account update problems after deletion, we plan to introduce a new operation code SETCODE to improve this situation;
Third Proposal EIP for Cancun Upgrade
1153 adds a transient storage operation code, 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 problem of transient storage;
Fourth proposal EIP for Cancun upgrade
5656 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%;
Fifth proposal for Cancun upgrade is EIP
4788 can make the communication between different protocols and applications in the Ethereum network more efficient and secure, and also allow more trustless designs for pledge pools, bridging and restaking protocols;
Cancun upgrades the latest (June 15, 23) proposed CL-centric EIP upgrades: EIP
6988、EIP
7044、EIP
7045, which improves the security and usability of Ethereum in details, such as improving the experience of pledgers and improving network security.
Among the deleted proposals, SSZ->
The transformation of the RLP makes the two SSZs
EIP（EIP
6475 and EIP
was removed from the Cancun upgrade; EOF-related proposals were removed from the Cancun upgrade after being removed from the Shanghai upgrade, and it is currently considered that it may be directly implemented in the later daily upgrade; EVMMAX is due to some EIPs related to EOF implementation Subset, so it was also moved out of Cancun for upgrade together with EOF; considering the potential side effects that may exist in the way of transferring ETH, as well as the reasoning, testing and security work required to pass the proposal, EIP
5920 removed from upgrade.
**5. **Relationship with zkml and account abstraction
Little effect on zkml
ZKML is zero-knowledge proof (Zero
Knowledge) and machine learning (Machine
Learning); the combination of **blockchain and MLmodel 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 the machine for training, the confidentiality of personal information is a major requirement; or model parameters are the core competitiveness of the project, and encryption is also required to maintain competition barriers . When trust issues such as these exist, ML models are 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 **: **Need something like Space
The core technology of this separate storage structure is the "SQL proof" new security protocol. Simply put, it is a data warehouse next to the blockchain, allowing developers to connect on-chain and off-chain in a simple SQL format. data and load the results directly into the smart contract;
ZK-SNARKs **is the main form of ** ZK ** in ** ZKML **, and can adapt to the on-chain calculation of ** ML ** With the development of cryptography, especially the recursive **SNARKproof will be beneficialZKMLLanding 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 kind of proof only needs one time The nature of the interaction between the verifier and the verifier makes ZK-SNARKs efficient and practical in practical applications, and is more suitable for the computing power requirements of ML on the chain.
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 the low performance caused by algorithm limitations (cannot be calculated in parallel). Large model ZK proofs require higher computing power, which cannot be supported on the chain. The current popular ZK-SNARKs only support ML zero-knowledge proof with small 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, Cancun upgrade can reduce to a certain extentZK
rollupProof of Fee:
The current zkSync transaction fee depends on 3 aspects:
The cost of fixed resources consumed by the verifier to generate SNARK proofs and verify them 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 main network congestion will be alleviated, and the cost of ZKP proofs can be reduced to a certain extent. Although it is not much compared to the cost of generating proofs, considering that ZK is still in its early stages, The future development trend of the ZK series should not be underestimated.
Secondly, account abstraction transforms traditional ** tx ** transactions into ** useroperation, and then ** useroperationsuse *ECDSA * Packed into blocks, the storage on the chain occupies more than before, so the storage requirements are higher;
**Next, account abstraction and ** ZK
rollupcan complement each other:
The current problem of account abstraction is Gas
Fee is expensive, because there are too many steps and smart contracts are involved, so there is a lot of data, which leads to Gas
Fee is expensive, and ZK
The advantage of Rollup is that it can reduce data;
Account abstraction makes it difficult to guarantee security: Since AA involves multiple contracts, security is a problem, but after the gradual formation of L2 in the future, the consensus layer will not be changed, smart contracts will have more uses, and the security of account abstraction can also be guaranteed, with the help of ZK
The trusted verification of rollup will further improve the security.
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;
AI and optimization of activities on the chain: 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 be from the expansion of the storage space, to the integration with the ** ZK
The complementarity of rollup ** and the combination with ** AI ** technology will gradually benefit the future development of account abstraction. **
**6.**Looking back at the Ethereum roadmap, what’s next
**Currently, **Layer2 ** does not have performance (in terms of latency and throughput) similar to ** Solana **, nor like ** Near ** Such sharding performance, and no parallel execution performance like ** Sui ** and ** Aptos **, the Cancun upgrade has improved Ethereum's leading position as a leader; **
After the Cancun upgrade, several major development times are estimatedFully-Danksharding** (2~5 years), MEV * andPBS* 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?). **
The
Scourge
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 protections may be introduced.
PBS is the separation of block producers 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 MEV problems, which is the idea of MEV externalization.
The degree of completion of PBS is still very low, and the more mature ones are
Collaboration with external MEV solutions - mevboost by flashbots.
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 enhances the flexibility and adaptability of the PBS framework
The
Verge
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 light 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 for consensus state changes; Enshrined
Rollups。
Verkle trees are a more efficient alternative to state-specific Merkle trees that don't need to provide a path from each sister node (nodes that share the same parent) to the chosen node, but just the path itself as proof Part of Verkle proofs are 3 times more efficient than Merkle proofs.
Enshrined
Rollup 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.
The
purge
The
Purge 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 serving 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 a block, but not verify it; The state being accessed. State hibernation should reduce the state a node needs to store by a total of 20-50
GB。
In the fifth stage Purge, EIP
4444 is explicitly written into Roadmap, EIP-4444 requires the client to clear data older than one year, and at this stage there are still some EVM optimization work, such as simplifying the mechanism of GAS and EVM precompilation, etc.;
The
Splurge
In the final sixth stage Splurge, EIP
4337 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, social recovery wallets, etc.;
Reference materials:
Ethereum core dev meeting update:
Ethereum
All Core Developers Call #148
Writeup
Ethereum
All Core Developers Call #149 Writeup
Ethereum
Consensus Layer Call #99
Writeup
Ethereum
All Core Developers Call #150
Writeup
Ethereum
All Core Developers Call #151
Writeup
Ethereum
Consensus Layer Call #100
Writeup
Ethereum
All Core Developers ution Call #152
Writeup
Ethereum
All Core Developers ution Call #153
Writeup
Ethereum
Original Magicians forum discussion:
Ethereum
All Core Developers ution Call #156
Writeup
Ethereum
All Core Developers ution Call #157
Writeup
Ethereum
All Core Developers ution Call #158
Writeup
Ethereum
All Core Developers ution Call #159
Writeup
Ethereum
All Core Developers ution Call #160
Writeup
Ethereum
All Core Developers Consensus Call #108
Writeup
Ethereum
All Core Developers ution Call #161
Writeup
Ethereum
All Core Developers Consensus Call #109
Writeup
Ethereum
All Core Developers ution Call #162
Writeup
Ethereum
All Core Developers Consensus Call #110
Writeup
*Tim tweeted about the latest Ethereum Cancun upgrade (09.06.23):
Ethereum All Core Developers Consensus Call #111
Writeup
Ethereum
All Core Developers Consensus Call #112
Writeup
Ethereum upgrade related content:
Introduction to self-destruct code:
Explore the EVMMAX proposal and BLS12-381
Besides EIP-4844, what else will the Cancun upgrade include? A peek at Ethereum's latest consensus call
What new content has been added in the upgrade of Ethereum Shanghai?
tweets:
OK
Ventures: After the upgrade of Ethereum Shanghai, Cancun upgrades potential investment opportunities-
Foresight News
In addition to the high-profile EIP-4844, what proposals will the Cancun upgrade include?
V God: EVM function worth considering for deletion
Proto-Danksharding
FAQ
Recommended by V God丨In-depth understanding of Ethereum’s sharding roadmap, reading this report is enough
An article to understand Danksharding, the new upgrade plan of Ethereum
Decipher interesting facts and hidden secrets in Ethereum's latest roadmap
Vitalik: Why SELFDESTRUCT does more harm than good to Ethereum’s ecology
Ethereum vision:
Blockworks
Research Fellow Brrr: How Proto-Danksharding Accelerates Ethereum's L1
Rollup scalability
The 111th Ethereum ACDC meeting: Discuss the final scope of Deneb upgrade and three proposals including EIP-7044
KOL
Stacy Muur's peek at the evolution of Ethereum scaling solutions: OP
Stack、Arbitrary
Orbit、Polygon
2.0
Horizontal comparison of three types of Rollups: classic Rollups (Optimistic/ZK
Rollups）、Enshrined
Rollups、Sovereign
Rollups
[AMA]
We are EF Research (Pt. 8: 07 July,
2022)：
3 popular tracks worth rethinking in 2023
Montenegro EDCON
Thoughts on the End of 2023: A Look at Infrastructure and Application Trends
Infinite fantasy of the possibility of combining AI and Web3
AI+Web3: Exploring the integration of artificial intelligence and blockchain
Comparing zk-rollup and op-rollup: analyzing why the current zkSync from the verification method
Gas fee is high
"Adding volumes to volumes": account abstraction solutions in the Rollup era
In-depth interpretation of ZKML: technical principles, application scenarios, advantages and challenges
ZKML: a model deployment technology that integrates AI and blockchain to achieve privacy protection
iable
security data
sharding
Dialogue with Qi, founder of EthStorage
Zhou | Data Availability and Decentralized Storage
Read the latest version of Ethereum development roadmap in one article
About Space
and
A brief introduction to Time
Original proposal:
EIP
4844：
EIP
6780：
EIP
1153：
EIP
5920：
EIP
5656：
EIP
7069：
EIP
4788：
EIP
2537：
EVMMAX
EIPs：
EIP
6601：
EIP
6990：
EOF
changes：
EIP
663：
EIP
3540：
EIP
3670：
EIP
4200：
EIP
4750：
EIP
5450：
EIP
6475：
EIP
6493：
PR
3175：
View Original
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
The past, present and future of Cancun upgrades
Past Life
**Why is the Cancun upgrade needed? **
**How is the Ethereum roadmap planned? **
The last few important upgrades and their goals
The sharding scheme is divided into 2 steps, currently it is divided into Proto- sharding andFully-Rollup*****. ***
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.
Timeline of Cancun Escalation Related Meetings
*According to the content of the discussion, this Cancun upgrade can be roughly divided into 5 stages. ***
Phase 1 - Introducing Upgrade Themes
Introduce new tasksproto-danksharding***,EOF and "selfdestruct" Opcode, superficial discussion of Shanghai upgrade content**
Phase 2 - Determining the timeframe and preparing for the KZG ceremony
At the end of 2022**, the Ethereum conference mainly revolves around ***EOF and EIP 4844 Discussion, while continuing to promote EIP 4844 The pre-credible setting ceremony required for ***—KZG ceremony, the developers will be on ***23 Year **** 1 **** month officially confirmed which upgrade **** 4844 **** will appear in ***
Phase III - Preliminary discussion of the scope of the proposal
At the end of 231EOF moved into Cancun for promotion after being moved from Shanghai promotion , since then 2 months mainly revolve around except for EOF and EIP Other proposals other than 4844* were discussed, and 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. ***
The fourth stage - determine the clear direction of proposal upgrade and delete irrelevant proposals
In 234month, there is a clear direction for the proposals that should be covered by the Cancun upgrade, and the key nodes are in 4 ********************************************************************************************************** EIP, and tim also had a more in-depth discussion on the alternate proposals, in 4month In the meeting on 27,EIP 6780、EIP 6475 andEIP 1153** is determined to be included in Cancun, and at the same time *EOF and EVMMAX (with ****EOF **implementation related EIP subset) was removed from Cancun upgrade, EOF upgrade mainly helps EVM performs version control, and can run multiple sets of contract rules at the same time, which will help the subsequent expansion of Ethereum, but considering the feasibility of the entire upgrade, *** EOFThe upgrade may be carried forward with the daily upgrade
The fifth stage - final proposal determination and detail improvement
235month mainly streamlines and improves the details of the final proposal,SSZ-> The RLP changes will mean that the twoSSZs in Cancun are no longer needed EIPs**, soEIPs 6475 and 6493 will be moved out of Cancun for upgrades. At the same time, in the core meeting on the 26 day, Tim Beiko recommends that future conversations around expanding the reach of Cancun be limited to the following fiveEIP:EIP-5920 ,5656,7069,4788 and ****2530 *****. The developers have now determined the full extent of the Cancun upgrade. ***
*Ethereum Core Consensus meeting on 5/5/23, discussing the last mentioned EIP 4788, while adding the EIP 6987 and EIP Discussion in 6475, these two proposals are about verifiers and SSZ transactions respectively;
this life
**Analysis of KeyEIP
EIP 4844
followed bySELFDESTRUCT removal***,EIP-6780 was finally determined to be the most suitable solution, but the developer on 26** In the meeting tim** proposed adding another opcode to this proposalSETCODE to allow programmatic accounts to still be updated***
SELF DESTRUCT removal EIP-6780**：**X
The three proposals below are the proposals about SELFDESTRUCT that were subsequently deleted, in 23year*****4 ***6780 was officially selected in the core developer meeting on **28, and the other three proposals were abandoned. The reason is that the Ethereum development team eventually wants to completely delete the SELFDESTRUCT opcode, and the following three proposals are mostly modified by replacement. ***
Followed byEIP 1153***, while savinggas, paving the way for future storage design***
EIP 1153X
Followed by 4788, it can reduce the trust assumption on the pledge pool**
EIP 4788**：**X
The last is5656***, which provides an efficient new memory copy opcode, but is currently in a state of being temporarily included in the upgrade due to its testing bandwidth** *
EIP 5656X
Shortlist****EIP
On 236month15**, the developer consensus meeting discussed in *** Which EIP** centered on CL are included in Deneb, where **** EIP 6988****、EIP 7044、******EIP 7045 *** *** is proposed to join. ***
EIP 6988**：**X
EIP 7044**：**X
EIP 7045**：**X
Delete analysis of EIP
On the **** day of 29************************************************************************** In 160ACDE meeting of Ethereum, EVMMAX and **** EOF* is confirmed to be removed from this upgrade, changes related to EOF** may be introduced in subsequent daily upgrades***
EVMMAX EIPs**：**
EOF changes**：**
5month26********************************************************************************************************************* 4844Related transaction type change fromSSZ****** toRLPmeans that Cancun’s two aSSZ EIPs, soEIPs 6475 and 6493** are moved out of Cancun for upgrade***
EIP 6475X
EIP 6493X
Tim Beiko** suggested future developments around expanding Cancun in a core developer meeting on 5month26*** Conversations are limited to the following fiveEIP:EIP 5920,5656,7069,4788 and 2537, follow-up proposals will be generated within this scope. Follow-upEIP 5656*** andEIP 4788 was confirmed as an official upgrade proposal,5920,7069 and2537 removed whereEIP 5920 is due to the developer's concern about the potential side effects of the way to transfer ETH**, as well as the unfinished reasoning, testing and security work, so from the upgrade remove. ***
EIP 5920**：**X
EIP 7069X
EIP 2537**：**X
PR 3175 *** Mentioned but not shortlisted, no further discussion ***
PR 3175**：**X
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, capacity expansion, security, saving gas and interoperability:
2.** Cancun upgrade In the future 2~5 years of Danksharding**, it is the golden development period of DA layer projects****
**3.**Cancun upgrade benefits L2diversity, L3, RAAS and Data Availability and Other Tracks
**4.**Cancun upgrade improves developer and user experience
**5. **Relationship with zkml and account abstraction
Little effect on zkml
Good account abstraction
**6.**Looking back at the Ethereum roadmap, what’s next
The Scourge
The Verge
The purge
The Splurge
Reference materials: