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 Update 016 ⛓
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 ✅M...
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 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 Update 016 ⛓
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 ✅M...
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...
Subscribe to Tim Beiko
Subscribe to Tim Beiko
Share Dialog
Share Dialog
>200 subscribers
>200 subscribers
Long time coming, here's another AllCoreDevs update 😄 !
Shapella went live 🎉!
We're in the final stages of planning the next upgrade: Dencun 🏝️
Included EIPs are 4844, 6780, 1153 and 6475, but specs aren’t frozen yet ⛄️
EIPs 2537, 4788 and 6493 have been shortlisted as potential additions
Many others are still being discussed on EthMagicians 🧙♀️
I drafted EIP-6953, summarizing network upgrades activation triggers over time 📜
Catch me talking about Ethereum governance at a few places this summer — full list below 👇
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 ✔️
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, Shapella - progress - updates 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!
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.
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 not 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 "how", not "if", for Deneb.
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, TSTORE and TLOAD, which provide transient 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.
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.
Aside from the EIPs formally included in the upgrade, client teams have a shortlist of EIPs that may still make it in.
This EIP has been considered in one form or another 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.
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.
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.
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.
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 MCOPY opcode, on the last ACDE call.
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 😄
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 EDCON, ETHPrague, ETHShanghai, EthCC, and ETHMontreal.
See you there 👋!
Long time coming, here's another AllCoreDevs update 😄 !
Shapella went live 🎉!
We're in the final stages of planning the next upgrade: Dencun 🏝️
Included EIPs are 4844, 6780, 1153 and 6475, but specs aren’t frozen yet ⛄️
EIPs 2537, 4788 and 6493 have been shortlisted as potential additions
Many others are still being discussed on EthMagicians 🧙♀️
I drafted EIP-6953, summarizing network upgrades activation triggers over time 📜
Catch me talking about Ethereum governance at a few places this summer — full list below 👇
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 ✔️
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, Shapella - progress - updates 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!
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.
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 not 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 "how", not "if", for Deneb.
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, TSTORE and TLOAD, which provide transient 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.
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.
Aside from the EIPs formally included in the upgrade, client teams have a shortlist of EIPs that may still make it in.
This EIP has been considered in one form or another 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.
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.
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.
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.
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 MCOPY opcode, on the last ACDE call.
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 😄
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 EDCON, ETHPrague, ETHShanghai, EthCC, and ETHMontreal.
See you there 👋!
No activity yet