Ethereum Dencun hard fork content introduction

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).

Reading Tips

Before reading this article, you need to know Prerequisite knowledge includes:

• Hard fork

< li>

Ethereum is divided into Consensus Layer and Execution Layer

Dencun upgrade includes 9 EIPs, which are:

• EIP- 1153: Transient storage opcodes (execution layer changes)

• EIP-4788: Beacon block root in the EVM (execution layer and consensus layer) Changes)

• EIP-4844: Shard Blob Transactions (Execution layer and consensus layer changes)

< li>

EIP-5656: MCOPY - Memory copying instruction (execution layer changes)

• EIP-6780: SELFDESTRUCT only in same transaction (execution layer changes)

• EIP-7044: Perpetually Valid Signed Voluntary Exits (Consensus layer changes)

• EIP-7045: Increase Max Attestation Inclusion Slot (Consensus layer changes)

• EIP-7514: Add Max Epoch Churn Limit (consensus layer changes)

• EIP-7516: BLOBBASEFEE opcode (execution layer changes)

This article will introduce these EIPs (excluding EIP-4844) changes and impacts. For an introduction to EIP-4844, please refer to:

Rollup's big post: Proto-Danksharding (1)< /p>

• https://medium.com/taipei-ethereum-meetup/rollup- and-the-boost-from-proto-danksharding-85d2fe0566b6

Rollup's big post: Proto- Danksharding (2)

• https://medium.com/taipei-ethereum -meetup/rollup-proto-danksharding-implementation-detail-913a3c61fde8

The following introduction and sequence will be roughly It is divided into "EIP related to execution layer changes", "EIP related to consensus layer changes" and "EIP related to EIP-4844".

EIP-1153

• Execution layer changes

• EIP-1153: Transient storage opcodes

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

• EIP-1153:  fan page< /p>

• https://www.eip1153.com/

• EIP-1153: Transient storage opcodes< /p>

• https://ethereum-magicians.org/t/eip-1153-transient-storage-opcodes/553

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 through The SSTORE Opcode writes data into the storage space of the contract. 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.

Operation details

TSTORE is very cheap compared to SSTORE There are many, and its validity period can span 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:

1. Reentrancy Lock. Currently, Reentrancy Lock can only be simulated with SSTORE. Although SSTORE's rules have reduced a lot of gas costs for uses like Reentrancy Lock after passing EIP-2200, TSTORE can significantly reduce the cost: from 5000 to 100.

2. ERC-20 approve used in a single transaction. If contract A interacts with contract B, and contract A needs to transfer ERC-20 from contract B, contract B will first approve ERC-20 for contract A and then call contract A. Because the approval of ERC-20 is done through SSTORE, the cost is not low. Changing to use TSTORE will significantly reduce the cost.

3. Deployment parameters when deploying the contract through CREATE2. Because the Constructor parameters will affect the contract address deployed by CREATE2, if you do not want to be affected by the Constructor parameters, the contract Constructor will be designed to read the parameters from the Storage of the deployer contract, such as the Pool of Uniswap V3. Through TSTORE, this model can save a lot of costs.

Notes

• When contract developers use TSTORE to rewrite their own Reentrancy Lock, remember to clear the Lock when it is time to clear it, and do not want to talk about transactions It will clear itself after it is completed, so the gas consumption of clearing can be saved. Otherwise, if you need to enter the contract again during the transaction, you may not be able to enter because the Lock is not unlocked (not cleared).

• EIP-1153 has been launched in Solidity version 0.8.24, and developers can try it out in advance. Here is a developer-implemented Mutex example. Uniswap V4, which relies on TSTORE, will also go online after the Dencun upgrade is completed.

• This EIP adds a new Opcode, so if developers want to deploy contracts to multiple chains, Please pay attention to whether all chains support the latest Opcode, otherwise it will be unusable.

EIP-4788

• Execution layer changes

• EIP-4788: Beacon block root in the EVM

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

• EIP-4788: Beacon root in EVM

• https://ethereum-magicians.org/t/eip-4788-beacon-root-in-evm/8281

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 consensus layer The data. 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 pass Call the contract to query the consensus layer block root (Beacon Block Root) at a certain point in time. 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 uses it as the call content. The contract will use the timestamp to find the corresponding consensus layer block root in Storage and return it.

If a developer wants to use 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. Then it is combined with the information of the consensus layer block (such as the balance of a certain validator) and Merkle Proof to verify whether the information belongs to the root of the block. (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.)



△ Users provide Merkle Proof and consensus layer blocks Timestamp



△ 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 It is 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.

Notes

BEACON_ROOTS_ADDRESS can store up to 8191 items in the contract Consensus layer block root, 8191 previous block roots will be overwritten. For example, assuming it is Block 18191, the block roots that can be accessed at the moment will range from Block 10000 to Block 18190.

EIP-5656

• Execution layer changes

• EIP-5656: MCOPY - Memory copying instruction

  < /li>

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

EIP-5656 Add a new one MCOPY Opcode is specially used to copy the value stored in Memory during contract execution. Contracts 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 through Assembly ( mcopy(), link), future versions will automatically allow the compiler to apply MCOPY where Memory needs to be copied.

Notes

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

• Execution layer changes

• EIP-6780: SELFDESTRUCT only in same transaction

  < /li>

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

• EIP-6780: Deactivate SELFDESTRUCT, except where it occurs in the same transaction in which a contract was created

• < p style="text-align: left;">https://ethereum-magicians.org/t/eip-6780-deactivate-selfdestruct-except-where-it-occurs-in-the-same-transaction -in-which-a-contract-was-created/13539

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

SELFDESTRUCT The current behavior of the Opcode is: ( 1) Delete the code and storage of the contract, and (2) transfer all the ETH on you to the specified address.

The SELFDESTRUCT Opcode was originally 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 and is therefore key in the design of Stateless Client. With Stateless Client, the hardware of nodes 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:

• If the contract is not created in the same transaction, the code and storage of the contract will remain unchanged, but all the ETH on it will be transferred to the specified address.

• If the contract is created in the same transaction, the behavior is the same as before (before EIP-6780 ) are the same: the contract code and Storage will be removed, and ETH will be transferred to the specified address.

For Verkle Tree, the behavior of (1) must be removed

In the design of Verkle Tree, the way it stores 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, the second layer is a tree composed of all the storages of each address; and Verkle Tree can be imagined as a one-story, completely flat structure. Therefore, in Merkle Patricia Tree we can easily locate the Storage of an address and remove it, but in 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 not easy to know which value belongs to which storage 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: State Root corresponds to a tree composed of all addresses, and Storage Root corresponds to a tree composed of all Storages 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 picture is the address, and the green node is the Storage value of the address. .

Image source: https://youtu.be/s7fm6Zz_G0I?t=572

< img src="https://img.jinse.cn/7188773_image3.png">

△  If we only remove the red node but not Storage (green nodes), if the contract is redeployed to the same address, it will directly inherit the old, not deleted Storage, which will become a potential 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.

Notes

• If the developer uses CREATE2 + SELFDESTRUCT to repeatedly deploy to the same address, after Dencun this will only occur simultaneously within the same transaction to complete.

• If the developer uses CREATE2 + SELFDESTRUCT to achieve the effect of contract upgrade (so CREATE2 + SELFDESTRUCT does not will be completed in the same transaction) and will not be able to continue after Dencun, please switch to the upgrade mode that generally does not SELFDESTRUCT.

EIP-7044

• Consensus layer changes

• EIP-7044: Perpetually Valid Signed Voluntary Exits

• https://eips.ethereum.org/EIPS/eip-7044

• EIP-7044: Perpetually Valid Signed Voluntary Exits

• https://ethereum-magicians.org/t/eip-7044-perpetually-valid-signed-voluntary-exits/14348

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

Ethereum PoS validators need to have two The private key: one is used for daily participation in verification (such as producing blocks and signing), which is called Validator Key; the other is the private key of the address where pledged assets and handling fees are returned 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 staking service, the service provider will hold the Validator Key, and the user will hold the Withdrawal Key, so the service provider It can only perform daily verification-related work content, and cannot take away the user's pledged assets and handling fees to achieve the purpose of non-custodial. In order to prevent service providers from threatening to blackmail users by "not quitting PoS", service providers will sign a PoS withdrawal certificate at the beginning and give this certificate to users, so that users can choose to quit at any time. PoS, independent of service provider.

Operation details

However, due to the withdrawal of PoS signature content 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 withdrawal certificate signed at the time of Altair will become invalid now; if it is updated to the next version of Deneb, the withdrawal certificate signed at the time of 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 a hard fork occurs. If the user does not obtain the exit certificate in advance, the service provider may be able to "not obtain the exit certificate" after the hard fork. "Exit PoS" threatens to blackmail users.

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.

So EIP-7044 fixes the hard fork version of 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.

Notes

Because of the exit-proof hard fork The version has been fixed in Capella, so if a verifier or service provider signs the Deneb version's exit certificate in advance, it will become invalid after Deneb.

EIP-7045

• Consensus layer changes

• EIP-7045: Increase max attestation inclusion slot

  < /li>

  • https:// eips.ethereum.org/EIPS/eip-7045

• EIP-7045: Increase max attestation inclusion slot

• https://ethereum-magicians.org/t/eip-7045-increase-max-attestation-inclusion-slot/14342

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

Original validator’s vote (Attestation) There is one Epoch (32 Slots) of time that can be included. For example, assume that the verifier 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 until Slot 10020. p2p network, but her votes 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.

Operation details

EIP-7045 will include the voting The validity period is extended 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 (3237 = 3205 + 32) at the latest; after EIP-7045, her vote It can be included until the end of Epoch 101 (that is, Slot 3263) at the latest.

Note: Epoch 0 contains Slots 0 to 31; Epoch 100 contains Slots 3200 to 3231; Epoch 101 contains Slots 3232 to 3263.

EIP-7514

• Consensus layer changes

• EIP-7514: Add Max Epoch Churn Limit

  < /li>

  • https:// eips.ethereum.org/EIPS/eip-7514

• EIP-7514: Add max epoch churn limit

• https://ethereum-magicians.org/t/eip-7514-add-max-epoch-churn-limit/15709

Background

After Shanghai upgrades open validators to withdraw from PoS in 2023, On the contrary, it attracts more users to join as validators, causing the validator waiting sequence (Entry Queue) to always be full, and the total number of validators continues to rise rapidly.



△ Entry Queue has surged since PoS was withdrawn from the opening. Picture source: https://www.validatorqueue.com/

If the validator wait sequence continues to be full, then from September 2023 By May 2024 (when EIP is proposed), in about eight months, 50% of ETH will be pledged into PoS; 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.

Why does there continue to be so much ETH pouring 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 income of MEV, various factors have turned staking into a Very attractive option.

Fortunately, the staking boom will gradually recede in the second half of 2023, slowing down the growth of the number of validators.



△ The growth in the number of validators will slow down in the second half of 2023, and in February 2024, about 25% of ETH will be pledged. Image source: https://www.validatorqueue.com/

Operation details

Originally, the upper limit of the number of Entry Queue changes with the current number of validators. For every increase or decrease of 65536 validators, the upper limit of the number of Entry Queue will increase or decrease by 1. 2024 The monthly maximum number of Entry Queues is 14 (the current number of validators is approximately 950,000).

EIP-7514 will fix the upper limit of the number of Entry Queue at 8 and will no longer increase with the increase of the current number of validators, thereby slowing down the growth of the number of validators. Speed ​​allows 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: Shard Blob Transactions

• https://www.eip4844.com/

• Rollup's big post: Proto-Danksharding (1)

• https://medium.com/taipei-ethereum-meetup/rollup-and-the-boost-from- proto-danksharding-85d2fe0566b6

• Rollup's big post: Proto-Danksharding (2)< /p>

• https://medium.com/taipei-ethereum-meetup/rollup-proto-danksharding-implementation-detail-913a3c61fde8

EIP-4844 Added 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 expansion and upgrade, but more like "increasing the block Gas Limit" and "reducing the cost" so that the block can be placed A change to increase transaction volume by entering more (Rollup) transactions. But EIP-4844 also paves the way for a real expansion solution – Danksharding.

In addition, Blob trading fairs and general trading fairs are separate and independent fee markets. Each has its own Base Fee and Priority Fee, so EIP-7516 is a Blob trading A BLOBBASEFEE Opcode has been added to the fee market (the function is equivalent to the BASEFEE Opcode of general transactions), so that the Rollup contract can know the Base Fee of the Blob through this Opcode.

Summary and key points

• Dencun hard fork consists of Deneb hard fork at the consensus layer and Cancun hard fork at the execution layer.

• The protagonist of this upgrade is EIP-4844. The introduction of the Blob transaction format allows Rollup to further reduce transaction costs and at the same time provide Danksharding paving.

• Changes in the consensus layer include EIP-7044, EIP-7045 and EIP-7514.

• EIP-7044 allows validators using non-custodial staking services to be unaffected by future hard forks when opting out of PoS .

• EIP-7045 and EIP-7514 can be considered updates to increase the stability of the PoS network.

• Execution layer changes include EIP-1153, EIP-4788, EIP-5656, EIP-6780 and EIP-7516.

• EIP-1153 allows many contract design patterns to save a lot of gas; EIP-5656 also allows the gas cost to be slightly reduced.

• EIP-4788 allows the execution layer to read the consensus layer information without trusting a third party, opening more Possibility of staking related services.

• EIP-6780 further eliminates SELFDESTRUCT and removes its ability to "remove contract code and status".

• Developers need to be careful not to rely on the assumption that "temporary storage will be cleared after the transaction" when using EIP-1153, and if If you use SELFDESTRUCT, be sure to pay attention to whether your contract will be affected.

• General users do not need to pay special attention to it. They can enjoy lower transaction costs as long as Rollup adopts Blob transactions.

Reference data and recommended further reading

< p style="text-align: left;">EIP-1153

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

• https://www.eip1153.com/

• https://ethereum-magicians.org/t/eip-1153-transient-storage-opcodes/553

• https://hackmd.io/@-_WYFKbvSmip5m7MNB4b8A/SJFH66Eca

EIP-4788

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

• https://ethereum -magicians.org/t/eip-4788-beacon-root-in-evm/8281

< strong>EIP-5656

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

EIP-6780

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

• https://ethereum-magicians .org/t/eip-6780-deactivate-selfdestruct-except-where-it-occurs-in-the-same-transaction-in-which-a-contract-was-created/13539

• https://www.youtube.com/watch?v=s7fm6Zz_G0I

EIP-7044

• https://eips.ethereum.org/EIPS/eip-7044

• < p style="text-align: left;">https://ethereum-magicians.org/t/eip-7044-perpetually-valid-signed-voluntary-exits/14348

EIP-7514

• https://eips.ethereum.org/EIPS/eip-7514

• https://ethereum-magicians.org/t/eip-7514-add-max-epoch-churn-limit/15709

EIP-4844 & EIP-7516

• https://www.eip4844.com/

• https://medium.com/taipei-ethereum-meetup/rollup-and-the-boost-from-proto-danksharding -85d2fe0566b6

• https://medium.com/taipei-ethereum-meetup/rollup-proto -danksharding-implementation-detail-913a3c61fde8

• https://eips.ethereum.org/EIPS /eip-7516

• https://ethereum-magicians.org/t/eip-7516 -blobbasefee-opcode/15761