Author: BLOB
Compilation: Luccy, BlockBeats
Editor's note: As Cancun upgrade approaches, L2 also becomes lively. This article is sourced from blobcoin on Arbitrum, discussing 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 and explanation of the Cancun upgrade and the Dencun upgrade. The original article has been translated by BlockBeats as follows:
This is the first 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 EIP?
EIP-1 describes it as:
EIP stands for "Ethereum Improvement Proposal".
EIPs are design documents providing information to the Ethereum community, or describing new features to Ethereum or its processes or environment.
Anyone can start a conversation on forums such as Ethereum Magicians or Ethereum Research, discussing changes they would like to see on Ethereum. Once there is consensus on the idea, the author can write the EIP according to 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 running on two different, isolated layers: the "execution layer" and the "consensus layer".
These layers have different functions and together form the PoS version of the Ethereum blockchain:
Execution Layer (EL): Responsible for applying changes brought by transactions to the blockchain.
To understand what this means, let's take an example.
Suppose Alice wants to exchange 10 WETH for BLOB: Alice must send a transaction to the Ethereum blockchain, specifying the exchange of her WETH for BLOB. When Alice's transaction is included in the blockchain, the execution layer is responsible for executing all the necessary code (token exchange on Sushiswap) and updating Alice's token balance and approvals, effectively modifying the blockchain's database.
Essentially, you have to imagine the execution layer as the engine of Ethereum, where its wheels turn when users do things on the blockchain.
Consensus Layer (CL): Responsible for achieving consensus among all blockchain nodes. Given that the blockchain is supported by a distributed network of participants (usually called "nodes"), these participants must all agree on the blockchain. If this does not happen and Ethereum nodes disagree, we would enter a world where part of Ethereum might think Alice has 10 WETH, while another part might think Alice has no WETH.
Imagine the consensus layer as the steering wheel of Ethereum, defining the path the entire Ethereum blockchain is going to 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 2 independent layers, both layers must make their own modifications to support large-scale changes (such as EIP4844).
Therefore, large upgrades now require upgrades to both layers. For this reason, Ethereum core developers like to use a name to refer to a general Ethereum upgrade, obtained by combining the names of the upgraded layers.
• 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 parts of Dencun, let's delve 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 conditions and make it available for smart contracts on Ethereum (located in the execution layer).
Staking pools, re-staking protocols, bridges, and other systems will benefit from the improved trust assumptions at runtime.
EIP-4844: Shard Blob Transactions
This EIP introduces a new transaction format for "carrying Blob" in transactions. This new transaction format will be adopted by L2 networks such as Arbitrum and Optimism to publish their 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: Permanent voluntary exit with valid signatures
This EIP brings quality of life improvements for Ethereum validators running with separate attestation and withdrawal credentials, making it easier to withdraw a validator's stake. Curious readers can learn more about this EIP here.
EIP-7045: Increase maximum proof inclusion slots
This EIP will extend the longest time for proposed Ethereum block submission proofs. Proofs are "votes" cast by validators on 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 the "maximum validator growth rate." Ethereum core developers intend to limit the rate at which Ethereum validators grow, giving the team more time to research more comprehensive solutions to address potential issues 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 return to its original value before the transaction completes! This means smart contracts will be able to have storage that changes only 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 cost of variables used in reentrancy protection will be reduced. (Reentrancy protection is for variables set to an initial value, which 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: Shard 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 a different part of memory during smart contract execution.
EIP-6780: SELFDESTRUCT only within the same transaction
This EIP is part of the overall plan for deprecation. It changes the behavior of this opcode to delete an account only when executed in the same transaction that creates the smart contract.
It has long been intended for deprecation as it hinders the immutability of the Ethereum blockchain. Therefore, the opcode will be modified to only delete accounts within the same transaction that creates the contract! 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 Ethereum today, data Blob transactions will be priced using an elastic base fee mechanism, which will determine the total Gas price for sending such transactions! Just like regular transaction base fees, if the number of Blob transactions exceeds the target transaction count, the Blob base fee will gradually increase, and if it is below the target transaction count, the Blob base fee will gradually decrease.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
