Next Milestone in the Ethereum Roadmap: The Dencun Hardfork
After the success of The Merge in September 2022 and the arrival of Shapella in April 2023 with EIP-4895, the next major update for Ethereum, known as The Surge, is set to begin with the Dencun Hardfork, slated for early 2024.
Context - A Progressing Roadmap
To provide some context, the development of Ethereum follows a roadmap developed by Vitalik Buterin, the co-founder of the project. As he recently published in December 2023, this roadmap consists of several "arcs", or major stages, each composed of smaller updates called EIPs (Ethereum Improvement Proposals).
As shown above, the roadmap consists of 6 "arcs", 6 distinct phases each with their own overarching goals. As mentioned earlier, the first Arc, named The Merge, was a success during 2022/2023, transitioning from a Proof of Work to a Proof of Stake consensus model. Today, it's The Surge's turn to make its entrance.
The main objective of The Surge is to enable rollups, the second layers of the Ethereum network (Layer 2), to be even more scalable, with a targeted capacity of 100,000 transactions per second. For reference, Ethereum currently processes about 15 transactions per second.
Specifically, this update will tackle the problem of data availability for Ethereum's Rollups in addition to preparing for blockchain sharding.
The Current Problem with Rollups
Before delving into this update, it's important to understand the problem it aims to solve.
As a reminder, rollups perform transactions off-chain to alleviate the Ethereum network, compressing them and then publishing them as a single transaction on the Ethereum blockchain, in a section called "calldata".
A classic Ethereum transaction is composed of several parts, including the call data part where the rollup transaction is brought in, encompassing all the transactions they have performed.
The issue with this method is twofold:
- Cost: Data stored in calldata are very expensive in terms of gas;
- Limited space: Calldata has a limited capacity, which inevitably restricts the scaling capabilities of rollups.
Considering these two problems, rollup transactions were more expensive and less scalable. One of the goals of The Surge update is therefore to improve the management and availability of data to make rollups more scalable and cheaper in terms of gas fees.
Explaining The Surge
In each arc proposed by Vitalik Buterin, there are several EIPs inside. You may know them; these EIPs are proposals for improvements to the Ethereum protocol that are then voted on by the Ethereum developer community.
This arc thus includes several updates that themselves comprise several EIPs. The name of the first update of The Surge is called Cancun-Deneb, respectively referring to the location of the 3rd Devcon edition and the brightest star in the constellation Cygnus. To simplify, the contraction Dencun has appeared to name this update.
To be more precise:
- Cancún: The update of the Ethereum execution layer;
- Deneb: The update of the Ethereum consensus layer.
This Cancun-Deneb or Dencun hard fork will introduce a total of 7 EIPs, including the highly anticipated EIP-4844 Proto-Danksharding.
EIP-1153: Transient Storage Opcodes: Introduces the concept of transient storage, allowing temporary use of storage during the execution of a transaction. This eliminates the need to store data on disk.
EIP-4788: Beacon Block Root in the EVM: Aims to minimize the trust assumptions made by staking pools.
EIP-5656: MCOPY – Memory Copying Instruction: Proposes the introduction of a new instruction, MCOPY, in the EVM to efficiently copy memory areas.
EIP-6780: SELFDESTRUCT Only in Same Transaction: Seeks to eliminate the use of SELFDESTRUCT in Ethereum.
EIP-7044: Lock Voluntary Exit Domain on Capella: Aims to improve the user experience of staking by ensuring that the signed exit remains valid indefinitely.
EIP-7045: Increase Maximum Attestation Inclusion Slots: Proposes to extend the range of attestation slots from one to two epochs.
And EIP 4844, which particularly interests us, allows rollup data to be stored as blobs.
As announced by Tim Beiko, one of the main developers of the Ethereum network, the first testnet of the Dencun update was successfully passed, and it was scheduled for January 17 on Goerli. We are now awaiting the second testnet deployments, which are set for January 30 on Sepolia and February 7 on Holesky.
Focus on EIP 4844 and Proto Danksharding
Why is this EIP more anticipated than others?
Specifically, it's in this EIP that the concept of Proto-danksharding is integrated. This somewhat barbaric word aims to partially solve the data availability problem for rollups. We call proto-danksharding a step before the danksharding. In the Proto-danksharding there is only 1 blob attached to the block but it will expand to 64 at the full realization of the rollup scaling (Danksharding). This EIP aims to make transactions on Layer 2 as cheap as possible for users and should scale Ethereum to >100,000 transactions per second. At the danksharding we might be able to see the million transaction per second a reality because the Ethereum network will be able to support hundreds of rollups.
The goal is to replace the currently used calldata with blobs. A blob is a large-sized computer object (~125 KB) that enables data storage. These blobs are introduced by EIP 4844, or proto danksharding, and they aim to ensure data availability while drastically reducing the cost of publishing proofs on Ethereum.
The two major advantages of blobs are as follows:
- Inaccessible to the EVM: The data is not processed by the network nodes, thereby not consuming gas;
- Limited storage duration: These data are kept on the chain for a defined period, between one and three months, preventing an indefinite increase in the size of the blockchain.
The implementation of this EIP will thus reduce the costs of rollups since the data will no longer be processed by the nodes, and also in terms of scalability due to the greater storage capacity of blobs compared to calldata.
KZG, verify integrity of data
Now we know the data availability is good, but we need to ensure the integrity of this data.
When a rollup publishes its data in a blob, it also publishes a commitment to the data's integrity. To verify this data, there is a method named KZG for verifying this commitment.
KZG stands for Kate-Zaverucha-Goldberg - the names of the three original authors of a scheme that reduces a blob of data down to a small cryptographic 'commitment'.
The blob of data submitted by a rollup must be verified to ensure the rollup is not misbehaving. On the technical side, KZG is an alternative proof that fits a polynomial equation to the data. The commitment involves evaluating the polynomial at some secret data points. A prover would fit the same polynomial over the data and evaluate it at the same values, checking that the result is the same. This is a way to verify the data that is compatible with zero-knowledge techniques used by some rollups and potentially other parts of the Ethereum protocol.
Finally, the implementation of KZG requires a 'KZG ceremony'. This is an event where the Ethereum community collaborates to generate a secret chain of random numbers. (important for data verification)
Now, let's talk about Verkle Trees, which are a testnet innovation originating from the Ethereum development team. This concept aims to reduce the size of blocks and improve network synchronization, similar to what EIP 4844 accomplishes. It is not a part of the DenCun improvement, but it will help you understand the other two EIPs in this Proto-Danksharding improvement that we will present now.
The answer for verkle trees lies in the ability to build self-contained execution units. When you want to join the network after some period of time, you go by the process of the sync. You cannot access the state directly. The idea of the Verkle tree is to include in the block everything that you need to be able to download it.
Moreover, Verkle trees make the proof smaller and allow you to follow all the blocks, but you don’t need to download all the states. In a coming upgrade, you can define a state expiry. So you can delete some, piece of the state because the State of Ethereum is quite large. But if you want to use it again, you can simply provide the proof to resurrect the state.
Difference with the Merkle Patricia Tree
In opposite to Merkle Patricia tree, which uses the hash of all leaf and siblings to get a proof of the validity of the transactions in the block, the Verkle tree uses the Vector commitments. The issue with the hashing method in Merkle tree is based on a vector of values, if you just want to prove that one value is in that vector and you don't want to reveal so much data, you cannot just take the hash and the value to prove that this value is at this specific position in the source data. You need to pass the entire vector. The alternative is the vector commitment. You have your vector commitment and also the ability to find an "opening" which is a smaller payload of the data compared to the size of the vector. If you have the commitment, the opening and the data, you can prove that this data was at a specific position in the tree. You don't need to reveal all the data and then pass all the data.
It's much more lightweight compared to the method of the Merkle proof. In a Merkle tree that use a hash, you need to pass all the sibling of a given node along the path. Each node of the MPT has 15 siblings. For each level you need to pass the 15 siblings. You end up with a lot of data. In a MPT with 1000 leaves, it's roughly 3MB of data. In the Verkle tree you have only 150KB of data for the same amount of leaves.
EIP-6780 SELFDESTRUCT (Technical)
To explain this EIP, if the contract calls selfdestruct in the same transaction as the contract creation, then the behaviour does not change at all.
- The funds are sent to the target
- Code and storage are deleted
- Nonce is reset to 0
But if the selfdestruct is called outside the contract creation transaction, then the behaviour is that of SENDALL. Which means:
- Funds are sent to the target address
- Nonce, code and storage are kept as it.
Anyway, the SELFDESTRUCT opcode is deprecated from the EIP-6049 and it has been strongly discouraged to use this opcode in newly deployed contract. "Changes to the EVM might further reduce the functionality of the opcode."
History behind SELFDESTRUCT
SELFDESTRUCT known before as SUICIDE was introduced in 2013 specification to prevent the state from containing unnecessary data and encourage the state cleanup. The initial concept was that EOA will be automatically destroyed when the balance reaches 0 and smart contracts can also contain a SELFDESTRUCT clause to delete themselves when no longer needed. But in 2014 a vulnerability has been identified for EOA that were exposed to a replay attack. This issue has been resolved with the introduction of the "Nonce". The addition of nonce has eliminated the possibility of deleting EOA since none cannot be reset to 0.
2016 DAO hack
In 2016 DAOs suffered a loss of more that 3 million ETH due to a massive hack. This attack persisted for many days since smart contracts are immutable and lacked for a destruction method. That was the period of the hardfork of the entire blockchain, leaving the old chain as ETC. To address this issue, SELFDESTRUCT was created as an existing door in case of a security threat.
Reasons for using SELFDESTRUCT in Smart contracts
1- Enhance security
Enable developers to address vulnerabilities and security flaws more effectively. If a security issue is identified, the contract can be destroyed and a new more secured version can be deployed.
2- Clean-up unused contracts
Overtime, some contract can be unused or obsolete. Selfdestruct can remove the contract from the blockchain and free up resources. This can help the maintenance of the overall health of the system.
3- Smart contract upgrades
Developers can terminate the existing contract and transfer its funds to another contract containing some new features or upgrades.
- Non deterministic: Deleting an account with a lot of storage can take a lot of time. But the gas cost is the same regardless of the amount of deleted data. If you delete a very large contract with tons of data you should not pay the same amount of gas as a very simple contract. In the worst case, you could run out of gas while deleting a contract so then you end up in an undefined state.
- Central Library: If you have a wallet management code that relies on a central library and you deployed a multitude of them, they would all rely on the same contract library. If for some reason, the self destruct is called on the library contract, all the deployed wallets that needed the library will cease to function and all the funds will be locked.
- Create2: With the existence of the instruction Create2 it allows for code mutability. For example, in a context of account abstraction, if we have a lot of users with their transactions, and they don't want to pay the gas cost of realizing all those transactions on chain, they go through a relayer that aggregate all the transaction and creates a package transaction to be applied to the wallet onchain. If a hack like Parity happens, the wallet is selfdestructed and the transactions are irrelevant. Or worst, someone could replace the selfdestructed wallet with another wallet that is for example used for extortion.
- Verkle: Instead of having one tree that contains all the accounts and each account has one subtree for all its storage slots, everything would be spread over one single tree and there is no way to map an account to its storage slots. Or reverse, given a storage slot, there is no easy way to find which account it belongs to. So if we delete the account, the rest of the slots remains in the tree because we cannot tell which slot belongs to which account. The consequence to this would be that if someone uses create2 to recreate this account, he would inherit all the slots that were there before. As I mentioned, the slots are not deleted when the account is deleted in the Verkle. An example is deleting a contract with the selfdestruct and recreate a new one that the user control to manage all the state or take over an ERC20 contract...
EIP-5656 MCOPY (Technical/Network optimisation)
This EIP isn't a huge upgrade of the EVM instructions. MCOPY is an instruction that helps copy some areas of the memory efficiently. This instruction takes 3 operands:
- The source index of the memory to be copied
- The destination index of the memory where the area will be copied to
- The size of the area
With these instructions, you can copy pretty much anything in the memory. For example, you can copy in a destination:
- That does not overlap with the source
- That can overlap with the source
- That is backwards from the source.
There is no restrictions. The regular gas cost is applied. So if the copying object extended the memory itself, the additional gas cost will be applied.
Copying a word in the EVM can be accomplished by the instruction MLOAD and MSTORE. MLOAD will get the data from the memory address while MSTORE will save the data to an address. These instructions will cost 12 gas per word. With MCOPY, the gas cost is reduced significantly.
In total, we have a gas cost of Gc=3+3*(words copied)+ memory expansion cost +(length to be copied/32). So for 256 bytes, MCOPY will use 27 gas whereas the previous method use at least 96 gas. Memory copying is used quite often in Solidity so we expect to see more usage of this instruction by the developer to improve both performance and cost.
The Surge is a big milestone to achieve and the second arc of the Ethereum roadmap. The efficiency and data availability will be better after the implementation of EIP-4844 (Proto-danksharding) to boost the scalability of rollups and reduce their fees.
We only talk about EIP-4844, 5656, and 6780, but the other four are also important for the smooth implementation of the Dencun improvement.
Colossos is a crypto banking solution that integrates allowing you to easily on and off-ramp with your EUR to send, receive, and exchange ETH and 35+ other cryptocurrencies.