Dencun Upgrade Overview: Cancun Upgrade, Execution Layer and Consensus Layer EIPs

Original Title: 《Dencun Upgrade Overview》

Original Author: BLOB

Compiled by: Luccy, BlockBeats

Editor's Note: With the Cancun upgrade approaching, L2 has also become lively. This article originates from blobcoin on Arbitrum and discusses the Dencun upgrade at a high level, explaining all the changes it will bring to Ethereum, including the execution layer and the consensus layer. This article provides a detailed introduction to the Cancun upgrade and the Dencun upgrade, and BlockBeats compiles the original text as follows:

This is the first article in a series of educational articles about Dencun, EIP4844, and lower transaction fees on Ethereum L2.

Here, we will discuss the Dencun upgrade at a high level, explaining all the changes it will bring to Ethereum, including the execution layer and the consensus layer.

Introduction

What is an EIP?

EIP-1 describes it as:

EIP stands for "Ethereum Improvement Proposal."

An EIP is a design document providing information to the Ethereum community or describing new features for Ethereum or its processes or environment.

Anyone can start a conversation on forums like Ethereum Magicians or Ethereum Research to discuss changes they wish to make on Ethereum: once consensus is reached on the idea, the author can write an EIP following the process described in EIP - 1.

What are the execution layer and consensus layer?

Since Ethereum underwent the merge (also known as the "Paris upgrade"), it has been operating on two distinct, isolated layers: the "execution layer" and the "consensus layer."

These layers have different functions, and together they form the PoS version of the Ethereum blockchain:

Execution Layer (EL): Responsible for applying changes brought by transactions to the blockchain.

If you want to know what this means, let’s illustrate with an example.

In the case where Alice wants to swap 10 WETH for BLOB: Alice must send a transaction to the Ethereum blockchain specifying that she wants to swap her WETH for BLOB. When Alice's transaction is included in the blockchain, the execution layer is responsible for executing all necessary code (the token swap on Sushiswap) and updating Alice's token balance and approvals, effectively modifying the blockchain's database.

Essentially, you should think of the execution layer as Ethereum's engine, with its wheels turning when users do things on the blockchain.

Consensus Layer (CL): Responsible for ensuring all blockchain nodes agree with each other. Given that the blockchain is supported by a network of distributed participants, these participants (often referred to as "nodes") must all agree on the blockchain. If this does not happen and Ethereum nodes disagree, we enter a world where one part of Ethereum might think Alice has 10 WETH while another part thinks she has none.

Think of the consensus layer as Ethereum's steering wheel, defining the path the entire Ethereum blockchain will take!

Key Point: The execution layer and consensus layer are separate and independent, maintained by different teams.

What is Dencun?

Dencun = Deneb + Cancun

Since Ethereum now consists of two independent layers, both layers must make their own modifications to support large-scale changes (such as EIP4844).

Therefore, major upgrades now require upgrades to both layers. For this reason, Ethereum core developers like to refer to a general Ethereum upgrade with a name obtained by combining the names of the upgrades of each layer:

• Shapella = Shanghai (EL) + Capella (CL)

• Dencun = Cancun (EL) + Deneb (CL)

Interesting Fact: EL upgrades are named after cities, while CL upgrades are named after stars.

Now that we understand the two main components of Dencun, let’s dive deeper into them.

Deneb (CL upgrade) will include 5 EIPs, while Cancun will include 6 EIPs.

Deneb: Consensus Layer EIPs

EIP -4788: Beacon Block Root in EVM

This EIP will add "proof" of consensus layer conditions and make it available for smart contracts on Ethereum (located in the execution layer).

Systems like staking pools, re-staking protocols, and bridges will benefit from improved trust assumptions in runtime.

EIP -4844: Sharded Blob Transactions

This EIP introduces a new transaction format for "transactions carrying blobs." This new transaction format will be adopted by L2 networks like Arbitrum and Optimism to publish their own L2 transactions on Ethereum in a compressed format. This improvement will also create a separate fee market for these transactions—meaning Ethereum users and L2 networks will not compete in the Ethereum fee market but will each have their own gas prices.

EIP -7044: Permanently Valid Signature Voluntary Exit

This EIP brings quality-of-life improvements for Ethereum validators running with split credentials, making it easier to withdraw a validator's stake when holding verification credentials and withdrawal credentials separately. Curious readers can learn more about this EIP here.

EIP -7045: Increase Maximum Proof Inclusion Slot

This EIP will extend the maximum time for proposing Ethereum block submission proofs. Proofs are the "votes" cast by validators for proposed blocks: enough votes determine whether a new block will be accepted and added to the blockchain.

EIP -7514: Add Maximum Epoch Churn Limit

This EIP intends to introduce a limit on "epoch churn limit," which directly translates to a limit on "maximum validator growth rate." Ethereum core developers intend to limit the speed at which the number of Ethereum validators can grow, giving teams more time to research more comprehensive solutions to potential issues that may arise when 100% ETH is staked.

Cancun: Execution Layer EIPs

EIP -1153: Transient Storage Opcodes

This EIP will introduce TLOAD and TSTORE opcodes to the Ethereum Virtual Machine. These will be used to specify that certain smart contract data is temporary: it will revert to its original value before the transaction completes! This means smart contracts will be able to have storage that only changes within the transaction! After the transaction ends, such storage will revert to its original state. Many contracts and protocols will benefit from this, as the gas costs of variables used in reentrancy protection will be reduced. (Reentrancy protection is a variable set to an initial value that is modified during transaction execution and reset to the initial value at the end of the transaction.)

EIP -4788: Beacon Block Root in EVM

This EIP is of interest to both CL and EL.

EIP -4844: Sharded Blob Transactions

Our beloved EIP -4844 has already been discussed in the Deneb section.

EIP -5656: MCOPY - Memory Copy Opcode

This EIP will introduce the MCOPY opcode to the Ethereum Virtual Machine, allowing a segment of memory to be copied and written to different parts of memory during smart contract execution.

EIP -6780: SELFDESTRUCT Only in the Same Transaction

This EIP is part of the overall plan to deprecate. It will change the behavior of this opcode to delete accounts only if it is executed in the same transaction that creates the smart contract.

It has long been intended to be deprecated because it hinders the immutability of the Ethereum blockchain. Therefore, the opcode will be modified to allow account deletion only when creating contracts in the same transaction! SELFDESTRUCT

EIP -7516: BLOBBASEFEE Opcode

This EIP introduces the BLOBBASEFEE opcode, which returns the current base fee for data blobs. Similar to how transaction fees work on today's Ethereum, data blob transactions will be priced using an elastic base fee mechanism that will determine the total gas price for sending such transactions! Just like the base fee for normal transactions, if the number of blob transactions exceeds the target transaction count, the blob base fee will gradually increase, and if it falls below the target transaction count, the blob base fee will gradually decrease.