English
66821
 Dencun is composed of the two names Deneb and Cancun, which represent the hard fork of the Ethereum consensus layer and execution layer respectively. The Dencun hard fork has been completed on the Goerli, Sepolia and Holesky testnets, and the mainnet will be launched on Epoch 269568 (approximately March 13, 2024). Author: Nic @ imToken Labs Proofreading: Members at imToken Labs Cover source: Cancun & Deneb / Created by Midjourney Reading Tips Before reading this article, the prerequisite knowledge you need to know includes:
The Dencun upgrade includes 9 EIPs, which are:
This article will introduce the changes and impacts of these EIPs (excluding EIP-4844). For an introduction to EIP-4844, please refer to: Rollup’s big post: Proto-Danksharding (1)
Rollup’s big post: Proto-Danksharding (2)
The following introduction and sequence will be roughly divided into "EIP related to execution layer changes", "EIP related to consensus layer changes" and "EIP related to EIP-4844". EIP-1153
EIP-1153 adds two new Opcodes: TSTORE and TLOAD, which are used to write and read "temporary" Storage data. They will save many contract developers a lot of gas costs. background Storage refers to the smart contract writing data into the contract's storage space through the SSTORE Opcode. After the data is written, it will exist permanently until the contract actively removes the data. The characteristic of "temporary" is compared to "permanent existence". The data written by TSTORE is only valid until the end of the transaction. After the transaction is executed, the value written by TSTORE will be discarded. Operational details TSTORE is much cheaper than SSTORE, and its validity spans calls between different contracts (until the end of the transaction). Unlike Memory, although it is cheap, the value in Memory is exclusive to each contract itself. Contract A cannot read the Memory of Contract B. This is very helpful for many purposes:
EIP-4788
EIP-4788 adds a BEACON_ROOTS_ADDRESS contract to allow people to read the data of the consensus layer block, that is, the execution layer will be able to read the data of the consensus layer. Through this contract, the Staking and Restaking protocols can read and use consensus layer data without trusting any third party, such as reading the status of a certain validator. Operational details Users or contracts can query the consensus layer block root (Beacon Block Root) at a certain point in time by calling the contract. The block root is like the hash value of the block content (Beacon Block Hash), which is the root of the Merkle Tree (Merkle Tree Root) obtained by SSZ encoding of the block content. The caller encodes the timestamp (timestamp) into a uint256 value and treats it as the call content. The contract will use the timestamp to go to Storage to find the corresponding consensus layer block root and return it. If a developer wants to use the consensus layer information, his contract will query the block root of the consensus layer block he wants to read through the BEACON_ROOTS_ADDRESS contract, and then use the consensus layer block information (such as the balance of a certain validator) and Merkle Proof to verify whether the information belongs to the block root. (SSZ makes all content into Merkle Tree, so any information in the content can generate corresponding Merkle Proof to verify that the information exists in the content. )  △ The user provides Merkle Proof and the timestamp of the consensus layer block  △ Merkle Proof is used with querying the block root to verify the validator balance at a certain point in time. However, the consensus layer block root stored in the BEACON_ROOTS_ADDRESS contract is actually the block root of the "parent" block (that is, the previous block), not the block root of the same block as the execution layer.  △ The timestamp of Block 11001 (1234567) corresponds to the block root of Block 11000. Similarly, the timestamp of Block 11000 (1234555) corresponds to the block root of Block 10999. Things to note The BEACON_ROOTS_ADDRESS contract stores up to 8191 consensus layer block roots, and 8191 previous block roots will be overwritten. For example, assuming it is Block 18191, the block root range that can be accessed at the moment will be the block root from Block 10000 to Block 18190. EIP-5656
EIP-5656 adds a new MCOPY Opcode, specifically used to copy the value stored in Memory during contract execution. The contract will benefit from the gas cost savings of this Opcode. If contract developers want to use MCOPY Opcode, they need to specify the compiler version as 0.8.24 (or above) and the EVM version as Cancun:  △ To use MCOPY, you need to set the compiler version and EVM version. Note: The compiler version 0.8.24 only allows the use of MCOPY (mcopy(), link) through Assembly. Only in future versions will the compiler automatically apply MCOPY where Memory needs to be copied. Things to note This EIP adds a new Opcode, so if developers want to deploy contracts to multiple chains, they must pay attention to whether all chains support the latest Opcode, otherwise it will be unusable. EIP-6780
EIP-6780 modified the behavior of SELFDESTRUCT Opcode to prepare for Verkle Tree and the elimination of SELFDESTRUCT Opcode. Developers whose contracts use the SELFDESTRUCT Opcode need to pay special attention. background The current behavior of SELFDESTRUCT Opcode is: (1) delete the code and storage of the contract, and (2) transfer all the ETH on it to the specified address. From the beginning, the SELFDESTRUCT Opcode was designed with a Refund mechanism to encourage developers to remove unused contracts and storage space to help maintain the Ethereum state at a suitable size. But not many people actually do this. Instead, accidents like Parity Multisig have caused hundreds of thousands of ETH to be frozen due to SELFDESTRUCT. Therefore, the Ethereum community hopes to gradually phase out the SELFDESTRUCT Opcode. There have been many proposals to modify or remove the SELFDESTRUCT Opcode in the past, and EIP-6780 is one of them and was eventually included in the Dencun hard fork. Note: In the Shanghai hard fork in early 2023, EIP-6049 has officially announced that SELFDESTRUCT will be eliminated. Verkle Tree is a state storage structure currently being actively researched and developed by the Ethereum community, and will be used to replace the current Merkle Patricia Tree. Verkle Tree will make the proof size of Ethereum state smaller, so it is also the key in the design of Stateless Client. With Stateless Client, node hardware will be reduced, allowing more people to run nodes with lighter and cheaper hardware, improving the decentralization of the network. Operational details After EIP-6780, SELFDESTRUCT Opcode will remove the behavior of (1) and only retain the function of (2) "transfer all ETH on you to the specified address". The contract's code and Storage will remain unchanged unless the contract is created in the same transaction and then SELFDESTRUCT is performed. So when SELFDESTRUCT is triggered:
In the design of Verkle Tree, its way of storing state is different from that of Merkle Patricia Tree. The Merkle Patricia Tree storage state can be imagined as a two-layer (tree within a tree) structure: the first layer is a tree composed of all addresses, and the second layer is a tree composed of all Storages of each address. ； The Verkle Tree can be imagined as a one-story, completely flat structure. Therefore, in the Merkle Patricia Tree, we can easily locate the Storage of an address and remove it, but in the Verkle Tree, it is almost impossible to locate the Storage of an address, because all addresses and each Storage value of the address are flattened and scattered in the same tree. It is impossible to easily know which value belongs to the Storage of which address, so we cannot remove the contract code and all its Storage in the Verkle Tree.  △ The current state tree design (Merkle Patricia Tree) is a two-layer structure: the State Root corresponds to a tree composed of all addresses, and the Storage Root corresponds to a tree composed of all Storage under an address. Image source: https://fisco-bcos-documentation.readthedocs.io/en/latest/docs/design/storage/mpt.html  △ Verkle Tree state tree is a one-layer, completely flat tree. The red node in the figure is the address, and the green node is the Storage value of the address. Image source: https://youtu.be/s7fm6Zz_G0I?t=572  △ If we only remove the red nodes but not the Storage (green nodes), then if the contract is redeployed to the same address, it will directly inherit the old, undeleted Storage, which will become a potentially high-risk vulnerability. Image source: https://youtu.be/s7fm6Zz_G0I?t=572 Therefore, in order to welcome Verkle Tree, we must disable the SELFDESTRUCT Opcode that can remove contract code and Storage. Things to note
EIP-7044
EIP-7044 makes the signature used by the verifier to exit PoS permanently valid, preventing the signature from becoming invalid due to network hard forks. Validators entrusted to non-custodial staking services (such as Lido) will have improved experience and assurance: they will not have to ask a third party to re-sign every hard fork. background The validator of Ethereum PoS needs to have two private keys: one is used for daily participation in verification (such as producing blocks and signing), called Validator Key； The other is the private key of the address where pledged assets and handling fees are withdrawn when exiting PoS, which is called Withdrawal Key. When a validator wants to exit PoS, he will sign with the Validator Key, and the content of the signature contains the current network (hard fork) version. In the current non-custodial pledge service, the service provider will hold the Validator Key, and the user will hold the Withdrawal Key. Therefore, the service provider can only perform daily verification-related work and cannot take away the user's pledged assets and handling fees to achieve the purpose of non-custodial. In order to prevent the service provider from threatening to "not withdraw from PoS" to extort users, the service provider will sign the PoS withdrawal certificate at the beginning and hand this certificate to the user, so that the user can choose to withdraw from PoS at any time without being affected by the service provider. Operational details But because the signature content for exiting PoS contains the current network (hard fork) version, such as the current Shanghai or the previous version of Capella. The network will compare the "hard fork version in the exit certificate" and the "current version of the network". If the version difference is more than two versions, it will be deemed invalid. In other words, as the network is constantly updated, after hard forks and upgrades to new versions, exit certificates that are too old will become invalid. For example, the current hard fork versions of the consensus layer from old to new are Altair, Bellatrix and (currently) Capella. The exit certificate signed at Altair at that time will become invalid now. ； If you update to the next version of Deneb, the exit certificate signed at that time for Altair and Bellatrix will become invalid. In order to cope with this situation, users must request an exit certificate from the service provider every time they hard fork. If the user does not obtain the exit certificate in advance, the service provider may be able to blackmail the user with the threat of "not exiting PoS" after the hard fork. Note: However, because the "Exit PoS" was only opened after Capella, there may not be anyone who signs the exit certificate at Altair or Bellatrix in advance. Therefore, EIP-7044 fixes the hard fork version in the exit certificate in Capella, so that all exit certificates signed in the current version will be permanently valid. No matter how many times it is updated in the future, Capella will always be signed in the exit certificate and will no longer be affected by the hard fork version. Things to note Because the hard fork version of the exit certificate has been fixed in Capella, if a validator or service provider signs the Deneb version of the exit certificate in advance, it will become invalid after Deneb. EIP-7045
EIP-7045 extends the validity period of validators’ votes (Attestation), allowing more time for votes to be collected and increasing the stability of the network. There is no impact on general users or validators. background Originally, the validator's vote (Attestation) has one Epoch (32 Slots) of time to be included. For example, assuming that the validator Alice is assigned to vote in Slot 10000, and due to network waiting time issues, she may not complete her vote until Slot 10010 or her vote may not be successfully broadcast to the p2p network until Slot 10020, but her vote will still be included. However, if her vote does not appear until Slot 10033, her vote will not be included and it will be treated as if she did not vote. Operational details EIP-7045 extends the validity period of voting inclusion until the end of the next Epoch of voting at the latest. For example, assume that the verifier Alice is assigned to vote in Slot 3205 of Epoch 100. Before EIP-7045, her vote is valid until Slot 3237 at the latest (3237 = 3205 + 32) ； After EIP-7045, her vote can be included until the end of Epoch 101 (that is, Slot 3263) at the latest. Note: Epoch 0 contains Slots from 0 to 31； Epoch 100 contains Slots 3200 to 3231 ； Epoch 101 contains Slots 3232 to 3263. EIP-7514
background After Shanghai upgraded its open validators to withdraw from PoS in 2023, it attracted more users to join as validators, causing the validator waiting sequence (Entry Queue) to always be full, and the total number of validators continued to rise rapidly.  △ Entry Queue has surged since PoS was withdrawn from the opening. Image source: https://www.validatorqueue.com/ If the validator waiting sequence continues to be fully loaded, 50% of the ETH will be pledged into PoS in about eight months from September 2023 (when the EIP is proposed) to May 2024； By September 2024, 75% of ETH will be pledged. Staking so much ETH has several disadvantages, such as too many validators, resulting in too many validator votes and aggregated signatures, increasing the burden on the validator p2p network and the state expansion of the consensus chain. In addition, some people think that the security required by Ethereum does not require so much ETH pledge. Multi-pledge ETH is a waste from a security perspective. And why does so much ETH continue to pour in? Because even if 100% of ETH is pledged, the annualized rate is still about 1.6%, and the emergence of Liquid Staking Token (LST) has further improved capital utilization efficiency. Coupled with the benefits of MEV, various factors make staking a very attractive option. Fortunately, the staking craze gradually receded in the second half of 2023, slowing down the growth of the number of validators.  △ The growth in the number of validators slowed down in the second half of 2023, and in February 2024, approximately 25% of ETH was pledged. Image source: https://www.validatorqueue.com/ Operational details The original upper limit of the number of Entry Queue changes with the current number of validators. Every time 65536 validators are added or reduced, the upper limit of the number of Entry Queue will increase or decrease by 1. The upper limit of the number of Entry Queues in February 2024 is 14 (the current number of validators is approximately 950,000). EIP-7514 will fix the upper limit of the number of Entry Queues at 8 and will no longer increase as the current number of validators increases. This will slow down the growth of the number of validators and give the community more time to come up with long-term solutions, such as EIP-7251, which may be included in the next hard fork. EIP-4844 and EIP-7516
EIP-4844 adds a new transaction type, a transaction specifically used to store Blob data. By placing data in Blobs, Rollup will be able to further reduce transaction fees. EIP-4844 is not a change for capacity expansion and upgrade, but more like a change to increase the transaction volume by "increasing the gas limit of the block" and "reducing the cost" so that more (rollup) transactions can be put into the block. But EIP-4844 also paves the way for a real expansion solution – Danksharding. In addition, Blob trading and general trading are separate and independent fee markets, each with their own Base Fee and Priority Fee. Therefore, EIP-7516 adds a BLOBBASEFEE Opcode to the Blob trading fee market (the function is equivalent to the BASEFEE Opcode of general trading), so that the Rollup contract can know the Base Fee of the Blob through this Opcode. Summary and highlights
Reference data and recommended further reading EIP-1153
EIP-4788
EIP-5656
EIP-6780
EIP-7044
EIP-7514
EIP-4844 & EIP-7516
END Want to know more about blockchain technology, tools and digital assets please follow us  Click to watch and share us  |
|
|
|
|
|
