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!

The 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 time nearly everyone shared their preferences in writing.

These individualized statements struck a nice balance between efficiency and nuance. By moving parts of the “rough consensus” formation outside of calls, we could focus synchronous time on EIPs that either had the most buy-in or were most contentious.

During both the core dev interop and pre-Devcon R&D workshop, contributors discussed potential improvements to network upgrade coordination. These conversations led, among other things, to better defining the various stages of the process and their requirements.

Anyone can propose an EIP for inclusion in a network upgrade. Historically, though, the process was fairly informal. Proposals either came as AllCoreDevs agenda items or, more recently, in the Ethereum Magicians “Upgrade Meta” threads.

Once an EIP gained enough support, it would generally be marked as Considered for Inclusion (CFI), a term inspired by Bitcoin’s “Concept ACK”. This signals to EIP authors that their proposal is under serious consideration by client teams, even if technical details may still need to be figured out.

Since The Merge, devnets have played a critical role in testing client interoperability, yet their scope wasn’t tightly coupled with EIP inclusion stages. While Included EIPs in a network upgrade were tested on devnets, there was no formal criteria for adding CFI’d proposals to them.

This is largely why Pectra ended up split in two forks: we CFI’d more EIPs than we could concurrently implement and test.

Relatedly, EIP rejections were always awkward, as there was no formal way to signal them. They typically only happened implicitly, as a hard fork was finalized: EIPs that were not Included got dropped from the final specs. In rare cases, some Included EIPs were removed before mainnet deployment, typically due to security considerations.

To improve on this, EIP-7723 formally defines five network upgrade inclusion stages for EIPs, and how they relate to devnets:

• Proposed for Inclusion (PFI): Anyone can open a PR to add their EIP to a given fork’s Meta EIP, creating a clear record of all proposals up for consideration. Here’s a recent example.

• Considered for Inclusion (CFI): EIPs that client teams feel should belong in the network upgrade and feel confident they can implement in one of the upgrades’ devnets are moved to CFI.

• Scheduled for Inclusion (SFI): EIPs that client teams want to include in a network upgrade and implement in the next devnet are moved to SFI. Engineering bandwidth thus constrains how many EIPs can be moved to SFI.

• Declined for Inclusion (DFI): EIPs that client teams want to reject from a specific network upgrade are moved to DFI. This does not imply the EIP is rejected from all future upgrades. An EIP champion can propose a previously DFI’d EIP for a future upgrade.

• Included: Once a network upgrade has been activated on the Ethereum mainnet, all EIPs that were part of the upgrade are marked as Included. By default, this should be the list of SFI’d EIPs, but in rare cases of last-minute removals, the final 

Reading through EIP-7723 in full, you’ll notice the language is fairly permissive. There are many MAYs and few MUSTs. This is by design: the intention is for these norms to help facilitate the process, without slowing it down bureaucratically. It feels like the right level of formality for “mature experimental” tech!

Another small but consequential change to network upgrade planning (which I still need to formally define somewhere 😅) that came out of our pre-devcon workshop is to include non-Core EIPs as part of network upgrade Meta EIPs.

Core EIPs require all nodes on the network to activate them at the same time. For example, if an EIP updates the gas price for an opcode from X to Y, all nodes need to activate the EIP on the same block to stay in consensus.

However, several EIPs, such as Networking ones, don’t require simultaneous activation by all nodes. While there’s value in allowing clients to roll things out at their own pace, we’ve historically struggled to prioritize non-Core EIPs that require broader support, as our development process centers around network upgrades composed of Core EIPs.

To better surface these EIPs in our prioritization, we will include non-Core EIPs in network upgrade Meta EIPs. We’d already done this with PeerDAS due to its importance and agreed we should generalize the practice.

This will ensure that they explicitly focus on the most impactful protocol changes, whether or not they require a hard fork. The expectation for “including” non-Core EIPs in network upgrade specs is that, by the time of the network upgrade, all clients have the EIP deployed, even though teams may activate it at different times leading up to the deadline.

With process updates out of the way, let’s look at what is being planned for after the Pectra upgrade. For a deeper dive into Pectra, see my previous post.

The Fulu/Osaka network upgrade, Fusaka, follows Pectra. It includes the two major features that were removed from Pectra: PeerDAS and EOF.

PeerDAS introduces data availability sampling, extending EIP-4844’s ephemeral data and laying groundwork for full sharding. Instead of downloading every blob, nodes store only a subset and periodically verify samples from others. This approach lets the network increase blob throughput while maintaining similar bandwidth requirements for nodes. For a deeper dive into PeerDAS, see Francesco’s Devcon SEA talk.

EOF (EVM Object Format) overhauls the EVM to provide a clearer bytecode structure, improve efficiency, and enable deploy-time code validation. By removing features like dynamic JUMPs and code/gas observability, it becomes easier to statically analyze and verify EOF contracts. There’s a full website outlining the technical details and Danno Ferrin gave a Devcon SEA talk outlining the EIP’s history and motivations.

Both of these EIPs are currently being tested on independent devnets. Once Pectra is shipped, these will be combined into a first Fusaka devnet. As mentioned earlier, we’ll want to see EOF + PeerDAS running smoothly before SFIing more EIPs for Fusaka!

When planning the Pectra upgrade, core developers decided to preemptively CFI the Ethereum’s transition from Merkle to Verkle trees in the following fork. A set of Verkle-related EIPs were therefore formally marked as Considered for Inclusion in the Fusaka upgrade.

So, when Pectra was split in two upgrades, PeerDAS and EOF were moved to Fusaka and Verkle was pushed to the fork after that, Amsterdam. Because Verkle only affects the execution layer, specs for the consensus layer part of the fork were not drafted.

Following consensus layer convention, we should expect the CL part of the fork to be named after a star beginning with “G”. If we choose “Gl”, then we’ll have an elegant portmanteau: Glamsterdam 🪩

To better understand both the rationale for the Verkle transition and its current development status, see verkle.info or Guillaume Ballet’s Devcon talk.

Last but not least, 2024 has been a big year for Ethereum’s social layer. While no one can singlehandedly fill the shoes of legends saying “goodbye for now”, Ethereum’s L1 R&D community has grown resilient enough to not depend on any specific individual.

Better still, thanks to multiple client teams and R&D champions spread across the community, a myriad of initiatives can advance in parallel. Many of these are captured by breakout rooms, such as EPBS, Inclusion Lists,  EOF,  EVMMAX,  Stateless,  RollCall,  PeerDAS, Preconfirmations or Account Abstraction. Beyond these, we’ve seen progress on topics ranging from SSZ to History Expiry and Issuance, as well as significant 

There are also many excellent resources helping the community make sense of this constellation of possibilities. And, last but not least, a growing number of people and projects who have pledged their support to core contributors ❤️‍🔥

In many respects, we’ve reached functional escape velocity. At this point, no one can single-handedly direct it, but all of us can nudge Ethereum towards a better endgame.

If you’ve read all of this, you are the social layer.

Thank you for your contributions and see you in 2025!

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!

The 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 time nearly everyone shared their preferences in writing.

These individualized statements struck a nice balance between efficiency and nuance. By moving parts of the “rough consensus” formation outside of calls, we could focus synchronous time on EIPs that either had the most buy-in or were most contentious.

During both the core dev interop and pre-Devcon R&D workshop, contributors discussed potential improvements to network upgrade coordination. These conversations led, among other things, to better defining the various stages of the process and their requirements.

Anyone can propose an EIP for inclusion in a network upgrade. Historically, though, the process was fairly informal. Proposals either came as AllCoreDevs agenda items or, more recently, in the Ethereum Magicians “Upgrade Meta” threads.

Once an EIP gained enough support, it would generally be marked as Considered for Inclusion (CFI), a term inspired by Bitcoin’s “Concept ACK”. This signals to EIP authors that their proposal is under serious consideration by client teams, even if technical details may still need to be figured out.

Since The Merge, devnets have played a critical role in testing client interoperability, yet their scope wasn’t tightly coupled with EIP inclusion stages. While Included EIPs in a network upgrade were tested on devnets, there was no formal criteria for adding CFI’d proposals to them.

This is largely why Pectra ended up split in two forks: we CFI’d more EIPs than we could concurrently implement and test.

Relatedly, EIP rejections were always awkward, as there was no formal way to signal them. They typically only happened implicitly, as a hard fork was finalized: EIPs that were not Included got dropped from the final specs. In rare cases, some Included EIPs were removed before mainnet deployment, typically due to security considerations.

To improve on this, EIP-7723 formally defines five network upgrade inclusion stages for EIPs, and how they relate to devnets:

• Proposed for Inclusion (PFI): Anyone can open a PR to add their EIP to a given fork’s Meta EIP, creating a clear record of all proposals up for consideration. Here’s a recent example.

• Considered for Inclusion (CFI): EIPs that client teams feel should belong in the network upgrade and feel confident they can implement in one of the upgrades’ devnets are moved to CFI.

• Scheduled for Inclusion (SFI): EIPs that client teams want to include in a network upgrade and implement in the next devnet are moved to SFI. Engineering bandwidth thus constrains how many EIPs can be moved to SFI.

• Declined for Inclusion (DFI): EIPs that client teams want to reject from a specific network upgrade are moved to DFI. This does not imply the EIP is rejected from all future upgrades. An EIP champion can propose a previously DFI’d EIP for a future upgrade.

• Included: Once a network upgrade has been activated on the Ethereum mainnet, all EIPs that were part of the upgrade are marked as Included. By default, this should be the list of SFI’d EIPs, but in rare cases of last-minute removals, the final 

Reading through EIP-7723 in full, you’ll notice the language is fairly permissive. There are many MAYs and few MUSTs. This is by design: the intention is for these norms to help facilitate the process, without slowing it down bureaucratically. It feels like the right level of formality for “mature experimental” tech!

Another small but consequential change to network upgrade planning (which I still need to formally define somewhere 😅) that came out of our pre-devcon workshop is to include non-Core EIPs as part of network upgrade Meta EIPs.

Core EIPs require all nodes on the network to activate them at the same time. For example, if an EIP updates the gas price for an opcode from X to Y, all nodes need to activate the EIP on the same block to stay in consensus.

However, several EIPs, such as Networking ones, don’t require simultaneous activation by all nodes. While there’s value in allowing clients to roll things out at their own pace, we’ve historically struggled to prioritize non-Core EIPs that require broader support, as our development process centers around network upgrades composed of Core EIPs.

To better surface these EIPs in our prioritization, we will include non-Core EIPs in network upgrade Meta EIPs. We’d already done this with PeerDAS due to its importance and agreed we should generalize the practice.

This will ensure that they explicitly focus on the most impactful protocol changes, whether or not they require a hard fork. The expectation for “including” non-Core EIPs in network upgrade specs is that, by the time of the network upgrade, all clients have the EIP deployed, even though teams may activate it at different times leading up to the deadline.

With process updates out of the way, let’s look at what is being planned for after the Pectra upgrade. For a deeper dive into Pectra, see my previous post.

The Fulu/Osaka network upgrade, Fusaka, follows Pectra. It includes the two major features that were removed from Pectra: PeerDAS and EOF.

PeerDAS introduces data availability sampling, extending EIP-4844’s ephemeral data and laying groundwork for full sharding. Instead of downloading every blob, nodes store only a subset and periodically verify samples from others. This approach lets the network increase blob throughput while maintaining similar bandwidth requirements for nodes. For a deeper dive into PeerDAS, see Francesco’s Devcon SEA talk.

EOF (EVM Object Format) overhauls the EVM to provide a clearer bytecode structure, improve efficiency, and enable deploy-time code validation. By removing features like dynamic JUMPs and code/gas observability, it becomes easier to statically analyze and verify EOF contracts. There’s a full website outlining the technical details and Danno Ferrin gave a Devcon SEA talk outlining the EIP’s history and motivations.

Both of these EIPs are currently being tested on independent devnets. Once Pectra is shipped, these will be combined into a first Fusaka devnet. As mentioned earlier, we’ll want to see EOF + PeerDAS running smoothly before SFIing more EIPs for Fusaka!

When planning the Pectra upgrade, core developers decided to preemptively CFI the Ethereum’s transition from Merkle to Verkle trees in the following fork. A set of Verkle-related EIPs were therefore formally marked as Considered for Inclusion in the Fusaka upgrade.

So, when Pectra was split in two upgrades, PeerDAS and EOF were moved to Fusaka and Verkle was pushed to the fork after that, Amsterdam. Because Verkle only affects the execution layer, specs for the consensus layer part of the fork were not drafted.

Following consensus layer convention, we should expect the CL part of the fork to be named after a star beginning with “G”. If we choose “Gl”, then we’ll have an elegant portmanteau: Glamsterdam 🪩

To better understand both the rationale for the Verkle transition and its current development status, see verkle.info or Guillaume Ballet’s Devcon talk.

Last but not least, 2024 has been a big year for Ethereum’s social layer. While no one can singlehandedly fill the shoes of legends saying “goodbye for now”, Ethereum’s L1 R&D community has grown resilient enough to not depend on any specific individual.

Better still, thanks to multiple client teams and R&D champions spread across the community, a myriad of initiatives can advance in parallel. Many of these are captured by breakout rooms, such as EPBS, Inclusion Lists,  EOF,  EVMMAX,  Stateless,  RollCall,  PeerDAS, Preconfirmations or Account Abstraction. Beyond these, we’ve seen progress on topics ranging from SSZ to History Expiry and Issuance, as well as significant 

There are also many excellent resources helping the community make sense of this constellation of possibilities. And, last but not least, a growing number of people and projects who have pledged their support to core contributors ❤️‍🔥

In many respects, we’ve reached functional escape velocity. At this point, no one can single-handedly direct it, but all of us can nudge Ethereum towards a better endgame.

If you’ve read all of this, you are the social layer.

Thank you for your contributions and see you in 2025!