Welcome to another AllCoreDevs update 👋 

Over the past six months or so, teams have been focused on Dencun, the next Ethereum upgrade, as well as some EIP process tweaks. This post covers both these topics, and briefly touches on planning for the upgrade.

TL;DR 👀

• Dencun testnets 🔜

  • The upgrade is in its final testing stages, with testnet upgrades expected to begin early next year.

• There’s more than danksharding in Dencun: EIP-7569 has the full list, and this post summarizes every included EIP ✅

• Many EIP process changes: CL EIPs, Meta EIPs, and the separation of EIPs, ERCs and RIPs 🪦

• Prague/Electra proposals are slowly rolling in, planning will kick off in January 📆

Dencun 🏝️

The blobs are coming!

What was hopefully the last big spec change for Dencun is now being tested on multi-client devnets. Shadow forks are up next, and testnets upgrades are expected to begin in January!

Dencun ended up being, in true Ethereum fashion, more complicated than expected. Introducing a whole new data layer to the network and testing its robustness in conditions we can’t easily replicate outside of mainnet has been quite the challenge. 14 months after the first 4844 interop call, and with a huge ramp up in the quantity and quality of our testing apparatus, we now see light at the end of the tunnel 🌞

Also, although they haven’t had as much of a spotlight on them, the Dencun upgrade introduces many other changes along with proto-danksharding. You can find the full list in EIP-7659:

• EIP-1153: Transient storage opcodes

• EIP-4788: Beacon block root in the EVM

• EIP-4844: Shard Blob Transactions

• EIP-5656: MCOPY - Memory copying instruction

• EIP-6780: SELFDESTRUCT only in same transaction

• EIP-7044: Perpetually Valid Signed Voluntary Exits

• EIP-7045: Increase Max Attestation Inclusion Slot

• EIP-7514: Add Max Epoch Churn Limit

• EIP-7516: BLOBBASEFEE opcode

I’ll briefly summarize each one below. For a deep dive into them, I recommend Ethereum Cat Herders’ PEEPanEIP series, which has in-depth conversations with EIP authors about their proposals.

EIP-1153

This EIP introduces two EVM opcodes, TLOAD and TSTORE. They load/store data similarly to SLOAD and SSTORE, but clear it at the end of each transaction, rather than store in Ethereum’s global state. Because the data never needs to be written to disk, these new opcodes have same gas cost as using SLOAD or SSTORE with “warm” data. PEEPanEIP #91 covers EIP-1153.

EIP-4788

4788 exposes the Beacon Chain’s block roots to the EVM by storing them in a smart contract on the execution layer. The roots are included in blocks passed from the CL to the EL, and written to a contract prior to executing the block’s transactions. Applications can use the block roots to validate proofs about Beacon Chain data directly onchain. Alex Stokes appeared on PEEPanEIP#117 to explain all of this more thoroughly.

EIP-4844

Also known as “proto-danksharding”, this one has a whole website about it :-)

EIP-5656

Another new EVM opcode, MCOPY, provides a simpler and cheaper way to copy memory in the EVM. This will be especially useful to higher level languages and EVM tooling, which both have to consider multiple edge cases around memory copying today. More on PEEPanEIP#118.

EIP-6780

SELFDESTRUCT removal (!!), with caveats*

After years of debate around if and how to remove SELFDESTRUCT, it’s finally happening! Following Ethereum’s first deprecation notice in Shanghai, EIP-6780 updates the SELFDESTRUCT opcode semantics to only delete a contract if the opcode is called within the same transaction as the contract creation. In all other cases, SELFDESTRUCT will simply transfer the funds in the contract to the target address and leave the contract intact. For a deep dive on this, see PEEPanEIP#115.

EIP-7044

This EIP removes restrictions on how long a validator exit message is valid for. Previously, after two network upgrades, an exit message would become invalid. Removing this constraint reduces the parameters that staking tools need to consider, and also allows for more permanent arrangement in staking operations where the signing and withdrawal key holders are different. This EIP was covered in PEEPanEIP#113.

EIP-7045

EIP-7045 increases the period during which an attestation can be included in a Beacon Chain block from a rolling 32 slots window until the last slot of the epoch after the one in which the slot occurred. In other words, it increases the inclusion window for attestations to a slot by the number of slots remaining in its epoch. For the last slot in an epoch, the change is minimal, but for the first, it effectively doubles the valid inclusion period. Danny Ryan discusses the change on PEEPanEIP#114.

EIP-7514

A somewhat contentious change, EIP-7514 adds a hard cap to how many validators can be activated each epoch. Previously, the amount varied as a function of the total number of active validators. Concerns about the rapid growth of the validator set, and the stress this puts on the network’s gossip layer, have led client teams to propose capping this value at 8 validators/epoch. PEEPanEIP#119 goes into more detail on this.

EIP-7516

Last but not least, EIP-7516 introduces one final new opcode: BLOBBASEFEE. Similarly to BASEFEE, the opcode returns the current 4844 data-gas base fee. This allows contracts to access this value directly onchain, providing a trustless oracle for L1 data gas costs, and can be the basis for more complex use cases, such as (blob) base fee futures. PEEPanEIP completes their full coverage of Dencun with episode 122 dedicated to this EIP.

EIP Process Changes 📋

In parallel to Dencun development, the EIP processes has recently seen many changes. Here is an overview of the most important ones:

CL EIPs

One thing you may have noticed in the section above is that all changes, including those to the consensus layer, are tied to an EIP! Indeed, while the bulk of specifications for CL changes are still in the consensus-specs repository, EIPs are now used to identify, describe, and motivate them. The CL spec can then be directly linked within an EIP. With this, and the introduction of an EL python spec, we’re getting close to a harmonized specification process :-)

Meta EIPs

Another thing you may have noticed: we’ve gone back to listing out all the changes included in a specific hard fork in (Meta) EIPs. Post-merge, network upgrades didn’t have a comprehensive list of changes across both the EL & CL, as both layers used separate processes to track them.

Not only did this lead to fragmentation, but the location of each list was also hard to find, and separate from the EIPs which contained the actual changes. Hopefully, bringing back Meta EIPs simplifies things a bit!

Dencun’s Meta EIP is EIP-7569, and EIP-7568 links out to the various specifications used for network upgrades that did not have a Meta EIP.

EIP/ERC/RIP Working Groups

The last, and most significant, change to happen to the EIP process over the past few months is its separation into Working Groups.

Historically, EIPs and ERCs used the same repository and processes. This made it hard to streamline and adapt things to the needs of either side. EIPs mostly describe protocol layer changes, a large chunk of which can only be activated if there is consensus amongst all stakeholders to do so. ERCs tend to describe opt-in application layer standards, which can be used without global agreement, and can be gradually adopted over time.

In addition to this, a standardization effort focused on Layer 2 — RollCall – has recently emerged. Rollup Improvement Proposals (RIPs) could allow L2s to coordinate on protocol changes they want to adopt independently of L1. Ideally, this reduces the risks of multiple L2s implementing the same feature in different ways, or different features in the same opcode or precompile space.

Both the ERC and RIP process could benefit from editors with domain knowledge. If you’d like to help shape how these things evolve, now is the time to reach out: head over to EIPIP!

Prague/Electra ⚡️

With Dencun wrapping up, attention has begun shifting towards the next upgrade: Prague/Electra. A discussion thread on EthMagicians has been started to aggregate suggestions for the upgrade.

Client teams will gradually begin reviewing proposals, and upgrade planning discussions will kick off in January. If you have an EIP you’d like to propose, now is the time to make it known !

Next Steps ✅

Dencun testnets 🔜, Prague/Electra planning will start in parallel, and, assuming things go smoothly, rollups will soon be moving their data to blobs and we’ll be debating whether the blob-gas limit on mainnet is high enough 😅 

Happy holidays 🎄