What is Ethereum Dencun upgrade?
Currently scheduled to be completed on March 13, 2024, the Dencun upgrade is an update designed in line with the Ethereum 2.0 roadmap.
What does Dencun mean?
Ethereum update names are often stellar names, and cities host community events known as Devcon.
In this case, Dencun is a combination of the star Deneb and the city of Cancun.
When will Dencun's upgrade take effect?
Prior to full integration, Ethereum updates are on Testnet networks as part of various applications.
The Dencun update was integrated into the Goerli Testnet on January 17, 2024, into Sepolia on January 31, 2024, and into the Holesky Testnet in February 2024.
The integration of the update into the Ethereum network is expected to be completed on March 13, 2024.
What does Ethereum Dencun offer?
The Dencun upgrade is set to be integrated into the network via the hard fork method. Includes proposed amendments EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780, EIP-7044, EIP-7045, and EIP-7514.
Applications running on the Ethereum blockchain and Layer 2 infrastructures connected to the Ethereum network use a function called ‘CallData’ when sending transactions to Ethereum. Due to its high demand, this function can incur high transaction fees, increasing the cost for platforms.
EIP-4844 aims to integrate a new transaction type called Blob into the Ethereum network to solve this problem. Blob is not a typical Ethereum transaction and is much smaller (128 kb). It exists off-chain, but it can synchronize with the Ethereum blockchain using an embedded reference code.
Blob transactions require different transaction type, called Blob-Carrying, in order to add their data to blocks on the Ethereum blockchain. Blob-Carrying transactions hold data associated with the Blob they represent. Thus, validators on the Ethereum network can read this off-chain data and verify their accuracy. Without Blob-Carrying, Blob transactions cannot synchronize with Ethereum.
Since it’s possible to store data externally and bring it onto the Ethereum blockchain via Blob, Layer 2 infrastructures are expected to utilise Blob transactions. This creates a secondary alternative alongside the CallData function, aiming to reduce the fees that platforms pay on the Ethereum blockchain.
Fee information for Blob transactions is contained within Blob-Carrying transactions. Validators prioritize Blob-Carrying transactions for inclusion in blocks based on the highest to lowest fee. This is expected to create a separate price and competition mechanism for the fee for Blob transactions.
Blob transactions are not exclusive to Layer 2 platforms. Other platforms may also choose to use Blob transactions.
EIP-4844 aims to reduce costs for both applications on the Ethereum network and Layer 2 infrastructure.
EIP-1153 introduces a new feature called Transient Storage. This feature facilitates communication between layers using temporary data. Since Transient Storage data is temporary, it does not occupy space on the network after the transaction. Thus, it aims to enable multi-layered transactions with lower fees while avoiding additional data burdens on the network.
EIP-4788:
Applications utilizing the Ethereum blockchain must constantly verify whether the validators, who confirm the accuracy of transactions, have reached consensus among themselves. If consensus is achieved, it indicates that the data on the blockchain is reliable and there are no issues.
To obtain this confirmation, hash codes linking blocks must be conveyed to the applications. However, on Ethereum, the layer that executes transactions and the layer achieving consensus are separate.
The data communication between these two synchronized layers may not always be sufficiently fast for applications.
Applications on the Ethereum blockchain rely on data centers, called Oracles, to ascertain the consensus status faster. Applications tend to work with multiple Oracles to avoid overreliance on a single center, and EIP-4788 has been developed to address the potential risks created by this situation.
Following EIP-4788, the required hash code will be automatically broadcasted in the consensus layer, and a separate smart contract containing all these hash codes will be created. This is aimed at reducing the dependency of applications wanting to confirm the consensus status of the Ethereum blockchain on Oracle services. This development is expected to be positive for the security and sustainability of both the Ethereum blockchain and for the applications using it.
EIP-5656:
Aiming to enhance the efficiency of data structures in blocks on the Ethereum blockchain, EIP-5656 introduces a new function called MCOPY. This function is designed to accomplish the task currently performed by the existing code for copying data with a single code. Consequently, it is expected that transaction fees will be reduced due to the use of fewer functions.
EIP-6780:
The existing SELFDESTRUCT function on the Ethereum blockchain is designed for developers to remove erroneous or unnecessary data from the network. However, mistakes made by developers have shown that misuse of this function could lead to unwanted consequences in the future.
EIP-6780 aims to reduce the impact of the SELFDESTRUCT function. Following the update, having a reference to this function in contracts will be crucial. Contracts created with a reference to it can continue to use this function. However, in contracts created without a reference, the function will not be operational. Contracts written before the update will continue to function as before without any changes.
The reason for not completely removing the SELFDESTRUCT function is to provide flexibility to developers. It is expected that with the subsequent integration into the network, the Verkle Tree will render this function completely obsolete.
EIP-7044:
After Ethereum 2.0, it became possible to contribute to the security of the blockchain and, in return earn passive income by staking ETH on the network. Since the staking process can be complex and risky for users without technical knowledge, infrastructure has been developed to automate this process.
Users wishing to stake ETH must trust an intermediary (middleman) to manage the balance they want to stake when using these services. To address trust issues, the ‘signing key’ required to manage locked tokens on the network is stored in the middleman’s wallet and the key needed to withdraw locked ETH is kept in the user’s wallet. Thus, the user retains the authority to withdraw tokens back to the wallet.
Despite this system, additional developments are needed to address trust issues. When a user uses their key to withdraw locked tokens, the intermediary must first accept this request and initiate the withdrawal request for the locked tokens on the blockchain. To mitigate the risk of the intermediary refusing or not initiating transactions, an additional mechanism has been created.
This mechanism involves transferring withdrawal requests, pre-signed by intermediary, to the user when transferring locked tokens. Because of this, even if the intermediary does not acknowledge the transaction, the user has a pre-signed transaction request with the intermediary’s key and can reclaim their locked tokens.
EIP-7044 aims to ensure that these pre-signed approvals provided to users continue to be effective after the Dencun update. Since the Dencun update will be integrated into the network through a hard fork, such approvals would typically lose their functionality. EIP-7044 aims to prevent users from being disadvantaged and platforms from running into issues.
EIP-7045:
Validators on the Ethereum blockchain take on the task of processing transactions into blocks and adding blocks to a chain. Validators vote on confirmed transactions and blocks. When selecting the next block, the block with the most approvals is chosen.
EIP-7045 introduces an additional voting right for the validators determining the next block. This allows for a broader selection of the block with the highest votes as the number of approvals increases. The expansion of the selection pool is aimed at increasing the speed of block selection, thus enhancing the network’s speed.
On the Ethereum network, each section of 32 blocks is referred to as an Epoch, and timings are typically defined in terms of Epochs. To explain this update in terms of Epochs, validators, who typically have 32 voting rights per Epoch, can, if desired, have 64 votes per Epoch after the update.
EIP-7514:
New validators wishing to join the network to validate transactions on the Ethereum blockchain must wait for the next Epoch. A minimum of 3 new validators can participate in the process in each Epoch. The upper limit gradually increases and has no defined ceiling.
While having a large number of validators enhances the decentralization of the network and the accuracy of data, massive increases in the number of validators can bloat the network and lead to complexities.
EIP-7514 aims to limit the number of validators that can participate in the process in each Epoch to eight. Thus, the current upper limit increase will not be allowed and the increase in validators within the Epoch are kept within predictable limits. The goal is to anticipate potential complexities in the network in advance and take necessary capacity-related measures when needed.
