Introduction to the content of Ethereum Dencun

Dencun is composed of two names Deneb and Cancun, representing the hard fork between the Ethereum consensus layer and the execution layer.The Dencun hard fork has been completed on Goerli, Sepolia and Holesky test networks, and the mainnet will be conducted on Epoch 269568 (approximately March 13, 2024).

Reading Tips

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

Hard fork
Ethereum is divided into a consensus layer and an execution layer.

The Dencun upgrade contains 9 EIPs, namely:

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)
EIP-5656: MCOPY – Memory copying instruction (execution layer changes)
EIP-6780: SELFDESTRUCT only in same transaction
EIP-7044: Perpetually Valid Signed Voluntary Exits
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 the changes and impacts of these EIPs (excluding EIP-4844). For the introduction of EIP-4844, please refer to:

Rollup’s big addition: Proto-Danksharding (I)

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

Rollup’s big addition: Proto-Danksharding (II)

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

Next, we will introduce the order roughly 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

https://www.eip1153.com/

EIP-1153: Transient storage opcodes

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

EIP-1153 has added two new Opcodes: TSTORE and TLOAD, which are used to write and read “temporary” Storage data.They will save a lot of Gas costs for many contract developers.

background

Storage refers to the smart contract writing data into the storage space of the contract through the SSTORE Opcode. The data exists permanently after writing it until the contract actively removes the data.The “temporary” characteristic is that compared with “permanent existence”, the data written by TSTORE is valid until the end of the transaction. After the transaction is executed, the value written by TSTORE will be discarded.

Operation details

TSTORE is much cheaper than SSTORE, and its validity period can span calls between different contracts (until the transaction ends). Unlike Memory, although it is cheap, the value in Memory only belongs to each contract itself, and A contract cannotGo to read the Memory of the B contract.This is very helpful for many uses:

Reentrancy Lock.Currently, Reentrancy Lock can only be simulated with SSTORE. Although the use of Reentrancy Lock after EIP-2200 can reduce the cost of Gas, TSTORE can significantly reduce the cost: from 5,000 to 100.
Used in ERC-20 approve within 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 to contract A before calling contract A.Because the approve of ERC-20 is all through SSTORE, the cost is not low, and changing to using TSTORE will greatly reduce the cost.
Deployment parameters when deploying contracts through CREATE2.Because the Constructor parameter will affect the contract address of CREATE2 deployment, if you do not want to be affected by the Constructor parameter, the contract constructor will be designed to deploy the Storage Read parameters of the contract, such as the Pool of Uniswap V3.With TSTORE, such a model can save a lot of costs.

Things to note

When contract developers use TSTORE to rewrite their own Reentrancy Lock, remember to clear the Lock when it is time to clear it. Don’t think that it will clear itself after the transaction is over, so it can save the consumption of clearing Gas, otherwise if there is a need during the transaction process, it will be done again.If you enter the contract, you may not be able to enter because 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 are the Mutex examples implemented by developers.Uniswap V4, which relies on TSTORE, will also be launched after the Dencun upgrade is completed.
This EIP has a new Opcode, so if developers want to deploy contracts to multiple chains, they should pay attention to whether all chains support the latest Opcode, otherwise it will be unavailable.

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 Added a BEACON_ROOTS_ADDRESS contract to allow people to read data from consensus layer blocks, that is, the execution layer will be able to read data from 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 verifier.

Operation details

Users or contracts can query the 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 Merkle Tree root of the block content through SSZ encoding.The caller encodes the timestamp into the value of uint256 and treats it as the call content. The contract uses the timestamp to search for the corresponding consensus layer block root and pass it back.

If a developer wants to use the consensus layer information, his contract will query the block root of the consensus layer block that he wants to read through the BEACON_ROOTS_ADDRESS contract, and then match the information of the consensus layer block (for example, a verifier’sBalance) and Merkle Proof to verify whether the information belongs to the root of the block.(SSZ Because the content is made into Merkle Tree, any information in the content can generate the corresponding Merkle Proof to verify that the information exists in the content.)

△ The user provides the timestamp of Merkle Proof and consensus layer blocks

△ Merkle Proof is used to verify the verifier 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 “main” block (that is, the previous block), rather than 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, if it is Block 18191 now, the current block root range that can be accessed will be the block root of Block 10000 to Block 18190.

EIP-5656

Execution layer changes
EIP-5656: MCOPY – Memory copying instruction

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

EIP-5656 has added a MCOPY Opcode, which is specially used to copy the values stored in Memory during the contract execution.The contract will benefit from the Gas cost savings from this Opcode.

To use MCOPY Opcode, contract developers 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 of version 0.8.24 is only open to using MCOPY (mcopy(), link) through Assembly. In the future version, the compiler will automatically apply MCOPY where the Memory needs to be copied.

Things to note

This EIP has a new Opcode, so if developers want to deploy contracts to multiple chains, they should pay attention to whether all chains support the latest Opcode, otherwise it will be unavailable.

EIP-6780

Execution layer changes
EIP-6780: SELFDESTRUCT only in same transaction

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

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 who use SELFDESTRUCT Opcode need special attention.

background

SELFDESTRUCT Opcode’s current behavior is: (1) delete the code and storage of the contract, and (2) transfer all the ETH on it to the specified address.

At the beginning, we designed SELFDESTRUCT Opcode with 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 really do this, but there are accidents like Parity Multisig that caused hundreds of thousands of ETH to freeze due to SELFDESTRUCT, so the Ethereum community hopes to gradually eliminate SELFDESTRUCT Opcode.There have been many proposals to modify or remove 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 that the Ethereum community is currently actively researching and developing, 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 key in Stateless Client design.With the Stateless Client, the hardware of nodes will be reduced, allowing more people to run nodes with lighter and cheaper hardware, improving the degree of decentralization of the network.

Operation details

After EIP-6780, SELFDESTRUCT Opcode will remove (1) behavior and only retain the function of (2) “Transfer all ETH on your body to the specified address”.The contract 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 contract code and Storage remain unchanged, but the ETH on it is transferred to the specified address.
If the contract is created on the same transaction, the behavior is the same as before (before EIP-6780): the contract’s code and storage will be removed, and the ETH will be transferred to the specified address.

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

In the design of Verkle Tree, its storage status is different from that of Merkle Patricia Tree.The storage state of Merkle Patricia Tree can be imagined as a structure of two layers (trees in trees): the first layer is a tree composed of all addresses, and the second layer is a tree composed of all storage and synthesis for each address; and VerkleTree can be imagined as a layered, 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 the addresses and each Storage value of the address is evenly distributedIn the same tree, it is impossible to easily know which value belongs to which address Storage, 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 address sets, and Storage Root corresponds to all Storage and synthetic trees under an address.

Source: https://fisco-bcos-documentation.readthedocs.io/en/latest/docs/design/storage/mpt.html

△ Verkle Tree State Tree is a completely flat tree.

In the figure, the red node is the address, and the green node is the Storage value of the address.

Source: https://youtu.be/s7fm6Zz_G0I?t=572

△ If we only remove the red node but not the Storage (green nodes), if the contract is re-deployed to the same address, it will directly inherit the old, undeleted Storage, which will become a potentially high risk.Vulnerability.

Source: https://youtu.be/s7fm6Zz_G0I?t=572

So in order to welcome Verkle Tree, we must prohibit SELFDESTRUCT Opcode from removing contract codes and storage.

Things to note

If the developer uses CREATE2 + SELFDESTRUCT to repeatedly deploy to the same address, this will only occur simultaneously within the same transaction after Dencun to complete.
If the developer uses CREATE2 + SELFDESTRUCT to achieve the effect of contract upgrades (so CREATE2 + SELFDESTRUCT will not be completed in the same transaction), it will not be able to continue after Dencun. Please use the upgrade mode that does not generally 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 allows the signature used by the verifier to exit PoS to be permanently valid, avoiding the signature being invalid due to network hard fork.The user experience and protection of verifiers entrusted to non-managed pledge services (such as Lido) will be improved: there is no need to ask a third party to re-sign each time you have to hard fork.

background

The verifier of Ethereum PoS needs to have two private keys: one for daily participation in verification (such as block production and signature), called Validator Key; the other is to receive the pledged assets and handling fees when exiting PoS.The private key of the address is called Withdrawal Key.When the validator is about to exit PoS, he will sign with the Validator Key, and the signed content contains the current network (hard forked) version.

In the current non-hosted pledge services, the service provider will hold the Validator Key in its hand, and the user will hold the Withdrawal Key. Therefore, the service provider can only perform daily verification-related work content and cannot take away the user’sPledge assets and handling fees to achieve the purpose of non-custody.In order to avoid service providers threatening to extort users by “not exiting PoS”, service providers will sign the exit PoS certificate at the beginning and hand over the proof to the user, so that users can choose to exit at any timePoS, not affected by service providers.

Operation details

But because the signature content that exits 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 considered invalid.In other words, as the network continues to be updated, after hard fork and upgrade to a new version, the exit proof that is too old will be invalid.

For example, the hard forked versions of the consensus layer from old to new are Altair, Bellatrix and (current) Capella.The exit certificate signed at Altair will become invalid now; if it is updated to the next version of Deneb, the exit certificate signed at Altair and Bellatrix will become invalid now.To cope with this situation, the user must request another exit certificate from the service provider every time the user forks. If the user does not receive the exit certificate in advance, the service provider may be able to “no” after the hard forks.Exit PoS” threatens to blackmail users.

Note: However, since “Exit PoS” is only open after Capella, no one may sign out the exit certificate in Altair or Bellatrix in advance.

Therefore, EIP-7044 fixes the hard fork version in the exit certificate to Capella, so that all exit certificates signed in the current version will be permanently valid.No matter how many updates are made in the future, Capella will be signed in the exit certificate and will no longer be affected by the hard forked version.

Things to note

Because the hard fork version of the exit certificate is already fixed in Capella, 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

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 the voting of validators, allowing more time to be earned and increases network stability.No impact on general users or verifiers.

background

Originally, the voting of the verifier (Attestation) has an Epoch (32 Slots) time that can be earned. For example, if the verifier Alice is assigned to vote in Slot 10000, she may not complete the voting in Slot 10010 due to network waiting time issues orIt was only after the Slot 10020 vote that it was successfully broadcast to the p2p network, but her votes would still be earned.But if her vote only appears until 10033 Slot, then there is no way to include her vote and it is deemed that there is no vote.

Operation details

EIP-7045 extends the validity period of voting inclusion until the latest “before the next Epoch of the vote ends”.For example, suppose that the verifier Alice is assigned to vote at Slot 3205 on Epoch 100, and before EIP-7045, her voting is valid until Slot 3237 (3237 = 3205 + 32); after EIP-7045, her voting is valid until Slot 3237 (3237 = 3205 + 32); after EIP-7045, her voting is validIt can be included until the end of Epoch 101 (that is, Slot 3263).

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

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 upgraded and opened validators to exit PoS in 2023, it has attracted more users to join and become validators, resulting in the validator waiting sequence (Entry Queue) always being full, and the total number of validators is also increasing rapidly.

△ Entry Queue has surged after exiting PoS from open.Source: https://www.validatorqueue.com/

If the validator waits for the sequence to remain fully loaded, 50% of ETH will be pledged to PoS in about eight months from September 2023 (when the EIP was proposed) to May 2024; by 2024There will be 75% ETH pledge in September 2019.There are several disadvantages of so many ETH pledges, such as too many validators, which leads to too many validators voting and aggregation signatures, increasing the burden on the validators’ p2p network and the expansion of the consensus chain.In addition, some people think that the security required by Ethereum does not require so much ETH stake. Multi-staken ETH is a waste from a security perspective.

And why does so much ETH continue to pour in?Because even if ETH reaches 100% stake, the annualized rate is still about 1.6%. Moreover, the emergence of Liquid Staking Token (LST) has further improved capital utilization efficiency, coupled with the returns of MEV, various factors have turned the pledge into aVery attractive option.

Fortunately, the pledge boom gradually receded in the second half of 2023, slowing down the growth of the number of validators.

△ The growth of the number of validators slowed down in the second half of 2023, with about 25% ETH pledged in February 2024.Source: https://www.validatorqueue.com/

Operation details

The original number of Entry Queues varies with the current number of validators. For every 65,536 validators increase or decrease, the number of Entry Queues will increase or decrease by 1. The number of Entry Queues in February 2024 is 14 (The current number of validators is approximately 950,000).

EIP-7514 will fix the Entry Queue limit to 8, no longer increasing with the number of current validators, thereby slowing down the growth of validators and giving the community more time to come up with long-term solutions, such asThe next hard fork may earn EIP-7251.

EIP-4844 and EIP-7516

EIP-4844: Shard Blob Transactions

https://www.eip4844.com/

Rollup’s big addition: Proto-Danksharding (I)

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

Rollup’s big addition: Proto-Danksharding (II)

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

EIP-4844 Added a new type of transaction, a transaction specifically used to store blob data.By placing the data in a blob, Rollup will further reduce transaction fees.

EIP-4844 is not a change to expand and upgrade capacity, but is more like “upgrade the block Gas Limit” and “reduce costs”, allowing the block to put more (rollup) transactions into it.But EIP-4844 is also paving the way for the real expansion plan – Danksharding.

In addition, Blob Fair and General Fair are separate and independent fee markets, each with their own Base Fee and Priority Fee. Therefore, EIP-7516 adds a BLOBBASEFEE Opcode to the fee market for Blob Fair (the function is equivalent to BASEFEE of general transactions).Opcode), let the Rollup contract know what the Base Fee of the Blob is through this Opcode.

Summary and focus

The Dencun hard fork consists of the Deneb hard fork of the consensus layer and the Cancun hard fork of 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 pave the way for Danksharding.
Changes to the consensus layer include EIP-7044, EIP-7045 and EIP-7514.
EIP-7044 allows validators using unmanaged staked services to avoid future hard forks when opting out of PoS.
EIP-7045 and EIP-7514 can be regarded as updates that increase the stability of PoS network.
Changes to the execution layer include EIP-1153, EIP-4788, EIP-5656, EIP-6780 and EIP-7516.
EIP-1153 allows many contract design models to save a lot of Gas; EIP-5656 also allows Gas to be slightly reduced.
EIP-4788 allows the execution layer to read the consensus layer information in a way that does not require trusting third parties, enabling more possibilities for staking related services.
EIP-6780 further eliminates SELFDESTRUCT and removes its ability to “remove contract codes and statuses”.
Developers need to pay attention to the assumption that “temporary Storage will be cleared after transactions” when using EIP-1153, and be sure to pay attention to whether your contract will be affected if it is affected.
Ordinary users do not need to pay special attention. Just wait until Rollup uses Blob to trade and you can enjoy lower transaction costs.

Reference data and recommended extended reading

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

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