Ethereum’s core devs are already approaching another major upgrade to mainnet. This upgrade will center on Ethereum Improvement Proposal #4844 (EIP-4844). They’ve designated a new portmanteau,” to refer to this upgrade (combining “Deneb” and “Cancun,” for updates to the consensus and execution layers, respectively).
Shapella ??
It's live! It works! Despite a few minor issues around the upgrade activation, less than a month later, we now take for granted that withdrawals get processed smoothly on Ethereum ??
Onto the next thing ??
Dencun ???
The last AllCoreDevs update came out when Shapella was mostly spec'ed out, but still had many moving parts. After I published it, and specs were finalized, moved to the EF blog, which now has email subscriptions for protocol announcements
This update is of a similar nature: we currently have a tentative set of EIPs included in the next network upgrade, Dencun (Deneb + Cancun). I'll give an overview of what they are, why they matter, as well as the candidate EIPs still being considered for the upgrade.
Note that this will mostly focus on Ethereum's execution layer --- there are likely more things being considered on the CL that I've missed. Optimistically, I'd like to publish another update once we've finalized Dencun's scope. Realistically, that will probably be the first testnet fork announcement ?? Let's dive into it!
Included EIPs
EIP-4844, a.k.a. Proto-Danksharding
This one needs no introduction: 4844 is the core feature of the Dencun network upgrade. In short, this EIP introduces temporary "data blobs" to the Ethereum network, which L2s can use to post the transaction/proof data they currently store in CALLDATA
Due to blobs being stored ephemerally, their gas cost is expected to be significantly lower than CALLDATA, which is stored by the network forever. This will result in significantly cheaper L2 transactions for users, as >90% of the current cost for L2 transactions is L1 data storage. If you'd like to dig deeper in 4844, eip4844.com has various levels of explainers/FAQs/etc.
While not quite as big as The Merge, EIP-4844 is a significant change to Ethereum: it introduces an whole new data layer to the network, which both the current consensus and execution layers must interact with. The size of the EIP means that bandwidth for other changes in Dencun is limited.
That said, a few more EIPs have also been included alongside 4844.
EIP-4844 may bring down transaction costs on mainnet, but its focus is on reducing fees for Ethereum’s second layers (see my post here about L2s). To accomplish this, this EIP's approach is all about data. The EIP will improve the way in which L2s encode data on mainnet. L2s currently devote much of their fees to writing to Ethereum mainnet for validating their ledgers (using transaction calldata). This also increases fees on mainnet. You can see this on Etherscan’s “gas guzzler” . 5%–10% of mainnet fees are often related to L2s, such as zkSync and Arbitrum.
EIP-6780, SELFDESTRUCT deactivation, except if coupled with contract creation
The second major change being introduced in Dencun is the deactivation of the SELFDESTRUCT opcode with EIP-6780. This comes after years of discussions, as well as a formal deprecation notice in Shapella.
During some recent analyses, a common usage pattern for SELFDESTRUCT was identified: contracts being created and destroyed within a single transaction. EIP-6780 allows this functionality to be maintained. If SELFDESTRUCT is called in the same transaction as a contract's creation, then its behaviour remains the same as today.
In all other cases, though, the opcode will delete the contract's storage or code. ETH in the contract will still be transferred to the target address, though.
While client teams currently think this is the best approach to deal with SELFDESTRUCT, a more thorough impact analysis is still underway. Once that is done, the specification may be modified to deal with other edge cases. A different approach altogether may also be taken. For example, EIP-6046 was also considered.
In other words, SELFDESTRUCT removal is now a question of , for Deneb.
EIP-1153, transient storage
The third change included in Dencun is EIP-1153. Proposed nearly five years ago, and revived last year by the Uniswap team, the EIP has gathered significant support amongst Ethereum's developer community. It introduces two new opcodes, , which provide ransient storage that gets cleared at the end of the transaction. The EIP enables several use cases, from re-entry locks to single-transaction ERC20 approvals.
EIP-1153 was also considered for the Shapella upgrade, but ultimately deprioritized. This time around, client teams agreed to move forward with it. It's worth emphasizing that beyond the general soundness + usefulness of the EIP, one contributing factor to 1153's inclusion was the excellent technical championing work done: Uniswap and others provided full 1153 reference implementations and comprehensive test cases for all execution layer clients.
EIP-6475: SSZ Optionals
This last included change can be thought of as a companion to EIP-4844. Proto-danksharding introduces a new transaction type that uses SSZ encoding, rather than RLP encoding, which is used by the rest of the transaction types.
There have long been discussions of moving Ethereum's execution layer over to SSZ completely, as it is a richer encoding structure and is used by the consensus layer, but this is currently out of scope for Deneb. EIP-6475 defines one of the SSZ elements that's part of the 4844 transaction format (Optionals) to ensure it is forward-compatible with future SSZ objects we'd want to introduce to Ethereum.
As discussions about both the best long term SSZ formats for transaction generally and 4844 blob transactions specifically continue, expect modifications to happen to both of these EIPs.
EIPs Considered for Inclusion
Aside from the EIPs formally included in the upgrade, client teams have a shortlist of EIPs that may still make it in.
EIP-2537: Precompile for BLS12-381 curve operations
This EIP has been considered in one form or since 2019. Historically, there was reluctance to add a new cryptographic curve to Ethereum's execution layer. That said, the Beacon Chain relies heavily on BLS12-381, and with The Merge behind us, it's fair to say that BLS has become a "core" dependency of Ethereum, with secure and optimized libraries.
Introducing this precompile would be allow for both Beacon Chain signatures to be validated on the EL as well as the development of new use cases leveraging this curve.
EIP-4788: Beacon block root in the EVM
Similarly to 2537, this EIP exposes information from the Beacon Chain to the execution layer. In this case, the root of Beacon Chain blocks is added to execution payloads and then stored in a contract on the EL. The stored Beacon block roots can then be accessed via a new BEACON_ROOT opcode, which takes a slot number as input and returns the associated Beacon block root.
This EIP would allow for more trustless designs of staking pools, bridges, and restaking protocols.
EIP-6493: SSZ Transaction Signature Scheme
This EIP is a complement to EIP-6475: it defines a signature scheme for SSZ transactions. While it wouldn't apply to existing RLP transactions, it could be used to ensure the current 4844 SSZ transaction signature scheme is forward-compatible with a future SSZ overhaul of the execution layer.
Notable exclusion: EOF
After being CFI'd for both the Shapella and Dencun upgrades, the suite of EOF EIPs was formally pushed out of this upgrade as well, due to limited bandwidth. There is currently some discussion of prioritizing these as the "main feature" for a future upgrade, but this has not been formally agreed to by client teams.
Other Proposed EIPs
Aside from these, the full list of proposed EIPs for the upgrade can be found on Ethereum Magicians. While it's likely that most things that end up in Dencun have already been discussed, surprises are possible! Notably, teams reacted positively when first learning of EIP-5656, proposing an opcode, on the last ACDE call.
Network Upgrade Activations EIP ??
PSA: I've drafted an Informational EIP to list the various mechanisms used to trigger network upgrades over time, from proof-of-work blocks, to epochs, TTDs, and now timestamps.
Hopefully, we don't have to change from the current epoch+timestamp combo ever again ??
Summer (Remote) Talks ??
Over the next few months, I'll be giving a few talks sharing my view of how Ethereum's governance process works. Some will be IRL, some remote, some TBD! Chronologically, I'll be speaking at ETHPrague, ETHShanghai, ETHMontreal
