The past, present, and future of Cancun’s upgrade

Cancun's upgrade the past, present, and future

Past Life

Why is the Cancun upgrade needed?

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

• Issues with Ethereum:

  • Interpreting the potential profit opportunities of Base Velodrome, DackieSwap, Baseswap…
  • Opinion GMX v2 will become a bigger cornerstone than GLP.
  • No longer hesitant, two bills reveal the latest ideas on cryptocurrency regulation in the United States.

• Currently, there are problems with low TPS and performance, high gas fees, and severe congestion. At the same time, the disk space required to run an Ethereum client is also growing rapidly. At the underlying level, the impact of the work consensus algorithm for ensuring Ethereum’s security and decentralization is becoming 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 the efforts 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 threshold for nodes, and is also preparing to optimize security by using a beacon chain to randomly allocate validators. In terms of scalability, Ethereum is considering using sharding to reduce the workload of nodes, which can also allow Ethereum to create multiple blocks simultaneously and enhance its scalability.

• Currently, each block in Ethereum has a size of about 200-300 KB, and the minimum size of each transaction is about 100 bytes. With approximately 2000 transactions per block, divided by a block time of 12 seconds, the TPS limit of Ethereum is limited to around 100. This data clearly cannot meet the needs of Ethereum.

• Therefore, Ethereum Layer2 focuses on how to put a large amount of data into the block sLianGuaice, ensuring security through fraud proofs and validity proofs. This is also the reason why the DA layer determines the security upper limit, which is the core content of the Cancun upgrade.

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

How is the Ethereum roadmap planned?

Recent important upgrades and their goals

• December 1, 2020: The Beacon Chain was officially released, laying the foundation for the POS upgrade

• August 5, 2021: The London upgrade, EIP1559 changed Ethereum’s economic model;

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

• April 12, 2023: Shanghai upgrade solved the staking withdrawal issue;

• Completed upgrades related to the economic model and POS. The next few upgrades will address Ethereum’s performance, TPS, and developer experience issues;

• The next focus is “The Surge” in Ethereum’s roadmap.

• Goal: 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 solution: Refers to making changes directly on L1, which is the popular shard solution. Shard can be understood as dividing all nodes into different shard areas to complete tasks in each area, which will effectively improve speed.

• Analysis of shard solution:

• The dilemma of shard solution: Previous sharding solutions included state sharding, transaction sharding, etc., but synchronizing between different shards was a challenge. Currently, achieving wide-scale network node data synchronization is technically difficult. It not only fails to solve the MEV issue but may also require a large number of patches to address various problems that may arise. It cannot be achieved 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,” which is also related to the upcoming concepts of Data Availability Sampling (DAS), Block Producer-Sealer Separation (PBS), and Anti-Censorship List (Crlist). The greatest significance of Danksharding’s core idea is to turn Ethereum L1 into a unified settlement and data availability layer.

The shard solution is divided into 2 steps, currently divided into Proto-danksharding and Fully-Rollup.

• Proto-danksharding:

• Introduction: By introducing blob to help reduce fees and increase throughput on L2, while serving as a pre-sharding solution for the implementation of complete sharding, it is expected to take 2-5 years after proto-danksharding for danksharding to be fully realized.

• Content: The main feature of proto-danksharding is the introduction of a new transaction type called blob. Blob has the characteristics of large capacity and low cost. By allowing Ethereum to externally connect with such data packets, all data from rollup can be stored in blob, greatly relieving the storage pressure on the main chain and reducing the cost of rollup.

• Fully-Rollup

• Introduction: Rollup is a comprehensive expansion, with a focus on utilizing data availability.

• Content:

• DAS’s P2P Design: Involves some work and research on data sharding and network connectivity issues;

• Data availability sampling client: Develop a lightweight client that can quickly determine whether data is available by sampling a few kilobytes of random data;

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

Ethereum Core Developer Meetings

Every upgrade of Ethereum relies on core developer meetings, which determine the future development direction based on the collective discussion of core contributors and a series of proposals by developers

• Definition: Core developer meetings are weekly conference calls held by the Ethereum development community. Core contributors from different organizations discuss technical issues and coordinate future work on Ethereum. They determine the future technological direction of the Ethereum protocol and are also the governing body responsible for making decisions on Ethereum upgrades, such as whether to include EIPs in the upgrade and whether to make changes to the roadmap.

• Core process: The upgrade process centered around EIPs is roughly as follows: first, a preliminary acceptance of an EIP is made at the core developer meeting (referred to as ACD). Then, regardless of whether the EIP is included in the upgrade or not, client teams test it and review it again after the final testing is completed. The final decision on whether to include it in the actual upgrade is made based on the discussion.

• The meetings are divided into two categories, alternating every other week:

• Consensus Layer Meetings (All Core Developers Consensus – ACDC), focusing on the Ethereum consensus layer (proof of stake, beacon chain, etc.);

• Execution Layer Meetings (All Core Developers Execution – ACDE), focusing on Ethereum’s execution layer (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 the ETH1 network client, upgrades, and maintenance of Ethereum code and core architecture;

• “Project Management” section: Supports Ethereum developers, coordinates hard forks, monitors EIPs, and directly assists AllCoreDevs in communication and operations;

• Ethereum Magicians: a “forum” that aims to discuss EIP and other technical topics.

Timeline of Cancun Upgrade-related Meetings

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

First stage – Introducing the upgrade theme

Introducing new tasks proto-danksharding, EOF, and “selfdestruct” opcode, discussing the Shanghai upgrade content superficially

• After Ethereum completes the merge on September 15th, 22, developer meetings will be suspended for 4 weeks, giving developers a month to review the EIPs discussed in the subsequent upgrades;

• On October 28th, 22, the first developer meeting after the merge, proto-danksharding, EOF implementation, and “selfdestruct” opcode were first proposed. At this time, the specific scope of proto-danksharding was not determined. Some developers initially believed that the Shanghai upgrade could be divided into several small upgrades, such as enabling withdrawal of staked ETH first, and then upgrading EIP 4844. However, another group of developers believed that implementing a larger upgrade all at once would be more meaningful.

Second stage – Determining the time frame and preparing for the KZG ceremony

At the end of 2022, Ethereum meetings will mainly focus on EOF and EIP 4844, while continuously advancing the pre-trusted setup ceremony required for EIP 4844 – KZG ceremony. Developers will officially determine when 4844 will appear in which upgrade in January 23.

• In the Ethereum all-core developer call #149 in November 22, EOF or proto-danksharding was mentioned, and developers were still considering placing it in the Shanghai upgrade;

• In the consensus-layer meeting on December 2, Trent Van Epps, the head of the Ethereum ecosystem, updated the progress of the trusted setup ceremony required for the implementation of EIP 4844. The ceremony aims to generate secure code that will be used in EIP 4844. Van Epps hopes that this ceremony will be one of the largest ceremonies in the history of the crypto field, collecting 8000 to 10000 contributions. The public contribution period of this ceremony will last for about 2 months and will start at some point in December;

• In the core developer meeting on the same day, there was some discussion about EOF and deactivating the selfdestruct opcode. A developer from the Ethereum Foundation opposed delaying EOF to Cancun, believing that if the code changes are not included in Shanghai, the chances of it entering Cancun are slim. Regarding the selfdestruct code, some developers advocated for pushing forward with EIP 4758. However, directly deactivating this opcode will break certain applications. Developers believe that the EIP should reconsider for a certain period of time before creating an edge case to protect contracts of this type;

• In the core developer meeting on December 9, 22, the implementation of the KZG ceremony for the Cancun upgrade was discussed, and the trusted setup ceremony required by EIP 4844 is now ready;

• In the consensus layer meeting on December 16, 22, developers discussed merging two different pull requests (PR) into the specification of proto-danksharding for EIP 4844. One is related to how nodes handle data availability when the data exceeds a specific point after data pruning, and the other is to introduce new error codes to remind nodes when there is missing information about the blob in a block;

• In the core developer meeting on January 5, 23, developers reached a consensus to remove the code modifications related to EOF implementation from the Shanghai upgrade. At this time, Beiko suggested to decide whether to include EOF in the Cancun upgrade two weeks later;

Phase Three – Preliminary discussion of the scope of the proposal

By the end of January 23, after EOF was removed from the Shanghai upgrade and moved into the Cancun upgrade, the main focus for the next two months was on discussing proposals other than EOF and EIP 4844. At the same time, EOF was proposed to be removed from Cancun. During this period, the scope of the Cancun upgrade proposal was mainly defined.

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

• In the core developer meeting on March 6, 23, the preliminary proposals for the Cancun upgrade were: EIP 4788 (publicly-verifiable chain state root), EIP 2537 (efficient execution of BLS signature verification and SNARKs verification operations), EIP-5920 (introducing new opcode LianGuaiY), and the combination of EIP 6189 (to make SELFDESTRUCT compatible with Verkle tree) and EIP-6190 (changing SELFDESTRUCT function to only cause a limited number of state changes);

• In the core developer meeting on March 16, 23, in addition to EOF and EIP 4844, the following proposals were considered to be included in Cancun: SSZ format, SELFDESTRUCT deletion, EIP 2537, EVMMAX, EIP 1153, unrestricted SWAP and DUP instructions, introducing LianGuaiY code, and beacon state root in EVM;

• In the core developer meeting on March 30, 23, the proposal EIP-6780 to disable SELFDESTRUCT was first proposed, which was also the final proposal for disabling SELFDESTRUCT used in Cancun. However, regarding the implementation of EOF, a developer from the Erigon (EL) client team stated that EOF has “too many changes” and cannot be combined with Ethereum Improvement Proposal EIP 4844 in the upcoming Cancun upgrade. It was suggested to implement EOF in a hard fork shortly after the Cancun upgrade;

Phase 4 – Determine clear upgrade direction and remove irrelevant proposals

In April 23, a clear direction was established regarding the proposals to be covered in the Cancun upgrade. The key nodes were the developer meeting on April 13, where 9 EIPs were proposed, and Tim had in-depth discussions on the backup proposals. In the meeting on April 27, EIP 6780, EIP 6475, and EIP 1153 were confirmed to be included in Cancun. Meanwhile, EOF and EVMMAX (a subset of EIPs related to EOF implementation) were removed from the Cancun upgrade. EOF upgrade can help EVM with version control and run multiple sets of contract rules simultaneously, which is beneficial for the future scalability of Ethereum. However, considering the feasibility of the entire upgrade, the EOF upgrade may be promoted in subsequent regular upgrades.

• On April 12, the Ethereum Shanghai upgrade has been completed;

• In the core developer meeting on April 13, developers discussed EIP 4844 (for publicly exposing CL state root data in EL), and at least nine other EIPs were considered for inclusion in the upgrade, namely EIP 4844, removal of SELFDESTRUCT (EIP-6780, EIP 4758, EIP 6046, EIP 6190), EIP 5920, EIP 1153, EIP 2537, EIP 4788, EVMMAX EIPs (EIP 6601 and EIP 6690), SSZ 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, several progress and trade-offs were made. First, EIP 4844 was confirmed to be included in the Cancun upgrade, and the following EIPs were added: EIP 6780 (functionality change to SELFDESTRUCT opcode), EIP 6475 (a new Simple Serialize (SSZ) type to represent optional values), and EIP 1153 (adding new opcodes to manipulate status). Secondly, EIPs that are under consideration but not officially included in the upgrade are EIP 6913 (introduce SETCODE instruction), EIP 6493 (defining signature schemes for SSZ encoded transactions), EIP 4788 (expose beacon chain root in EL block headers), EIP 2537 (add BLS12-381 curve as a precompile), and EIP 5656 (introduce new EVM instructions for copying memory regions). Finally, EOF and EVMMAX (a subset of EIPs related to EOF implementation) were removed from the Cancun upgrade. EOF upgrade was previously removed from the Shanghai upgrade at the Ethereum developer conference in early January 2023, and it was expected to be included in the Cancun upgrade from the end of January to early April. However, in the developer meeting on April 29, EOF was removed again.

Phase 5 – Final Proposal Confirmation and Detail Refinement

In May 23, the main focus was on streamlining and refining the details of the final proposal. The change from SSZ to RLP means that the two SSZ EIPs in Cancun upgrade are no longer needed. Therefore, EIPs 6475 and 6493 will be removed from the Cancun upgrade. At the core meeting on the 26th, Tim Beiko proposed that future discussions on expanding the scope of Cancun should be limited to the following five EIPs: EIP-5920, 5656, 7069, 4788, and 2530. The developers have now determined the full scope of the Cancun upgrade.

• In the Ethereum Core Consensus Meeting on May 5, discussions were held on EIP 4788, and discussions on EIP 6987 and EIP 6475 were also added. These two proposals are related to validators and SSZ transactions.

• In the 161st Ethereum Execution Layer Meeting on May 11, Tim Beiko stated that the scope of the Cancun upgrade can still be modified in the next few weeks. However, if there are no clear recommendations from the developers, the scope of the Cancun upgrade will remain in a “default” state. In the discussion of EIP-4844, developers agreed to remove SSZ from the EL implementation of EIP-4844, but it has not affected the ongoing progress of EIP 6475. In addition, developers briefly discussed two EIPs for consideration in Cancun, namely EIP 6969 (a modified version of EIP 1559) and EIP 5656 (an efficient EVM instruction for copying memory regions).

• In the Developer Consensus Meeting on May 18, a brief discussion was held on the progress of EIP 4844, such as allowing smart contract applications on EL to verify CL state proofs.

• In the 162nd Ethereum Core Meeting on May 25, discussions were held on disabling SELFDESTRUCT, EIP-4844 specification changes, opcode management, and potential final Cancun additions. Tim Beiko proposed that future discussions on expanding the scope of Cancun should be limited to the following five EIPs: EIP-5920, 5656, 7069, 4788, and 2530. The developers will determine the full scope of Dencun (Deneb + Cancun) in the coming weeks.

• In the 110th Ethereum Consensus Layer Meeting on June 1, a researcher from the Ethereum Foundation presented experimental results on the ability of Ethereum mainnet nodes to propagate large amounts of data. Based on these results, the researcher suggested increasing the maximum number of blobs per block from 4 to 6 in the EIP 4844 specification. At the same time, developers are considering including EIP 4788 in the Cancun upgrade.

• In the core developer meeting on June 13, 2023, the developers officially confirmed the scope of the upgrade, including EIP 4844, EIP 1153, EIP 5656, EIP 6780, EIP 4788;

• In the consensus meeting on June 15, 2023, discussions were held on which CL-centric EIPs to include in Deneb. EIP-6988, EIP-7044, EIP-7045 were proposed to be added. The CL client team agreed to test the increased blob count on the next EIP-4844 testnet, Devnet6, and make a final decision within two weeks. At the same time, Ethereum Foundation researcher Michael Neuder proposed removing the 32 ETH staking limit to help reduce the growth of active validator sets;

• In the meeting on June 22, 2023, Tim proposed moving the precompile address of 4844 to 0xA, packaging and moving BLS to another address. Although this precompile was introduced through EIP 2537, it will not be considered in Cancun;

• In the consensus meeting on June 29, 2023, developers continued to discuss the blob count, raising the target blob limit from 2 to 3 and the maximum blob limit from 4 to 6. Devnet #7 for EIP 4844 testing is about to be launched;

This Life

• The core content is EIP 4844, which is Proto-Danksharding;

• The confirmed EIP scope for the Cancun upgrade includes EIP 4844, EIP 1153, EIP 5656, EIP 6780, EIP 4788. In the 111th Ethereum ACDC meeting on June 19, developers continued to discuss EIP 6988, EIP 7044, EIP 7045 for inclusion in Deneb. Developers plan to merge the above three EIPs into the Deneb specification in the coming weeks;

Analysis of Key EIPs

EIP 4844

• Introduction:

• EIP 4844, named Proto-Danksharding, is a preliminary proposal for the full-scale shard scaling solution Danksharding. The entire shard solution is designed around Rollup for on-chain scaling. The purpose of this proposal is to expand the second layer Rollup by reducing fees and increasing throughput, while paving the way for complete sharding.

• In the February 2023 conference call, Ethereum developers named the upgrade of EIP 4844 as Deneb, which is the name of a first-magnitude star in the constellation Cygnus. Therefore, the naming of EIP 4844 on related GitHub versions will be updated to Deneb. In the June 1st, 2023 meeting, there were some changes to the next Ethereum upgrade specification, referred to as Deneb on the CL side and Cancun on the EL side.

• In the June 23rd, 2023 developer meeting, developers prepared to update the precompiled addresses of EIP 4844. Currently, the core developers have added 9 precompiles to the EVM and will create two precompiles at addresses “0xA” and “0xB” respectively by activating EIP 4844 and 4788. In the consensus meeting on June 29th, they are ready to launch the dedicated short-term test network Devnet #7 for EIP 4844.

• EIP-4844 introduces a new type of transaction called Blob Transaction.

• Blob Introduction:

• Blob is like an add-on data packet, initially with a storage space of only 128 KB. In the early discussions of this proposal, the target and limit of Blob were 2/4. In the developer meeting on June 9th, 2023, it was adjusted to 3/6. Currently, each transaction in Ethereum can carry up to three Blob transactions, totaling 384 KB. The target Blob capacity for each block is 6, which is 768 KB, and the maximum number of Blobs that can be accommodated is 16, which is 2MB.

• It may have some impact on network stability, but the Ethereum development team still decided to conduct preliminary testing to avoid the need for a hard fork in the future to expand blob blocks.

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

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

• The role of Blob – improving Ethereum’s TPS while reducing costs

• Currently, the total data size of the entire Ethereum is only about 1TB, while Blob can bring an additional data volume of 2.5-5TB to Ethereum every year, far exceeding the size of the ledger itself.

• For nodes, downloading an additional 1MB-2MB of Blob data per block does not impose a bandwidth burden, and it only adds a fixed amount of Blob data of about 200-400GB per month to the storage space, which does not affect the decentralization of the entire Ethereum node but greatly improves scalability around Rollup.

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

• The role of EIP-4844 – Opening the prelude to Danksharding narrative

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

• Low fees: According to Bernstein analysts, Proto-dank-sharding can reduce the cost of the second layer network by 10-100 times the current level;

• Real data:

• Opside has deployed 4844 on the testnet, and it is currently observed that it can reduce the cost of rollup by 50%;

• EigenLayer’s DA technical solution has not disclosed much, so its data cannot be evaluated;

• Celestia, strictly speaking, has little to do with Ethereum, and its DA cost cannot be evaluated now, depending on its specific technical solution;

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

• Topia expects to reduce costs by 100-1000 times because the mainnet Danksharding also needs to consider security and compatibility with Layer1’s P2P network broadcasting.

• DA solution: Danksharding (Ethereum’s sharding solution for scalability) currently faces the problems of excessive node burden (>16mb) and insufficient data availability (30-day expiration). The solution:

• Data Availability Sampling – reduces node burden

• Split the data in the Blob into data fragments and transform the node from downloading Blob data to randomly sampling Blob data fragments, so that the data fragments of the Blob are dispersed among each node in Ethereum, but the complete Blob data is stored in the entire Ethereum ledger, provided that there are enough decentralized nodes;

• DAS adopts two technologies: Erasure Coding and KZG Polynomial Commitment;

• Proposal-Bundler Separation (PBS) – solves the division of labor problem for nodes, allowing nodes with high-performance configurations to be responsible for downloading all data for encoding and distribution, and nodes with low-performance configurations to be responsible for sampling and verification.

• Nodes with high-performance configurations can become builders. Builders only need to download Blob data for encoding and create blocks, and then broadcast them to other nodes for sampling. For builders, because the synchronization data volume and bandwidth requirements are relatively high, they may be relatively centralized;

• Nodes with lower performance can become proposers. Proposers only need to validate the validity of the data and create and broadcast block headers. However, for proposers, the data synchronization and bandwidth requirements are lower, so it tends to be decentralized.

• Anti-censorship list (crList) – solves the problem that packers can intentionally ignore certain transactions, arbitrarily sort and insert their desired transactions to obtain MEV, due to their excessive censorship power.

• Before the packer packs the block transactions, the proposer will first publish an anti-censorship list (crList), which contains all the transactions in the mempool.

• The packer can only select and sort the transactions in the crList, which means that the packer cannot insert their own private transactions to obtain MEV, nor can they intentionally reject a transaction (unless the gas limit is full).

• After the packer finishes packing, they will broadcast the hashed final version of the transaction list to the proposer. The proposer selects one of the transaction lists to generate a block header and broadcasts it.

• When nodes synchronize data, they obtain block headers from the proposers and block bodies from the packers, ensuring that the block body is the final chosen version.

• Dual-slot PBS – solves the problem of centralized packers leading to increasing centralization of MEV.

• Use bidding to determine block generation:

• The packer receives the crList and creates a block header for the transaction list and makes a bid.

• The proposer selects the block header and packer with the most successful bid. The proposer unconditionally receives the winning bid fee (regardless of whether a valid block is generated).

• The validation committee confirms the winning block header.

• The packer discloses the winning block body.

• The validation committee confirms and votes on the winning block body. If it passes, the block is generated. If the packer intentionally does not provide the block body, it is considered that the block does not exist.

• Significance:

• First, the packer has more power to pack transactions. However, as mentioned above, the crList restricts its ability to temporarily insert transactions. Second, if the packer wants to profit by changing the order of transactions, they need to pay a high bidding cost at the beginning to ensure their eligibility for block headers. This further reduces the MEV profit they can obtain, affecting both the means and actual value of their MEV acquisition.

• However, in the early stages, only a small number of people may become packers (considering node performance issues), while most people become proposers. This may lead to further centralization. Meanwhile, when the number of packers is already small, experienced miners with MEV capabilities are more likely to succeed in bidding, which will further affect the effectiveness of MEV resolution in practice.

• It has a certain impact on MEV solutions that use MEV auction.

• Significance:

• EIP 4844 is actually a super simplified version of Danksharding: It provides an application interface similar to Danksharding, including a new opcode called Data Hash; and a new data object called Binary Large Objects, which is Blob.

• proto-danksharding is a “scaffold” proposal for implementing the complete Danksharding specification (i.e., transaction format and validation rules): However, no sharding has been implemented at present, and all validators and users still need to directly verify the availability of the complete data.

• Why choose proto-danksharding in the long term instead of directly reducing fees for layer2 through EIP 4488, because this way only requires slight adjustments when upgrading to complete sharding:

• The main practical difference between EIP-4488 and proto-danksharding is that EIP-4488 attempts to minimize the changes needed for Ethereum today, while proto-danksharding makes more changes to Ethereum today so that it requires fewer changes when upgrading to the complete version of sharding in the future.

• Although implementing complete sharding (with data availability sampling, etc.) is a complex task, and there is still complex work to be done after implementing proto-danksharding, all these complexities will be controlled at the consensus layer. Once proto-danksharding is deployed, execution layer client teams, rollup developers, and users do not need to do any additional work when transitioning to complete sharding.

• To implement complete sharding, it is necessary to complete the actual implementation of PBS, delegation proof, and data availability sampling, but such modifications will be focused on the CL layer and do not require developers to make further adjustments: Currently, 4844 has implemented a new transaction type that is identical to the transaction format, consensus cross-verification logic, and execution layer logic required for complete sharding. It has also derived independent gas pricing for blobs that self-adjusts. In the future, to achieve complete sharding, 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 modifications by EL layer or rollup developers, which is convenient for developers.

Next is SELFDESTRUCT removal, EIP-6780 was finally determined to be the most suitable solution, but in the developer meeting on the 26th, tim proposed to add another opcode SETCODE to this proposal to allow programmable accounts to still be updated.

SELFDESTRUCT Removal EIP-6780: X

• Background:

• In March 21, Vitalik proposed that SELFDESTRUCT is more harmful than beneficial to the Ethereum ecosystem. The main reason is that it is the only opcode that can change an unlimited number of state objects in a single block, causing changes in contract code and modifying account balances without the account’s consent, posing a significant security risk to Ethereum.

• The only way to remove a contract on-chain is through SELFDESTRUCT. If the selfdestruct function is called inside a contract, the contract will self-destruct. The Ether held in the contract will be sent to a pre-designated address. The remaining code and storage variables will be removed from the state machine. In theory, contract destruction sounds like a good idea, but it is actually very dangerous. Although the selfdestruct function can help developers delete smart contracts and transfer the contract’s balance to a specified address in emergency situations, this feature has also been exploited by malicious actors, making it a means of attack.

• In the core developer meeting on April 13, 23, four proposals related to SELFDESTRUCT were discussed, namely 6780, 4758, 6046, and 6190. Subsequently, EIP 6780 was designated as the final proposal.

• Introduction: selfdestruct is the emergency button of a smart contract that destroys the contract and transfers the remaining ETH to a specified account.

• EIP 6780: Disable SELFDESTRUCT unless used in the same transaction as other operations in the contract.

• Update: On May 26, Tim proposed to add another opcode called SETCODE in addition to removing SELFDESTRUCT, allowing programmable accounts to still be updated. This means that the properties inside the smart contract can be updated/upgraded through updates, taking advantage of EIP 4758, which allows dapps to have upgradeability.

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

• Change: This EIP implements the change of removing SELFDESTRUCT, except in the following two cases:

• Applications that only use SELFDESTRUCT to recover funds can still use it;

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

• Significance: Improved security

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

• Prevent users from continuing to deposit and trade funds into a vault after SELFDESTRUCT, which may result in anyone being able to steal tokens from the vault through repeated exploitation.

The following three proposals are related to the deletion ofSELFDESTRUCTin subsequent proposals, officially selected at the core developers meeting on April 28, 20236780, and the remaining three proposals are abandoned. The reason is that the Ethereum development team ultimately wants to completely remove theSELFDESTRUCTopcode, while the following three proposals are more about fixing it through replacement.

• EIP-4758(Deprecated): Disables SELFDESTRUCT by changing it to SENDALL, which allows all funds in the account to be sent back to the caller (sending all ether in the account to the caller), but does not delete any code or storage.

• Reason: Same as above, the original SELFDESTRUCT opcode required extensive changes to the account state, such as deleting all code and storage. This poses difficulties for future use of Verkle trees: each account will be stored in many different account keys that are not explicitly linked to the root account.

• Change:

• Rename the SELFDESTRUCT opcode to SENDALL, which now only moves all ETH in the account to the caller. This scheme no longer destroys code and storage or changes the nonce;

• All refund SELFDESTRUCT related has been deleted

• Significance:

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

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

• Reason: Same as above, with Verkle trees, accounts will be organized differently: account attributes (including storage) will have separate keys, but it is not possible to traverse and find all used keys. The original SELFDESTRUCT opcode required extensive changes to the account state, making it very difficult to continue using SELFDESTRUCT in Verkle trees.

• Change:

• Change the rule introduced by EIP-2681 to constrain regular nonces to 2^64-2 instead of 2^64-1;

• SELFDESTRUCT is changed to:

• Do not delete any storage keys and keep 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 refund since EIP-3529;

• Related rules of EIP-2929 remain unchanged for SELFDESTRUCT.

• Significance:

• This proposal has more flexibility compared to directly deleting the SELFDESTRUCT behavior.

• EIP-6190 (deprecated): Change SELFDESTRUCT to be compatible with Verkle, causing limited state changes.

• Reason: Same as above, using Verkle tree, accounts will be organized differently: account attributes (including storage) will have separate keys, but it is not possible to traverse and find all the used keys. The original operation of the SELFDESTRUCT code requires a large number of changes to the account state, making it extremely difficult to continue using SELFDESTRUCT in the Verkle tree.

• Change: Instead of destroying the contract at the end of the transaction, the following will happen at the end of the transaction that calls 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 address that will be deployed when the CREATE opcode (keccak256(contractAddress, nonce)) is used. The random number is always 2^64-1.

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

• The balance of the contract is transferred to the address at the top of the stack;

• The top of the stack is popped.

• Significance:

• Intends to allow SELFDESTRUCT to form Verkle trees subsequently with minimal changes;

• Applies the gas cost increase from EIP-2929.

Next is EIP 1153, paving the way for future storage design while saving gas

EIP 1153X

• Introduction: Transient storage opcodes, adding opcodes to operate on a state that is the same as storage behavior but discarded after each transaction.

• Reason:

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

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

• Take reentrancy lock as an example, it cannot rely on intermediate frames to pass the lock state: communication through storage using SSTORE and SLOAD is expensive, while transient storage is a dedicated and gas-efficient solution to solve inter-frame communication issues.

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

• Instant storage is private for the contract that owns it, just like persistent storage. Only the contract framework can access its temporary storage. When accessing storage, all frames access the same temporary storage in the same way as persistent storage, but different from memory.

• Potential use cases:

• Reentrancy lock;

• On-chain computable CREATE2 address: Constructor parameters are read from the factory contract instead of being passed as part of the initialization code hash;

• Single transaction EIP-20 approval, for example #temporaryApprove(address spender, uint256 amount);

• Transfer fee contract: Paying fees to the token contract to unlock transfers during the transaction;

• “Till” pattern: Allows users to perform all operations as part of a callback and check whether the “till” is balanced at the end;

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

• Significance:

• Save gas, have simpler gas billing rules;

• Solve inter-frame communication problems;

• Do not change the semantics of existing operations;

• No need to clear storage slots after use;

• Future storage designs (e.g. Verkle tree) do not need to consider refunding of temporary storage.

Next is 4788, which reduces trust assumptions on the staking pool

EIP 4788: X

• Introduction: Beacon block root in the EVM.

• Update: In the developer meeting on June 15, 23, developers proposed code changes to improve the staker experience. This EIP exposes the root of the beacon chain blocks, which contains internal chain state information of the EVM, for minimal trust access by DApp developers.

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

• Significance: This is a code modification proposal that proposes modifying the Ethereum Virtual Machine (EVM) to enable the exposure of contract layer (CL) state roots to the execution layer (EL) data, which can make communication between different protocols and applications in the Ethereum network more efficient and secure. It allows staking pools, bridging, and restaking protocols to have more trustless designs.

Finally5656 provides a new efficient memory copy opcode, but considering its testing bandwidth, it is currently temporarily included in the upgrade.

EIP 5656X

• Introduction: MCOPY – Memory copy instruction.

• Update: On June 9, 23, the development team stated that there were initial disagreements about MCOPY because although it addressed security issues, there were still concerns about adding it to the upgrade due to implementation + testing bandwidth required. However, they ultimately agreed to include the EIP, but if developers encounter capacity issues during testing or client, they will consider removing it. Therefore, MCOPY is currently temporarily included in the Cancun upgrade.

• Change: Provides an efficient EVM instruction for copying memory regions.

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

• With the availability of the MCOPY instruction, it is possible to copy code words more accurately, which will improve memory copy performance by about 10.5%, which is very useful for various computationally intensive operations;

• It will also be helpful for the compiler to generate more efficient and smaller bytecode;

• It can save certain gas fees for identity pre-compilation, but it cannot actually promote the implementation 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 EIP 6988, EIP 7044, and EIP 7045 were proposed to be included.

EIP 6988: X

• Introduction: Preventing penalized validators from being selected as block proposers.

• Significance: Increases the penalty for violating nodes, which will benefit DVT.

EIP 7044: X

• Introduction: Ensuring that the signature of the validator remains valid permanently.

• Significance: Can improve the experience of stakers to some extent.

EIP 7045: X

• Introduction: Extends the attestation slot inclusion window from one epoch to two epochs.

• Significance: Enhances network security.

Analysis of Removing 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 routine upgrades.

EVMMAX EIPs:

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

• EIP 6601: EVM Modular Arithmetic Extension (EVMMAX)

• Changes: It is an iteration of EIP 5843, with the following differences compared to EIP 5843:

• EIP 6601 introduces a new EOF section type, which stores the modulus, precomputed Montgomery parameters, and the number of values to be used (still supporting runtime configurable modulus);

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

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

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

• Enables elliptic curve arithmetic operations on various curves (including BLS12-381) in EVM contracts;

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

• Allows implementing modexp as a precompiled function in EVM contracts;

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

• EIP 6690:

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

• Significance: It retains the core functionality of EIP-6601, which enables 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.

EOF changes:

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

• EIP 663:

• Introduction: Unrestricted SWAP and DUP instructions

• Significance: By introducing two new instructions, SWAPN and DUPN, which differ from SWAP and DUP in that the stack depth increases from 16 elements to 256 elements

• EIP 3540:

• Introduction: EVM bytecode deployed on previous chains does not have a pre-defined uniform structure. The code is only verified before being executed in the client, which is both an indirect cost and a hindrance to developers introducing new features or deprecating old ones.

• This EIP introduces a container that can be extended and version controlled for the EVM, and declares the format of EOF contracts. Based on this, code validation can be performed when deploying EOF contracts, known as creation time validation, which means that contracts that do not comply with the EOF format can be prevented from being deployed. This change achieves EOF version control, which will help in the future deprecation of existing EVM instructions or introduction of large-scale features (such as account abstraction).

• Significance:

• Version control facilitates the introduction or deprecation of new features (e.g., introducing account abstraction).

• The separation of contract code and data is beneficial for L2 verification (op), reducing the gas cost for L2 validators. Additionally, the separation of contract code and data also facilitates the work of on-chain data analysis tools.

• EIP 3670:

• Introduction: Based on EIP-3540, the goal is to ensure that the code of EOF contracts is valid according to the format and prevent the deployment of contracts that do not comply with the format, without affecting Legacy bytecode.

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

• EIP 4200:

• Introduction: Introduces 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 gas costs during deployment and execution of JUMPs, as they eliminate the need for runtime jumpdest analysis required by existing JUMP and JUMPI opcodes. This EIP is a supplement to dynamic jumps.

• Unlike traditional JUMP operations, RJUMP and other operations do not specify a specific offset position, but rather specify a relative offset position (from dynamic jumps to static jumps), as static jumps are often sufficient.

• Significance: Optimize network and reduce costs.

• EIP 4750:

• Takes the functionality of 4200 further: By introducing two new opcodes, CALLF and RETF, it provides an alternative solution for cases where RJUMP, RJUMPI, and RJUMPV cannot be replaced, thus eliminating the need for JUMPDEST in EOF contracts and thereby disallowing dynamic jumps.

• Significance: Optimizes code by dividing it into several parts.

• EIP 5450:

• Background: Currently, Ethereum contracts are not checked during deployment and various checks, such as stack overflow (limit 1024) and sufficient gas, are only performed during runtime.

• Content: Adds another validity check for EOF contracts, this time focusing on the stack. This EIP prevents stack underflows or overflows that could occur during deployment of EOF contracts. As a result, clients can reduce the number of validity checks performed during execution of EOF contracts.

• Significance: One major improvement is to minimize the checks performed during execution and perform more checks during contract deployment.

After the developer meeting update on May 26, changes related to EIP 4844 from SSZ to RLP in transaction types mean that the two SSZ EIPs in Cancun upgrade are no longer needed, thus EIPs 6475 and 6493 have been removed from the Cancun upgrade.

EIP 6475:

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

• Update: During the 161st Ethereum execution layer core developer meeting, discussions about the SSZ serialization format for EIP 4844 showed that initially developers were inclined to introduce SSZ format early on through blob transactions to the EL. Eventually, the plan was to upgrade all transaction types from RLP to SSZ, but due to the unclear path and the impossibility of implementing it in the Cancun upgrade, developers have been considering removing SSZ from EIP-4844. After multiple discussions, developers agreed to remove SSZ from the EL implementation of EIP-4844, but there has been no action to remove EIP 6475 as of now. After the update on May 26, the change from SSZ to RLP means that the two SSZ EIPs in Cancun are no longer needed, so EIPs 6475 and 6493 will be removed from the Cancun upgrade.

EIP 6493 X

• Introduction: SSZ transaction signing scheme. This EIP defines a signing scheme for serialized (SSZ) encoded transactions, addressing how nodes should handle blob transaction types that are formatted in SSZ but encoded differently in EL. This EIP is part of the update to the Ethereum serialization format to achieve cross-layer consistency;

• Background: SSZ changes

• Introduction: Simple SerialiZe, a serialization method used in the beacon chain.

• SSZ changes also include three other complementary proposals, only EIP 6465 is introduced this time.

• EIP 6465: SSZ withdrawal root, defines the migration process for existing Merkle-Patricia Trie (MPT) commitments to Simple SerialiZe (SSZ) withdrawals;

• EIP 6404 / EIP 6466:

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

• EIP-6404 – SSZ transaction root

• EIP-6466 – SSZ receipt root

Tim Beiko suggested in the Core Developer Meeting on May 26th that future discussions around expanding the scope of Cancun be limited to the following five EIPs: EIP 5920, 5656, 7069, 4788, and 2537. Subsequent proposals will be generated within this range. Subsequent EIP 5656 and EIP 4788 have been confirmed as formal upgrade proposals, while EIP 5920, 7069, and 2537 have been removed. EIP 5920 was removed due to developer concerns about potential side effects of the ETH transfer method, as well as incomplete reasoning, testing, and security work.

EIP 5920: X

• Introduction: Payment opcode. Introduces a new opcode LianGuaiY for transferring Ether on Ethereum without calling any functions on the recipient address.

• Reason: Currently, sending Ether to an address requires the user to call a function on that address, which has several issues:

• Firstly, it opens up a vector for reentrancy attacks, as the recipient can callback to the sender;

• Secondly, it opens up a DoS vector, so the parent function must be aware that the recipient might exhaust gas or callback;

• Lastly, the CALL opcode is unnecessarily expensive for simple Ether transfers as it requires expanding memory and stack, loading the recipient’s entire data including code and memory, and finally executing a call that may do other unintended actions.

• Change:

• Introduced a new opcode: (LianGuaiY) LianGuaiY_OPCODE, where:

• Pop two values from the stack: addr and val.

• Transfer wei from the execution address to the address addr, with the value val. If addr is the zero address, the val wei will be burned from the execution address.

• Potential risk: Existing contracts can be used without relying on the actual balance of their wallets, as Ether can now be sent to an address without calling it.

• Significance: Save gas.

• Update: On June 9, 2023, LianGuaiY was removed from the upgrade due to concerns about potential side effects of transferring ETH, as well as the reasoning, testing, and security work required by the proposal.

EIP 7069X

• Introduction: Modified CALL instruction

• Change: Introduce three new call instructions, CALL2, DELEGATECALL2, and STATICCALL2, with simplified semantics. The aim is to remove gas observability from the new instructions and open the door for new types of contracts that are not affected by repricing.

• Background:

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

• Before the introduction of the 63/64th rule, it was necessary to calculate the available gas for the calling party with some accuracy. Solidity has a complex rule that attempts to estimate the cost of the calling party’s execution of the call itself in order to set a reasonable gas value.

• Currently introducing the 63/64th rule:

• Removed call depth check;

• Ensure at least 5000 gas is reserved before executing the callee;

• Ensure at least 2300 gas is available for the callee.

• Allowance rule: The well-known 2300 allowance, when one contract calls another contract, the callee contract receives 2300 gas for performing very limited operations (enough for some calculations and generating a log, but not enough to fill a storage slot). Since it sets a fixed amount of gas, people have no way of determining what types of calculations these gas can support as long as the gas price can be adjusted.

• Significance: Paving the way for the future introduction of EOF (End of File), while also making the operation of large contracts more convenient.

• Removal of gas optionality: The new instructions do not allow specifying a gas limit and instead rely on the “63/64th rule” (primarily referring to the Gas repricing used for a large number of IO operations in EIP-150) to limit gas. This important improvement simplifies the rules around allowances, and callers no longer need to perform gas calculations regardless of whether the value is sent or not.

• After introducing a new proposal, users can always overcome the “Out of Gas” error by sending more gas in transactions (of course, subject to block gas limits).

• Previously, when increasing storage costs (such as increasing gas for certain opcodes in EIP-1884), some contracts that only sent a limited amount of gas to their calls were broken by the new cost accounting mechanism. Previously, some contracts had a gas limit that permanently restricted the amount of gas they could spend, even if they sent it to their sub-calls. No matter how much extra gas was sent, it could not be resolved because the call would limit the amount sent.

• To pave the way for the introduction of EOF: Once the EVM Object Format (EOF) is introduced, old call instructions can be rejected in EOF contracts, ensuring that they are not significantly affected by gas price changes. Since these operations are necessary to eliminate gas observability, EOF will need to replace them with existing instructions.

• More convenient state return codes: A convenient feature is introduced to return more detailed state codes: success (0), revert (1), failure (2), and can be expanded in the future.

EIP 2537: X

• Introduction: Precompiled operations for BLS12-381 curve operations.

• Changes: Add operations on the BLS12-381 curve as precompiled contracts to the set required for effective execution of BLS signature verification and execution of SNARKs verification.

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

PR 3175 was mentioned but not included in the candidate list, and there was no further discussion.

PR 3175: X

• Introduction: This proposal will prevent penalized validators from proposing blocks when they exit the queue. If more than 50% of validators are penalized for malicious behavior, they can still propose blocks while being forcibly expelled from the network. Developers say that changing this logic is a relatively minor CL layer change that can provide protection against “high failure modes”.

• According to the 108th Ethereum Core Developers’ Consensus Meeting on May 4th, PR 3175 is in the process of being formatted as EIP and will be changed to EIP-6987, which is to prevent slashed validators from being selected as block proposers for security reasons.

Future

Based on the above information, we draw the following conclusions:

1. The main goals of the Cancun upgrade are prioritized as follows: scalability, security, gas efficiency, and interoperability:

• Scalability is undoubtedly the first priority (4844);

• Safety and gas savings are secondary priorities (6780, 1153, 5656, and 7045), while also considering developer experience;

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

• Expected data: testnet 4844 can reduce the cost of opside rollup by 50%; the technical solutions for EigenLayer and Celestia have not been disclosed enough to evaluate their data; Ethstorage estimates that DA costs will be reduced to 5% of the original; Topia expects to reduce costs by 100 to 1000 times.

2. The Future of Cancun Upgrade to Danksharding: The Golden Development Period of DA Layer Projects in 2-5 Years

• The security ceiling of Layer 2 depends on the DA layer it adopts. Proto-Danksharding benefits storage protocols, modular protocols, and L1 storage extension networks through cheaper state data storage.

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

• Second, Danksharding reduces DA costs, but the actual implementation time and data availability issues also need to be resolved.

• Reduced DA costs: Before this update, calling calldata to publish data from rollup to the Ethereum main chain was very expensive in terms of gas fees, which was the largest expenditure in Layer 2. EIP 4844 introduces data blobs as unique additional data space for rollups, greatly reducing storage costs and thereby reducing DA costs.

• The actual implementation time is long, and the potential improvements in TPS and reductions in gas are limited, so it is beneficial for DA layer projects to continue their development:

• In the article on danksharding’s Variable Security Data Sharding in Polynya, it is indicated that it will take 2-5 years for it to be implemented;

• Even if implemented, the potential improvements in TPS and reductions in gas are still limited:

• EIP 4844 currently supports 6 Blobs, and the future expansion issue relies on Danksharding to solve;

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

• Therefore, projects at the DA layer, such as Celestia and Eigenda, can still compete with Danksharding in the future through lower costs and faster TPS, benefiting from a long landing time + limited actual change. New DA projects like ETHstorage topia can also fill the market gap before landing.

• Technical problems, such as data storage and data availability, also need to be solved:

• The main costs of DA are network bandwidth and storage. EIP 4844 itself does not solve storage and on-chain bandwidth issues.

• The Blob will be deleted from the Ethereum consensus layer after about 3 weeks. Currently, the solutions to achieve complete storage of historical records and full data availability include: dapps storing their own relevant data, Ethereum portal networks (currently under development), or third-party protocols such as block explorers, storing historical data or personal user’s spontaneous storage in BitTorrent.

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

• The demand for accessing historical data will create a new development channel for decentralized storage protocols or third-party indexing protocols;

• Subsequent modular protocols can use high-speed Rollup for transaction execution, with a secure settlement layer responsible for settlement, and a low-cost, high-capacity data availability layer responsible for guaranteeing data availability;

• L1 storage expansion networks, such as Eth storage, will benefit from lower storage costs and provide second-layer solutions for programmable storage.

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

• L2 track analysis:

• Top Layer2 projects such as Arbitrum Orbit, OP Stack, Polygon2.0, Fractal Scaling (under StarkWare), and HyperChain (under zkSync) will benefit. The storage cost reduction brought by Blobs will greatly improve the cost and scalability issues that previously limited the development of Layer 2, greatly enhancing data throughput. After solving the cost issue, top Layer 2 projects will have the opportunity to continue deploying highly customizable multi-chain concurrent L3 ecosystems for specific functions;

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

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

• Raas track analysis:

• The advantage of Raas lies in its high customization, where customized needs > pure cost and efficiency, so the reduction in fees is a larger benefit for customized Rollups.

• However, the problem with the RAAS track is that it may be overhyped, and there are even doubts about the RAAS track itself. Faced with the competition from the top 5 Layer2, the emergence of various new DAs, we have to question whether new projects can form a track.

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

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

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

• ZK series: Currently, more leading projects choose the ZKEVM route, pay more attention to compatibility with Ethereum, so circuit design will sacrifice certain efficiency and is not as targeted as the OP series. However, most of the ZK RAAS 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, OP RAAS still has some development space before layer3 is implemented, and in the long term, 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 its cost of uploading to L1 is less than OP, this is only a drop in the bucket compared to the cost of the proof process, while OP’s advantage lies in its ability to quickly build an ecosystem in the short term, and it still has some development space before layer3 is implemented;

• For conventional defi applications, NFT markets, transitioning to rollups is not a strict requirement. Rollups are only more necessary for payment applications or games that require high efficiency. In the future, defi projects may be on layer 2, social activities may be on layer 3 or off-chain, and core data and relationships will be placed on layer 2. Gaming projects may have a demand for layer 3 or rollups, but considering that most blockchain games are essentially financial pyramids and tokens cannot circulate externally, this brings development bottlenecks. In addition, the emergence of fully on-chain games, the ecological attractiveness of layer 3 itself is far greater than rollups.

4. Cancun upgrade improves developer and user experience

• The second important proposal of the Cancun upgrade, SELFDESTRUCT removal, will further improve the security of Ethereum. It also prepares to introduce a new opcode SETCODE to address the potential programmatic account update issue after deletion.

• The third proposal of the Cancun upgrade, EIP 1153, adds transient storage opcodes. Firstly, it can save gas fees, secondly, it can solve inter-frame communication issues, and finally, it paves the way for future storage designs. For example, Verkle tree will not need to consider the refund issue of transient storage.

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

• The fifth proposal of the Cancun upgrade, EIP 4788, can make communication between different protocols and applications in the Ethereum network more efficient and secure. It also allows staking pools, bridging, and restaking protocols to have more trustless designs.

• The latest (June 15, 2023) proposal added to the CL-centered EIP upgrade for the Cancun upgrade includes: EIP 6988, EIP 7044, EIP 7045, which respectively improve the security and usability of Ethereum in terms of details, such as improving the staker experience and enhancing network security.

• In the deleted proposals, the transition from SSZ to RLP resulted in the removal of two SSZ EIPs (EIP 6475 and EIP 6493) 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 they may be implemented directly in later routine upgrades. EVMMAX, because it is a subset of EIPs related to EOF implementation, was also removed from the Cancun upgrade along with EOF. Considering the potential side effects of transferring ETH and the reasoning, testing, and security work required through proposals, EIP 5920 was removed from the upgrade.

5. Relationship with zkML and account abstraction

Has little impact on zkML.

• ZKML refers to the combination of Zero Knowledge Proof and Machine Learning. The combination of blockchain and ML solves the privacy protection and verifiability issues of machine learning:

• Privacy protection: Confidentiality of input data is important. For example, when using a large amount of personal information as data for machine training, the confidentiality of personal information is a major requirement. Or when model parameters are the core competitiveness of a project, encryption is needed to maintain competitive advantage. When trust issues like these exist, ML models may face obstacles in obtaining larger-scale data and applications.

• Verifiability: Zero Knowledge Proof technology has a wide range of applications. ZKP allows users to know the correctness of information without the need for verification. And because machine learning models require a large amount of computation, ML models can generate proofs through ZK-SNARKs, reducing proof size and alleviating the computational power requirements of ML.

• The storage requirements and DA relationship of ZKML are not significant: A separate storage structure like SLianGuaice and Time is needed, and its core technology is the “SQL Proof” new security protocol. In simple terms, it is a data warehouse located beside the blockchain, which allows developers to connect on-chain and off-chain data in a simple SQL format and directly load the results into smart contracts.

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

• ZK-SNARKs have the characteristic of high compactness. Using ZK-SNARKs, the prover can generate a short proof, and the verifier only needs to perform a small amount of computation to verify its validity without interaction. This property of requiring only one interaction between the prover and verifier makes ZK-SNARKs efficient and practical in practical applications, and more suitable for the on-chain computational power requirements of ML.

• Currently, on-chain training is not possible. On-chain can only store the results of off-chain computations:

• The current issues with ML are mainly the inability to meet computational power requirements and algorithm limitations (inability to perform parallel computations), resulting in low performance. Large-scale ZK proofs require higher computational power, which is not supported on-chain. The popular ZK-SNARKs also only support small-scale and low computational ML zero-knowledge proofs. Therefore, the limited computational power is a key factor affecting the development of ZKML blockchain applications. On-chain can only store the results of off-chain computations.

Positive impact of account abstraction:

• Firstly, the upgrade of Cancun can reduce the cost of ZK rollup proofs to some extent.

• The current transaction fees of zkSync depend on three aspects:

• The fixed resource cost for validators to generate SNARK proofs and perform verification, which is relatively high;

• The gas fee for validators to submit SNARK proofs to the Ethereum mainnet, which will increase correspondingly due to congestion;

• The service fees paid by users to validators, including transaction confirmation and message broadcasting.

• Therefore, the introduction of 4844 will alleviate the problem of increased gas fees caused by congestion on the mainnet, reduce the cost of ZKP proofs to a certain extent. Although the cost is not much compared to the cost of generating proofs, it should not be underestimated considering that ZK is still in its early stage and its future development trend is significant.

• Secondly, account abstraction transforms traditional tx transactions into useroperations, which are then packed into blocks using ECDSA. This results in more on-chain storage occupation compared to before, so higher storage requirements are needed;

• Furthermore, account abstraction and ZK rollup can complement each other:

• Currently, the problem with account abstraction is that Gas Fee is expensive due to the multiple steps involved, which also involves smart contracts and leads to more data, resulting in high Gas Fees. The advantage of ZK Rollup lies in its ability to reduce data;

• Account abstraction makes it difficult to guarantee security: as AA involves multiple contracts, security is a concern. However, after L2 gradually takes shape in the future, the consensus layer will no longer be modified, and smart contracts will have more room to play, thereby ensuring the security of account abstraction. With the trusted verification of ZK rollup, security will be greatly enhanced.

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

• AI 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, fraudulent behavior, and data leaks, and provides real-time monitoring and alert mechanisms to ensure the security and stability of on-chain transactions;

• AI and optimization of 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, improving overall efficiency and performance. AI can help identify transaction patterns, detect abnormal activities, and provide real-time recommendations to optimize the allocation of resources in the blockchain network through data analysis and model training.

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

6. What’s next on the Ethereum roadmap?

• Currently, Layer2 does not have the performance similar to Solana in terms of latency and throughput, nor the shard performance like Near, nor the parallel execution performance like Sui and Aptos. The Cancun upgrade enhances Ethereum’s leading position as a leader.

• After the Cancun upgrade, the estimated major development times are Fully-Danksharding (2-5 years), MEV and PBS implementation (1-3 years), account abstraction (1-2 years), ZK everything (3-6 years), EOF, and developer experience (subject to multiple delays?).

The Scourge

• Objective: Focus on solving MEV issues.

• Solution: Use “Proposer-Builder Separation (PBS)” to minimize MEV at the application layer. This may optimize blob and introduce pre-confirmation services or front-running protection.

• PBS separates block producers from sorters. Sorters are only responsible for sorting and do not handle on-chain transactions, while block producers do not handle transactions and directly select sorters’ sorted packages for on-chain inclusion. This process makes the whole process more fair and alleviates MEV issues, externalizing MEV.

• PBS is still at a relatively low level of completion. A more mature external MEV solution is the collaboration between flashbots and mevboost.

• A more advanced version of “Enshrined Proposer-Builder SeLianGuairation (ePBS)” has lower completion and longer cycles. It is estimated that it will not be implemented in the short term. There are also incremental versions of PEPC and Optimistic Relaying, which enhance the flexibility and adaptability of the PBS framework.

The Verge

• Objective: Use Verkel tree to replace Merkle and introduce a trust-minimized solution, allowing lightweight nodes to have the same security guarantee as full nodes, making block validation as simple and lightweight as possible.

• At the same time, the ZK transformation of L1 is explicitly included in the Verge roadmap. ZK will be the future trend of scalability and acceleration.

• Solution: Introduce zk-SNARKs to replace the old proof system, including SNARK-based lightweight clients; SNARKs for consensus state changes; Enshrined Rollups.

• Verkle tree is a more efficient alternative to Merkle tree specifically designed for states. It does not require providing the path from each sibling node (nodes sharing the same parent node) to the selected node, but only provides the path itself as part of the proof. Verkle proof is 3 times more efficient than Merkle proof.

• Enshrined Rollup refers to a Rollup that has some kind of consensus integration on L1. The advantage is inheriting the consensus of L1 without the need for governance tokens to execute rollup upgrades. By performing computations off-chain and only publishing the results to the blockchain, it can increase the number of transactions. However, the implementation difficulty is high. In the future, these rollups combined together will be able to meet most of the needs in the blockchain ecosystem for the next few decades.

The Purge

• The Purge refers to simplifying the protocol by reducing the storage requirements for participating in the validation network. This is mainly achieved by hibernating and managing history and state. History data hibernation (EIP-4444) allows clients to prune historical data older than one year and stop providing services at the P2P level.

• State hibernation. When it comes to dealing with state growth, there are two main goals: weak statelessness, which means using the state only to build blocks without verifying it; state hibernation, which means deleting states that have not been accessed within a specified time (1 year). State hibernation should reduce the total amount of state that nodes need to store by 20-50 GB.

• In the fifth phase of the Purge, EIP 4444 is explicitly written into the Roadmap. EIP-4444 requires clients to clear data older than one year. This phase also involves some EVM optimizations, such as simplifying GAS mechanisms and EVM precompiles.

The Splurge

• In the final phase, Splurge, EIP 4337 is also mentioned as a long-term layout proposal for the wallet ecosystem. Account abstraction will further improve the usability of wallets, including paying gas with stablecoins, social recovery wallets, etc.

References:

• Ethereum Core Developers Meeting Updates: https://www.galaxy.com/authors/christine-kim/

• Ethereum All Core Developers Call #148 Writeuphttps://www.galaxy.com/research/insights/ethereum-all-core-developers-call-148/

• Ethereum All Core Developers Call #149 Writeuphttps://www.galaxy.com/research/insights/ethereum-all-core-developers-call-149/

• Ethereum Consensus Layer Call #99 Writeuphttps://www.galaxy.com/research/insights/ethereum-consensus-layer-call-99-writeup/

• Ethereum
  All Core Developers Call #150
  Writeup: https://www.galaxy.com/research/insights/ethereum-all-core-developers-call-150-writeup/

• Ethereum
  All Core Developers Call #151
  Writeup: https://www.galaxy.com/research/insights/ethereum-all-core-developers-call-151/

• Ethereum
  Consensus Layer Call #100
  Writeup: https://www.galaxy.com/research/insights/ethereum-consensus-layer-call-100/

• Ethereum
  All Core Developers Execution Call #152
  Writeup: https://www.galaxy.com/research/insights/ethereum-all-core-developers-execution-call-152/

• Ethereum
  All Core Developers Execution Call #153
  Writeup: https://www.galaxy.com/research/insights/ethereum-all-core-developers-execution-call-153/

• Ethereum
  Magicians Forum discussion original post: https://ethereum-magicians.org/t/cancun-network-upgrade-meta-thread/12060

• Ethereum
  All Core Developers Execution Call #156
  Writeup: https://www.galaxy.com/research/insights/ethereum-all-core-developers-execution-call-156/

• Ethereum
  All Core Developers Execution Call #157
  Writeup: https://www.galaxy.com/research/insights/ethereum-all-core-developers-execution-call-157/

• Ethereum
  All Core Developers Execution Call #158
  Writeup: https://www.galaxy.com/research/insights/ethereum-all-core-developers-execution-call-158/

• Ethereum
  All Core Developers Execution Call #159
  Writeup: https://www.galaxy.com/research/insights/ethereum-all-core-developers-execution-call-159/

• Ethereum
  All Core Developers Execution Call #160
  Writeup: https://www.galaxy.com/research/insights/ethereum-all-core-developers-execution-call-160/

• Ethereum
  All Core Developers Consensus Call #108
  Writeup: https://www.galaxy.com/research/insights/ethereum-all-core-developers-consensus-call-108/

• Ethereum
  All Core Developers Execution Call #161
  Writeup: https://www.galaxy.com/research/insights/ethereum-all-core-developers-execution-call-161/

• Ethereum
  All Core Developers Consensus Call #109
  Writeup: https://www.galaxy.com/research/insights/ethereum-all-core-developers-consensus-call-109/

• Ethereum
  All Core Developers Execution Call #162
  Writeup: https://www.galaxy.com/research/insights/ethereum-all-core-developers-execution-call-162/

• Ethereum
  All Core Developers Consensus Call #110
  Writeup: https://www.galaxy.com/research/insights/ethereum-all-core-developers-consensus-call-110/

• Tim Tweet regarding the latest Ethereum Cancun Upgrade (June 9, 2023): https://twitter.com/TimBeiko/status/1666908046994608128

• Ethereum
  All Core Developers Consensus Call #111
  Writeup: https://www.galaxy.com/research/insights/ethereum-all-core-developers-consensus-call-111/

• Ethereum
  All Core Developers Consensus Call #112
  Writeup: https://www.galaxy.com/research/insights/ethereum-all-core-developers-consensus-call-112/

• Ethereum
  Upgrade-related content:

• Introduction to self-destructing code: https://www.wtf.academy/solidity-advanced/DeleteContract/

• Exploring EVMMAX proposals and BLS12-381: https://etherworld.co/2023/03/27/exploring-evmmax-proposals-bls12-381/

• In addition to EIP-4844, what other content will be included in the Cancun upgrade? Ethereum’s latest consensus conference at a glance: https://www.fx168news.com/article/193393

• What new content has been added to the Shanghai upgrade of Ethereum? https://foresightnews.pro/article/detail/21520

• Tweet: https://twitter.com/xiangganzi/status/1588367511577194496

• OKX Ventures: Potential investment opportunities in the Cancun upgrade after the Shanghai upgrade of Ethereum – Foresight News

• In addition to the highly anticipated EIP-4844, what other proposals will the Cancun upgrade include? https://www.panewslab.com/zh/articledetails/4qlg59ty.html

• Vitalik: EVM functions worth considering for deletion: https://www.jinse.com/blockchain/1020439.html

• Proto-Danksharding FAQ: https://notes.ethereum.org/@vbuterin/proto_danksharding_faq#What-is-Danksharding

• Vitalik’s recommendation: Understanding Ethereum’s shard roadmap in depth, this report is enough: https://www.8btc.com/article/6755560

• Understanding Ethereum’s new upgrade plan Danksharding in one article: https://mirror.xyz/mtyl.eth/TbLbRI1VcDZYxkHJOBhB319oaYxnV5_DmqXl6xLfcWM

• Interpreting interesting facts and hidden passwords in Ethereum’s latest roadmap: https://web3caff.com/zh/archives/40114

• Vitalik: Why SELFDESTRUCT is more harmful than beneficial to Ethereum’s ecosystem: https://www.8btc.com/article/6610829

• Ethereum Vision: https://ethereum.org/zh/roadmap/vision/

• Blockworks Researcher Brrr: How Proto-Danksharding accelerates Ethereum’s L1 Rollup scalability: https://twitter.com/blockworksres/status/1671604147437834240

• Ethereum ACDC Meeting #111: Discussing the final scope of the Deneb upgrade and three proposals including EIP-7044: https://www.theblockbeats.info/flash/150732

• KOL Stacy Muur’s overview of Ethereum’s scaling solutions evolution: OP Stack, Arbitrum Orbit, Polygon 2.0: https://twitter.com/stacy_muur/status/1674091705300312066

• Comparison of three types of Rollups: Classic Rollups (Optimistic/ZK Rollups), Enshrined Rollups, Sovereign Rollups: https://news.marsbit.co/20230627082034175777.html

• [AMA] We are EF Research (Pt. 8: 07 July, 2022): https://www.reddit.com/r/ethereum/comments/vrx9xe/ama_we_are_ef_research_pt_8_07_july_2022/

• 3 hot tracks worth rethinking in 2023: https://finance.sina.cn/blockchain/2023-04-12/detail-imyqawtq3942364.d.html

• Thoughts after EDCON 2023: Infrastructure and application trends: https://www.techflowpost.com/article/detail_12307.html

• The infinite imagination of combining AI with Web3: https://www.techflowpost.com/article/detail_12169.html

• AI+Web3: Exploring the fusion of artificial intelligence and blockchain: https://www.techflowpost.com/article/detail_12141.html

• Comparing zk-rollup and op-rollup: Analyzing the verification methods to understand why zkSync gas fees are high: https://www.techflowpost.com/article/detail_11778.html

• “Adding Volume”: Account abstraction solution in the era of Rollup: https://www.panewslab.com/zh/articledetails/pbx0zoiw.html

• In-depth analysis of ZKML: Technical principles, application scenarios, advantages, and challenges: https://www.odaily.news/post/5188011

• ZKML: Deploying model deployment technology that combines AI and blockchain to achieve privacy protection: https://www.techflowpost.com/article/detail_12011.html

• Variable security data sharding: https://polynya.mirror.xyz/xJUgtU5mArDwz0MXIyxM_wAYDKy5LianGuairhUfqb2Z24ErI

• Interview with Qi Zhou, founder of EthStorage: Data availability and decentralized storage: https://mp.weixin.qq.com/s/1K8ue0jkER_QuXXsZUNbRw

• Understanding the latest version of Ethereum’s development roadmap in one article: https://foresightnews.pro/article/detail/20815

• A brief introduction to SLianGuaice and Time: https://mirror.xyz/200070.eth/1nzH8lYGrmt7T4ellNou0kKRfQXaKpxBb7D4caIqoLianGuai

• Original proposals:

• EIP 4844: https://eips.ethereum.org/EIPS/eip-4844

• EIP 6780: https://eips.ethereum.org/EIPS/eip-6780

• EIP 1153: https://eips.ethereum.org/EIPS/eip-1153

• EIP 5920: https://eips.ethereum.org/EIPS/eip-5920

• EIP 5656: https://eips.ethereum.org/EIPS/eip-5656

• EIP 7069: https://github.com/ethereum/EIPs/pull/7069

• EIP 4788: https://eips.ethereum.org/EIPS/eip-4788

• EIP 2537: https://eips.ethereum.org/EIPS/eip-2537

• EVMMAX
  EIPs:

• EIP
  6601: https://ethereum-magicians.org/t/eip-6601-evm-modular-arithmetic-extensions-evmmax/13168

• EIP
  6990: https://github.com/jwasinger/EIPs/blob/evmmax-no-eof/EIPS/eip-6690.md

• EOF
  changes:

• EIP
  663: https://eips.ethereum.org/EIPS/eip-663

• EIP
  3540: https://eips.ethereum.org/EIPS/eip-3540

• EIP
  3670: https://eips.ethereum.org/EIPS/eip-3670

• EIP
  4200: https://eips.ethereum.org/EIPS/eip-4200

• EIP
  4750: https://eips.ethereum.org/EIPS/eip-4750

• EIP
  5450: https://eips.ethereum.org/EIPS/eip-5450

• EIP
  6475: https://eips.ethereum.org/EIPS/eip-6475

• EIP
  6493: https://eips.ethereum.org/EIPS/eip-6493

• PR
  3175: https://github.com/ethereum/consensus-specs/pull/3175

We will continue to update Blocking; if you have any questions or suggestions, please contact us!