Ethereum is steadily progressing towards its next network upgrade, Dencun (Deneb on CL and Cancun on EL) after the successful conclusion of Shapella Upgrade earlier this year. After months of discussions, the Core Developers have finalized the specifications for the network upgrade expected in Q4 2023. Ethereum devs will soon release a comprehensive specs document that includes test vectors for the Dencun upgrade. Let's take a look at the CFI'd EIPs and specs changes with Dencun upgrade.
Cancun EIPs
EIP-1153: Transient storage opcodes
Transient storage involves the process of utilizing an empty storage slot, writing a value to it, and subsequently clearing it, all within a single transaction. This technique eliminates the need to store any data on disk.
In Ethereum, EIP-1153: Transient storage opcodes introduces the concept of transient storage, which allows for the temporary usage of storage during a transaction's execution. As part of this enhancement, two new opcodes have been introduced. These opcodes function similarly to storage but come with significantly reduced gas prices. Additionally, they do not involve complex refund logic, as they do not necessitate reading from or writing to the state trie. It is worth noting that these operations are typically the most costly for a node to perform.
For those seeking a more in-depth understanding of transient storage and its implications, the EtherWorld Team has developed a comprehensive blog guide.
EIP-4788: Beacon block root in the EVM
Aftewr a long discussion and multiple back and forth, EIP-4788 got a place in the Cancun specs.
The objective of EIP-4788: Beacon block root in the EVM is to minimize the reliance on trust assumptions made by staking pools. Furthermore, it offers extensive support for diverse use cases that enhance restaking constructions, smart contract bridges, MEV mitigations, and other functionalities. This EIP proposes the storage of cryptographic accumulators, referred to as roots, of the blocks in the beacon chain within the EVM.
As per the recent updates provided by Alex Stokes, the author of the EIP, there is a draft PR which aims to limit the storage growth in Ethereum by introducing the use of two ring buffers. The proposal suggests adopting ring buffers as a standardized method for queuing data in a fixed-length array, adhering to a first-in, first-out approach. The developers have reached a consensus to implement this solution in order to mitigate the storage requirements of the precompile responsible for storing Beacon Roots and timestamps.
EIP-4844: Shard Blob Transactions
Blob transactions are a new type of transaction introduced in Ethereum through EIP-4844: Shard Blob Transactions as part of the Dencun upgrade. These transactions are designed to handle more complex and larger data structures, which allows Ethereum to support a wider range of applications and use cases. EIP-4844 introduces transactions with 128KB ephemeral data blobs, which are dropped after 3 weeks, resulting in zero long-term storage usage.
EIP-5656: MCOPY - Memory copying instruction
EIP-5656: MCOPY - Memory copying instruction proposes the introduction of a new instruction called MCOPY in the EVM. This instruction is designed to efficiently copy memory areas within the EVM. The motivation behind this proposal is to address the overhead involved in memory copying operations on the EVM. The proposed MCOPY instruction aims to provide a more efficient solution for memory copying on the EVM. It has a gas cost of 27, which is significantly lower compared to existing methods.
EIP-6780: SELFDESTRUCT only in same transaction
EIP-6780: SELFDESTRUCT only in same transaction seeks to eliminate the usage of SELFDESTRUCT in Ethereum. We highly recommend watching this video to follow alternate proposals related to SELFDESTRUCT.
Deneb EIPs
For the first time, Consensus Specs include EIPs for an upgrade.
EIP-7044: Lock voluntary exit domain on Capella
This EIP is intended to enhance the staking user experience. Currently, when a validator signs an exit, it is only valid for two forks. However, this EIP ensures that the signed exit remains valid indefinitely. This change is backward compatible with previous versions and provides a more convenient staking experience.
EIP-7045: Increase maximum attestation inclusion slots
This EIP proposes expanding the range of attestation slots from one epoch to two epochs. This means that attestation slots will now include the current epoch and the next epoch. Additionally, it suggests making adjustments to the p2p gossip conditions to accommodate this modification.
Engine API Changes
Engine API is an interface that is used for communication between Consensus Layer and Execution Layer.
The Engine API in Dencun is also expecting some changes with the upgrade. With the activation of EIP 4844, two new methods, engine_newPayloadV3 and engine_getPayloadV3, have been introduced to facilitate blob transactions and the proposal included to deprecate the earlier warning message.
Previously, clients utilized the engine_exchangeTransitionConfiguration method to exchange merge-related information. However, as the merge process is now complete, it is logical to remove this method. All EL clients have already removed it, while CL clients have yet to implement this change. Mikhail Kalinin proposed a process guide to bring this change on EL and CL clients.
Here is a video by EW Team on The Merge Transition for the better understanding of the Engine API.
Additional Changes in Dencun specs
Up to this point, we have thoroughly discussed both finalized EIPs and those under discussion. Now, let's shift our focus to some Merged PRs in the Dencun Upgrade.
This PR suggests an update to the Ethereum precompile address. The developers have reached a consensus to adopt the next available address following a hexadecimal naming convention. The purpose of this update is to address the issue of the non-compact arrangement of the precompile address for EIP-4844. Initially, the subsequent address was reserved for the BLS precompile, intended to be introduced through EIP-2537. However, EIP 2537 will not be prioritized for Dencun.
Precompiles in Ethereum facilitate the efficient utilization of cryptographic and signature libraries by smart contract developers. Presently, there are nine precompiles in the Ethereum Virtual Machine (EVM), and two additional ones will be incorporated with the addresses 0xA and 0xB through the activation of EIP 4844 and EIP 4788, respectively.
If our readers are interested in learning more about EIP-2357 and Precompile, we invite them to explore the EW team's blog guide on Exploring EVMMAX Proposals and BLS12-381.
This PR updates the size limit for a specific data field called blob_kzg_commitments in a block. The PR introduces a new field called max_blob_commitments_per_block that allows for changing the maximum number of blobs (a type of transaction) that can be included in a block. This change provides more flexibility to the protocol and simplifies the process of updating the maximum number of blobs per block by only requiring an update to the execution layer.
This PR adds blob versioned hashes as a second parameter to engine_newPayloadV3 as per the discussion here.
The PR makes changes to the beacon chain by introducing new wrappers and extending the Engine API request. It includes an abstract data class and wrappers for verifying and notifying new payloads. The PR also modifies the argument passed to process_execution_payload in Bellatrix to include versioned hashes for validation. Additionally, it removes the process_blob_kzg_commitments function and updates the validator.md file by removing the validate_blobs_and_kzg_commitments section.
This PR updates the way subnets are specified in the code. Previously, the number of subnets was tied to the maximum number of blobs per block. With this change, the number of subnets will be determined by a new variable called blob_sidecar_subnet_count. This allows for more flexibility because now we can adjust the maximum blobs per block without needing to modify the peer-to-peer network structure and the arrangement of blob subnets. Essentially, this PR ensures that changes to the maximum blobs per block won't affect the network structure.
This PR changes the ordering of the data from little-endian to big-endian. This means that the output will now be organized in a way that follows big-endian conventions, ensuring consistency. The developers have agreed that for all instances of EIP 4844, the default data storage ordering should be big-endian.
Should you be interested in following Dencun upgrade closely, checkout our curated resource list.
Related Articles
- Mitigating Ethereum Chain re-org scenario with Deneb Upgrade
- Preventing Slashed Validators from Becoming Block Proposers
- '0-Blob Txns' Omitted from EIP-4844 in Cancun Upgrade
- 4844 Specs Include KZG Multi-Verify Function
- Upcoming Changes to Ethereum Blockchain
Related Videos
- SELFDESTRUCT: History, EIPs, Future
- SELFDESTRUCT in Smart Contract: Use Cases
- Coinbase International Exchange, Chain Reorg EIP-4844, Digital Yuan & More - #WEB3Today #34
- ETH Withdrawals: Everything You Need to Know
- Ethereum Transaction Lifecycle
YouTube
Disclaimer: The information contained in this website is for general informational purposes only. The content provided on this website, including articles, blog posts, opinions, and analysis related to blockchain technology and cryptocurrencies, is not intended as financial or investment advice. The website and its content should not be relied upon for making financial decisions. Read full disclaimer and privacy Policy.
For Press Releases, project updates and guest posts publishing with us, email to contact@etherworld.co.
Subscribe to EtherWorld YouTube channel for ELI5 content.
Share if you like the content. Donate at avarch.eth or Gitcoin
You've something to share with the blockchain community, join us on Discord!
