Ethereum Evolved: Dencun Upgrade Part 1, EIP-5656 & EIP-6780

While each Ethereum upgrade—executed via a “hard fork”—inevitably touches many lanes within Ethereum’s roadmap, they’re typically weighted in a specific direction. For example, the Bellatrix upgrade was primarily designed to transition Ethereum’s consensus from Proof of Work (PoW) to Proof of Stake (PoS), while the recent Shanghai-Capella upgrade mainly targeted enabling validator withdrawals from the Beacon Chain. 

With the upcoming Cancun-Deneb upgrade, there is a clear focus on improving Ethereum scalability through the creation of “data blobs”: a new transaction type intended to scale data availability for Layer 2 (L2) rollups. In addition to blob creation there are also important housekeeping upgrades, two of which we will break down in this post. Later in this series we will detail the more formational EIPs that will structurally change Ethereum. 

Before any of that, however, let’s lay the groundwork for how an Ethereum hard fork (upgrade) is implemented.

Ethereum: A tale of two layers

The Ethereum network is divided into two main layers: the Execution Layer and the Consensus Layer. Prior to the Bellatrix upgrade—often described as “The Merge”—Ethereum’s Consensus Layer and Execution Layer operated independent of one another (to learn more about the Merge and its place in Ethereum’s roadmap, visit Consensys’ information hub for The Merge). In our post-Merge world these two layers run parallel to one another:

Execution Layer: This is the part of Ethereum that handles the execution of smart contract logic and is where transactions are processed and broadcast to the rest of the network. The execution layer is also responsible for maintaining the state of the Ethereum network and executing the Ethereum Virtual Machine (EVM) code; in short, it's where all the computational work happens. Execution layer hard forks are named after the cities that have previously hosted Devcon: Berlin -> London ->Shanghai -> Cancun -> Prague -> Osaka -> Bogotá.

Consensus Layer: This layer is responsible for the agreement on the state of the network among all nodes. It ensures that all transactions and smart contracts are validated and agreed upon via Proof of Stake (PoS). Each consensus layer upgrade is given the name of a star, with the names chosen in alphabetical order based on the first letter: Altair -> Bellatrix -> Capella -> Deneb -> Electra -> (F)unknown.

How and when do upgrades to Ethereum’s layers occur?

Each Ethereum layer undergoes separate upgrades, but the client teams for each layer synchronize the timing of each Ethereum hard fork. Therefore, while the forthcoming Cancun and Deneb upgrades are technically distinct, they are implemented simultaneously. As a result, the portmanteau 'Dencun' is sometimes used to refer to this combined upgrade.

These upgrades do not follow a strict timeline or cadence due to Ethereum’s decentralized nature and plethora of client teams. Nevertheless, recent hard forks have shipped roughly every 8 to 12 months. 

Before going live on mainnet, each hard fork is battle tested through a series of testnets; similarly, Cancun and Deneb will be subjected to a local testnet before activation on the main Ethereum network . The testing roadmap is likely to follow the pipeline shown below—although even this timeline is not absolute—with the Cancun and Deneb hard forks expected to go live on Ethereum Mainnet sometime in January: 

This post will detail two Cancun-specific (Execution Layer) upgrades: EIP-6780 and EIP-5656. For readers unfamiliar with Ethereum jargon, “EIP” refers to “Ethereum Improvement Proposal”. Each specific upgrade to Ethereum typically starts out as an EIP and undergoes review/discussion by the Ethereum community before it is implemented. You can see EIPs considered for inclusion in the Cancun-Deneb fork on the Ethereum Cat Herders (ECH) Dencun page. 

EIP-6780: SELFDESTRUCT only in the same transaction

EIP 6780 is designed to disempower the SELFDESTRUCT (spelt as such) opcode while causing minimal disruption to smart contracts currently utilizing it. This change is partially motivated by the upcoming implementation of Verkle trees, which will make the pre-EIP 6780 version SELFDESTRUCT operation impossible.

If a contract references SELFDESTRUCT in the creation contract, this EIP will not have an impact—funds will still be sent to the target, the code and storage are deleted, and the nonce will be reset to 0. However, after EIP-6780 is implemented, if the contract does not reference SELFDESTRUCT in the same transaction as creation, only the funds are sent, while the code, storage, and nonce are unaffected. To put it simply, existing usage of SELFDESTRUCT should be unaffected, while future references to the opcode will be stripped of their potential negative capabilities.

A brief history of SELFDESTRUCT 

SELFDESTRUCT is an old opcode in the EVM. It was designed to be used by proactive contract creators to clean up and remove unneeded or deprecated code from Ethereum’s state. However, most Ethereum developers consider SELFDESTRUCT to have failed in this goal. The many dangers and unintended consequences of calling this opcode have led developers to stray away from it at best, and incorrectly use it at worst.

The semi-deterministic nature of SELFDESTRUCT made it difficult for developers to use, and often led to incomplete states where data was not fully deleted. This was partially due to the difficulty in estimating the time needed for storage to be removed, as the gas cost was the same irrespective of the amount of data queried for deletion.

Benefits of EIP-6780

On the surface, the benefits of this EIP are clear, and represent necessary house cleaning of the EVM opcodes that is only possible in hindsight. Proponents of this EIP argue the benefits far outweigh the negatives, and refer to Ethereum’s roadmap and future Verkle tree usage, wherein the negative consequences of incorrectly used SELFDESTRUCT calls have the potential for far worse consequences. 

That said, deprecating and bricking specific opcodes always has the potential to come with unintended consequences. Here, the problem has to do with the inability to account for the thousands of Ethereum developers and the myriad ways they may be utilizing SELFDESTRUCT. In cases where a smart contract’s logic relies on the SELFDESTRUCT opcode, removing it may affect the contract’s operation and result in (potentially) unsafe execution. 

The disempowering, rather than the complete removal of the SELFDESTRUCT opcode is an attempt at compromise between these conflicting views. In an ideal world post EIP-6780, there would be few new implementations of SELFDESTRUCT in Ethereum smart contracts, and no existing smart contracts calling the SELFDESTRUCT opcode would be affected. For a more comprehensive introduction to both sides of the debate around the removal of SELFDESTRUCT, we encourage reading Removal of SELFDESTRUCT: An Impact Study on EIP-4758 & EIP-6780—a comprehensive report by Dedaub on the implications of implementing EIP-6780.

EIP-5656: Memory copying instruction

Where EIP-6780 is a reactive upgrade focused on removing a harmful and regrettable opcode, EIP-5656 is a proactive implementation of a new opcode that promises greater efficiency in how data may be moved in the EVM. Specifically, EIP 5656 introduces a new EVM instruction known as MCOPY. 

The purpose of MCOPY is to improve the performance of memory copying and assist in a more efficient means of building data structures. This EIP is strictly an efficiency improvement to the EVM, and does not have any trade offs or incompatibilities as there are no current functional references to MCOPY. 

Broadly speaking, memory copying refers to the process of moving blocks of data from one location in memory to another. It's a fundamental operation in computing, used for tasks like building data structures and copying objects. The MCOPY instruction can be used for non- overlapping areas of memory, overlapping areas, and can be used to move memory backwards. 

For context on efficiency gains: copying 256 bytes of memory will cost 27 gas using MCOPY under EIP-5656, compared to at least 96 gas using the most common previous method, which required multiple instructions. Currently, if a developer needs to copy memory their best option is to reference both MSTORE and MLOAD. The introduction of MCOPY is essentially a combination of those two opcodes.

Going forward, it is rational to expect most developers will utilize MCOPY in place of MSTORE/MLOAD. However, it is notable that no developer will be forced to use MCOPY, just as no existing reference to MSTORE or MLOAD will be affected. It’s also worth noting that a more gas efficient contract ultimately benefits the end user, as they are the ones calling the contract and spending the gas to do so.

Charting the future of Ethereum, one EIP at a time

As mentioned in the introduction, the EIPs discussed in this post—EIP-5656 and EIP-6780—are largely housekeeping updates that won't change the overall direction of Ethereum. Rather, they are best described as the disempowering of one opcode, and the introduction of another. In both cases it is highly likely that Ethereum developers will now be better equipped in their development of smart contracts.

The next post in this series will go further into the Cancun-Deneb upgrade and discuss updates that affect Ethereum’s consensus layer—in this case, EIP-7044 and EIP-7045.

To continue to part two, Ethereum Evolved: Dencun Upgrade Part 2, EIP-7044 & EIP-7045, please click here.