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.
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 📆
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.
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.
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.
Also known as “proto-danksharding”, this one has a whole website about it :-)
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.
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.
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 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.
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.
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.
In parallel to Dencun development, the EIP processes has recently seen many changes. Here is an overview of the most important ones:
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 :-)
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.
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!
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 !
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 🎄
Tim BeikoProtocol Guild Pledge
Important caveats: This piece assumes context about Protocol Guild and narrowly focuses on its economic implications. For an introduction to PG, see Cheeky Gorilla’s EDCON talk. For a more philosophical read on its role, see Trent Van Epps’s article on Capital and Enclosure in Software Commons.A rough, quantitative framing of Protocol Guild’s mission is to make contributing to Ethereum L1 R&D economically rational on a risk-adjusted basis, while avoiding capture. With our pilot concluded and ...
Tim BeikoAllCoreDevs 2024 Recap & 2025 Outlook
As promised in my recent Pectra update, here’s a follow-up post covering this year’s changes to AllCoreDevs and what’s on the horizon for 2025 and beyond!ACD Process ImprovementsThe first small but important process change of 2024 came with Reth publishing their team’s preferences for the Pectra hard fork. Other execution and consensus layer client teams quickly adopted this written approach. While we had previously attempted to gather async input on upgrade scoping, Pectra marked the first t...
Tim BeikoAllCoreDevs Update 017: Pectra 🌌
As we close out the year, and with 12 months since the last one (!), I’m overdue for another AllCoreDevs update. This post details the evolution and scope of the Pectra network upgrade. Expect a follow-up 🔜 covering what’s after Pectra, as well as ACD’s evolution over the past year!PectraThis time last year, we began seriously discussing the scope for the Prague/Electra network upgrade, eventually portmanteaued into “Pectra”. Through the first few months of the year, as Dencun went live with...
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.
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 📆
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.
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.
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.
Also known as “proto-danksharding”, this one has a whole website about it :-)
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.
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.
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 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.
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.
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.
In parallel to Dencun development, the EIP processes has recently seen many changes. Here is an overview of the most important ones:
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 :-)
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.
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!
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 !
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 🎄
Tim BeikoProtocol Guild Pledge
Important caveats: This piece assumes context about Protocol Guild and narrowly focuses on its economic implications. For an introduction to PG, see Cheeky Gorilla’s EDCON talk. For a more philosophical read on its role, see Trent Van Epps’s article on Capital and Enclosure in Software Commons.A rough, quantitative framing of Protocol Guild’s mission is to make contributing to Ethereum L1 R&D economically rational on a risk-adjusted basis, while avoiding capture. With our pilot concluded and ...
Tim BeikoAllCoreDevs 2024 Recap & 2025 Outlook
As promised in my recent Pectra update, here’s a follow-up post covering this year’s changes to AllCoreDevs and what’s on the horizon for 2025 and beyond!ACD Process ImprovementsThe first small but important process change of 2024 came with Reth publishing their team’s preferences for the Pectra hard fork. Other execution and consensus layer client teams quickly adopted this written approach. While we had previously attempted to gather async input on upgrade scoping, Pectra marked the first t...
Tim BeikoAllCoreDevs Update 017: Pectra 🌌
As we close out the year, and with 12 months since the last one (!), I’m overdue for another AllCoreDevs update. This post details the evolution and scope of the Pectra network upgrade. Expect a follow-up 🔜 covering what’s after Pectra, as well as ACD’s evolution over the past year!PectraThis time last year, we began seriously discussing the scope for the Prague/Electra network upgrade, eventually portmanteaued into “Pectra”. Through the first few months of the year, as Dencun went live with...
Share Dialog
Share Dialog
Subscribe to Tim Beiko
Subscribe to Tim Beiko
>200 subscribers
>200 subscribers
No activity yet