Ethereum Cancun-Deneb Hard Fork Countdown and Date (Dencun)
The Ethereum upgrade named Cancun-Deneb, also known as 'Dencun,' was activated on March 13, 2024.
Dencun EIPs
- EIP-1153: Transient storage opcodes
store data, delete at end of txn -> cheaperstore data, delete at end of txn -> cheaper - EIP-4788: Beacon block root in the EVM
add data beacon data chain in EVM, less trust assumption for staking poolsadd data beacon data chain in EVM, less trust assumption for staking pools - EIP-4844: Shard Blob Transactions
store data, delete after 3 weeks, cheaper rollup txnsstore data, delete after 3 weeks, cheaper rollup txns - EIP-5656: MCOPY - Memory copying instruction
cool new opcodecool new opcode - EIP-6780: SELFDESTRUCT only in same transaction
remove SELFDESTRUCT, reduce breakageremove SELFDESTRUCT, reduce breakage
Q&A
What is Rollup and what is it for?
Rollups offer a solution for enhancing the scalability of Ethereum through the consolidation of transactions off-chain, followed by their subsequent submission to the Ethereum network. A rollup consists of two fundamental components: data and execution check. The data encompasses the complete sequence of transactions processed within a rollup, resulting in the state change that is ultimately posted to Ethereum. On the other hand, the execution check entails the re-execution of these transactions by an honest participant known as a "prover," whose role is to verify the accuracy of the proposed state change. To facilitate the execution check, the transaction data must remain accessible for a sufficient duration to allow anyone to download and verify it. This ensures that any dishonest actions carried out by the rollup sequencer can be detected and challenged by the prover. However, it is not necessary for the transaction data to be available indefinitely.
What is EIP-4844?
Proto-Danksharding and Danksharding are essential for Ethereum to achieve true scalability, necessitating various protocol upgrades. Proto-Danksharding serves as an intermediary phase in this process, paving the way for the ultimate goal. The primary objective of both approaches is to significantly reduce transaction costs for users on Layer 2 while enabling Ethereum to scale to over 100,000 transactions per second.
When will the DENCUN hard fork be activated on the Ethereum network?
The DENCUN hard fork on the Ethereum network will be activated at epoch's starting slot 8626176, with the corresponding timestamp being 1710338135 (March 13, 2024).
On ACDC#127 we agreed to schedule Dencun's mainnet activation for epoch269568. I used https://slots.symphonious.net to confirm that the epoch's starting slot is8626176, which is an historical accumulator boundary (8626176 % 8192 = 0), and the corresponding timestamp is1710338135. At least one person should independently validate those numbers before we merge this 😄
| Network | epoch (slot) | Timestamp | Date |
|---|---|---|---|
| Goerli | 231680 | 1705473120 | 17 January 2024 |
| Sepolia | 132608 | 1706655072 | 30 January 2024 |
| Holešky | 29696 | 1707305664 | 7 February 2024 |
| Mainnet | 269568 (8626176) | 1710338135 | 13 March 2024 |
What is the cost advantage of using blobs in rollups?
Rollups offer a method for increasing the scalability of Ethereum by consolidating transactions off-chain and subsequently submitting the results to the Ethereum network. A rollup consists of two primary components: data and execution check. The data represents the complete sequence of transactions processed within a rollup, resulting in the state change that is posted to Ethereum. The execution check involves re-executing these transactions by an honest participant known as a "prover" to verify the accuracy of the proposed state change. To enable the execution check, the transaction data must remain accessible for a sufficient duration to allow anyone to download and verify it. This ensures that any fraudulent actions performed by the rollup sequencer can be detected and challenged by the prover. However, it is not necessary for the data to remain available indefinitely.
Blob Lifecycle
Blob transactions
Possibly delayed until the Cancun hard fork, but already in full development is the support for blob transactions (aka 4844), which would allow the Ethereum network to create huge transactions (128KB a pop) that only have an ephemeral lifespan (2-4 weeks). The purpose of these transactions would be to allow layer 2 solutions to commit to and prove large batches of data very cheaply, without incurring an indefinite storage cost on all full nodes. This should make L2s significantly cheaper and thus allow Ethereum to - hopefully - onboard the next stream of users. This work has been pioneered by Coinbase's Jessie and team and is currently being picked up by Peter to integrate where possible and reimplement where Geth's DoS requirements require a different approach from the original PoC work.
