ACD Process Improvements

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.

EIP-7723: Network Upgrade Inclusion Stages

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 Included list may differ.

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!

Non-Core EIPs “Inclusion”

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.

Fusaka & G*/Amsterdam

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.

Fusaka

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!

G*/Amsterdam

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.

The Social Layer

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 new client-specific features, and, of course, Beam Chain.

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!

Pectra

This 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 without issues, client teams came to consensus on an initial set of EIPs for the upgrade, including BLS precompiles, EIP-3074, an increase to validators’ MAX_EFFECTIVE_BALANCE and several other protocol improvements .

These EIPs served as the target for our Nyota interop event. Over 5 days, ~120 attendees from client and research teams came together in Kenya to launch over 100 devnets to test Pectra, PeerDAS, Verkle, SSZ, EOF and more. 80% of the attendees said the week was one of their most, if not the most, productive of the past year! After interop, teams felt emboldened to think bigger… perhaps too big 😅

Even prior to the event, it was clear that parts of Pectra had to be rethought, most notably EIP-3074, which eventually got replaced by EIP-7702. After making more progress than expected on PeerDAS and EOF in Africa, teams felt confident they could bundle both changes alongside the already ambitious Pectra. By mid-June, Pectra had grown to include 20 EIPs, with more still under consideration.

As we spent the summer working on implementations, it became clear that bundling all of this in a single fork would be unworkable. In September, we decided to split the fork, even though there were concerns that moving EOF and PeerDAS out of Pectra would lead these important features to also be delayed.

PeerDAS’s removal from Pectra created urgency around considering a blob count increase for the fork. Several research posts analyzed the issue.

After months of back and forth, teams eventually agreed to double the blob target from 3 to 6 per block, and raise the maximum from 6 to 9. To prevent potential networking issues caused by large blocks, EIP-7623 was also included in Pectra. On the last AllCoreDevs of 2024, with the inclusion of EIP-7840, the final adjustments to Pectra’s scope were completed!

Now, let’s unpack exactly what is in this network upgrade.

EIP-7600

First, EIP-7600 defines the feature set for Pectra. While there have been exceptions, most network upgrades have a Meta EIP to track the individual EIPs they include. For Pectra, these are:

• EIP-2537: Precompile for BLS12-381 curve operations

• EIP-2935: Save historical block hashes in state

• EIP-6110: Supply validator deposits on chain

• EIP-7002: Execution layer triggerable exits

• EIP-7251: Increase the MAX_EFFECTIVE_BALANCE

• EIP-7549: Move committee index outside Attestation

• EIP-7623: Increase calldata cost

• EIP-7685: General purpose execution layer requests

• EIP-7691: Blob throughput increase

• EIP-7702: Set EOA account code

• EIP-7840: Add blob schedule to EL config files

  • Note: still not merged in the Meta EIP.

While I encourage you to read all of the actual EIPs (many of them are mostly words and not code!), here is a layman’s summary for each one.

EIP-2537

This EIP, first proposed for Berlin in 2020, holds the record of being considered for the most upgrades before its eventual inclusion. It introduces BLS12-381 cryptographic operations as precompiles on Ethereum’s execution layer. This curve is notably used by validators on the consensus layer, meaning that its inclusion allows smart contracts to validate proofs of validator signatures.

This is especially useful for use cases such as liquid staking or preconfirmations. Even beyond that, BLS provides higher security and cheaper verification than existing cryptographic primitives on Ethereum’s execution layer.

EIP-2935

This EIP sets the stage for Ethereum’s eventual transition to statelessness by storing the last 8192 block hashes in a contract. This will allow block hashes to be included in witnesses provided to stateless clients. Additionally, the EIP extends the range of block hashes available to applications from 256 (via the BLOCKHASH opcode) to 8192 in the 2935 system contract at 0x0aae40965e6800cd9b1f4b05ff21581047e3f91e.

EIP-6110

To account for potential proof-of-work reorgs, validator deposits are subject to a 2048 block wait prior to entering the Beacon Chain activation queue. Since The Merge, this has been unnecessary, as the execution layer stays in sync with the consensus layer each block. EIP-6110 updates the deposit mechanism to remove the delay between deposits being executed on the EL and added to the CL’s activation queue.

EIP-7002

Validators have two keys: an “active” BLS key, which is regularly used to sign attestations and other messages, and a withdrawal key, which is either a placeholder BLS key or the destination Ethereum address for the funds. Historically, only the active BLS key could initiate exits. EIP-7002 allows validators with Ethereum addresses as withdrawal credentials to initiate withdrawals.

This enables more trustless delegated staking arrangements, either via onchain pools or other custody setups. Today, delegators need to rely on the validator operator to initiate a withdrawal. With 7002, the controller of the withdrawal credentials can trustlessly exit their validators.

EIP-7251

This EIP raises the MAXIMUM_EFFECTIVE_BALANCE for validators from 32 ETH to 2048 ETH. This allows smaller validators to compound their rewards. Today, if a validator’s balance has increased beyond 32 ETH, the additional ETH is ignored when calculating rewards. With EIP-7251, rewards will compound up to 2048 ETH. The EIP also allows existing validators sharing a withdrawal address to consolidate their validators, hopefully reducing bandwidth usage on the network. For a deeper dive into the EIP, see Paul Harris’s Devcon Talk.

EIP-7549

When validators vote on blocks, they currently sign three pieces of information: their vote on finality (FFG vote), their vote on the current chain head (LMD-GHOST vote), and their committee assignment. By removing committee assignments from what gets signed, validators making the same votes can combine their signatures. This reduces the work needed to cryptographically verify consensus by about 60x!

This change has no impact on security - it just makes the same security guarantees more efficient to verify. This is especially important for light clients and future zero-knowledge proofs of consensus.

EIP-7623

The biggest factor in the size of an Ethereum block is how much CALLDATA it uses. While the vast majority of Ethereum transaction senders use a relatively small amount of data relative to the computation they execute, a small subset of transactions are extremely CALLDATA-heavy. In the worst cases, data-heavy blocks can severely disrupt the peer-to-peer network.

This EIP introduces a two-tiered gas price scheme for CALLDATA, based on how much gas a transaction spends on computation vs. data. By doing so, it effectively applies higher costs to extremely data-heavy transactions while leaving the vast majority of end user ones unaffected. An ethresear.ch post by the author goes into more detail here.

EIP-7685

This EIP extends execution layer block headers with a new requests_hash field to communicate information from execution layer system contracts, used in EIPs 2935, 4788, 6110 and 7002, with the consensus layer. In essence, this sets up a universal “request bus” for the execution layer to pass data to the consensus layer. The EIP is intentionally minimal, specifying only the base mechanism for storing and verifying requests, so that it can hopefully be used in all future similar cases.

EIP-7691

The blob increase! This EIP raises the per-block blob target from 3 to 6 and its maximum from 6 to 9, increasing Ethereum’s blob capacity by 2x! As previously mentioned, several research posts analyzed whether this could be done while maintaining reasonable node requirements. Including EIP-7623 was critical in bounding the worst case block sizes to allow for an increase in their average sizes with this EIP.

EIP-7702

As mentioned earlier, this EIP is the successor to EIP-3074. Its design was the result of extensive discussions between client teams, account abstraction researchers, wallet maintainers and application developers. In short, the EIP allows EOAs (Externally Owned Accounts) to execute code stored at a delegated address, effectively turning it into a smart-wallet for the duration of a transaction.

Much has been written about 7702. To better understand the design and its implication, see a deep dive by one of the authors, this panel on how the EIP affects wallets, or one of the many explainers for it. You can even try a live demo!

EIP-7840

EIP-7840 replaces a previous proposal, EIP-7742, that tried to decouple blob counts entirely from the execution layer. This would have allowed consensus layer-only forks to increase the blob count. After getting deeper in their implementations, teams realized that the blob count could not easily be abstracted from the execution layer.

Instead, EIP-7840 formalizes how EL clients will track the evolving blob target/maximum across forks in their config files, replacing EIP-7742’s approach of decoupling. This ensures the execution layer reliably references each fork’s blob constraints. In a scenario where the consensus layer was ready to raise the blob count and the execution layer needed to follow, all clients would need is a “one line change” in their genesis configurations.

Next Steps

Even with its reduced scope, Pectra is still shaping up to be one of the largest upgrades to Ethereum in history. It’s hard to believe that only 8 months ago we didn’t even have blobs live! With the feature set for the upgrade now finalized, teams have a more stable implementation target to kick off the year.

It’s hard to predict timelines, but hopefully after devnet-5, we only have another devnet or two before moving to testnet forks. As always, security remains the top priority. If the devnets or other testing reveals issues, teams will of course address them before moving forward.

Until then, expect another ACD update covering post-Pectra updates, AllCoreDevs process changes and more 🔜

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 PGv2 launching soon, now feels like a good time to articulate how and why we can and should get there. Let’s call this the Protocol Guild Pledge!

In the first part of this post, I’ll unpack what I mean by “Ethereum L1 R&D”, “economically rational”, “risk adjusted basis” and “avoiding capture”. Then, I’ll expand on the Protocol Guild Pledge (PGP, for short), arguing that a norm of projects with native tokens donating 1% of them to Protocol Guild is sufficient to provide sustainable funding for Ethereum L1 R&D long-term.

Ethereum L1 R&D

Ethereum is developed and maintained by a large set of core contributors, with expertise ranging from distributed systems, to cryptography, devops, cat herding and more. They collaborate in the open to define & deliver Ethereum’s complex technical roadmap, while ensuring the security of the network is never compromised. Participation is permissionless — anyone can just show up and start contributing! — which has many benefits, but makes defining the set of “core contributors” a notoriously hard problem.

Organizations are at best proxies with (often worthwhile!) overhead, and individuals “doing the work” often have the least bandwidth for and interest in self-promotion. Protocol Guild (PG) thus aims to make the set of Ethereum L1 R&D contributors directly legible onchain. Using a time-weighted list and clear membership criteria, PG provides an continually up-to-date view of who is currently contributing to the protocol, and for how long they have been doing it.

Economically Rational

Working on Ethereum is incredibly exciting and, in my experience, a deep sense of mission permeates the core development community. Funding for protocol R&D work is also in a much healthier place than it was a few years ago. That said, Ethereum core devs and researchers are in high demand: everyone working on Ethereum L1 could likely earn significantly more by doing something else. Even with a reasonable salary, as the opportunity cost of continuing to work on L1 grows, maintainers rationally start considering other options. Relying exclusively on passion, or status, as a long term strategy to attract and retain core contributors puts Ethereum at risk of ending up in a “guy from Nebraska” situation, where only a small set of (relatively) underpaid maintainers are responsible for infrastructure securing billions in value.

Risk-Adjusted Basis

While there are a number of more lucrative opportunities for Ethereum core contributors out there, an important caveat is that many of them involve higher risk! This is an important distinction: rewards for contributing to Ethereum L1 should be calibrated to the relative risk of doing so. Starting a successful company as a founding engineer will always be more profitable than being one of X00 Ethereum L1 contributors, but the odds of that company failing are much higher.

Protocol Guild should not aim to match the expected rewards of riskier endeavors, but instead close the “gap” that currently exists between working on Ethereum L1 and projects slightly farther out on the risk curve, which can offer disproportionately higher rewards. Visually, PG can be thought of as the yellow arrow below, “lifting” the Ethereum L1 R&D cloud on the Reward axis, to bring it back in line with everything else:

Avoiding Capture

Aligning the risk/reward of L1 R&D work with the rest of the ecosystem is necessary to attract and retain high quality contributors. However, it’s critical to consider the impact of additional funding on incentive alignment. We want to prevent scenarios where a deep-pocketed actor can single handedly exert influence over a large portion of maintainers.

While this risk can never be fully eliminated and Protocol Guild isn’t necessary for external actors to try and influence protocol maintainers, PG being fully onchain at least provides transparency. Anyone can audit who sent what to its contracts to assess whether a single donor or asset is overrepresented. In such a scenario, other donors can then step in to equalize things :-)

By sharing funding expectations across the ecosystem, we reduce both potential influence from, and excessive reliance on, a small number of donors. As Trent explained in a recent article, with a diverse donor set, Protocol Guild may even be able to shield protocol development from the pressures of commercial entities who currently employ most maintainers.

Lastly, while this should go without saying, let me be explicit: donors should never expect anything beyond the continued support and development of the Ethereum protocol as a result of their contribution. In other words, donating to Protocol Guild is not a way to shift core contributors’ focus to a specific initiative.

With definitions out of the way, let’s now dive into the Protocol Guild Pledge!

Protocol Guild Pledge: 1% of Native Tokens to Fund Core Development

Why Tokens?

In the earlier diagram, most of the gap in rewards between the white “Ethereum L1 R&D” cloud and others is due to the expected value of tokens in compensation packages, not differences in base salary.

While no token is guaranteed to appreciate in value (that’s the “risk” part!) Ethereum contributors generally do not get exposure to the assets secured by the network as part of their job. By switching to a role with an only slightly larger risk profile that offers token compensation, they can often materially increase their expected rewards, even if their base salary remains constant.

Protocol Guild being an onchain registry is perfectly positioned to close that gap. Token donations are often suboptimal due to recipients’ need to cover fiat-denominated expenses. But, in this case, given the risk/reward gap is primarily composed of such assets, their volatility is a feature, not a bug!

In a way, these tokens represent the surplus value of the Ethereum ecosystem. If a broad enough subset of projects contribute their tokens to PG, core contributors end up with a basket providing diversified exposure to the value created by the ecosystem they support. In many cases, these tokens also confer rights, such as participation in governance, to holders. Projects donating their tokens then ensure these end up in the hands of valuable contributors, both today and in the future.

Why 1%?

First, why a percentage at all? Denominating the Protocol Guild Pledge in “percentage of supply” rather than “fiat equivalent value” has a few advantages:

• It puts all projects on an equal footing. A small project donating 1% of their tokens should be celebrated to a similar degree as a large one, as they are making the same proportional commitment.

• It abstracts volatility from donations. Funds sent to PG are vested for years. By the time they are fully received by members, the price of tokens could have shifted dramatically. A large fiat-denominated bull-market donation may end up less valuable when fully vested than a smaller fiat-denominated bear market one.

• It enables pre-token commitments. Projects may not want to signal specific timelines for the introduction of a token, but may want to commit to supporting PG early on. A public commitment to reserve 1% of a future (hypothetical) token is then an easy thing for the community to hold a project accountable to.

Now, why 1%? Why not 10%? 0.1%? Something else? Well, for one thing, it’s less than 1.5%!  More seriously, though, here are some metrics to provide context for the amount:

• Protocol Guild currently has 163 members. Members’ share of total donations is proportional to the (square root of) the amount of time they have been contributing to Ethereum. Members’ shares currently vary between 1.16% and 0.27%.

• Ethereum currently secures roughly 200b$ of non-ETH assets on L1. Removing LSTs & stablecoins/RWAs, leaves slightly less than 100b$. Including L2-native assets to this brings the total back to roughly 100b$ of native tokens whose security depends on L1.

• Protocol Guild’s v2 contracts will have a multi-year vesting period. The exact duration is TBD, but will likely be between 3-5 years, with a minimum contribution period required before maintainers can join PG. For simplicity, let’s use 4 years.

Now, let’s imagine a hypothetical world where all Ethereum projects with a native token that exist today have contributed to Protocol Guild. 1% of their 100b$ native token market cap would represent 1B$ in total contributions, or 250m$ vesting per year. Across 163 members, this currently averages to ~1.5m$/yr, ranging between 675k$ and 2.9m$/yr.

At first glance, these numbers seem within the right order of magnitude. High-six / low-seven figure yearly compensation isn’t unheard of in the tech industry, especially in roles that are critical to the handling of hundreds of billions in value.

However, this hypothetical makes many simplifying and optimistic assumptions. First, it only looks at a fixed point in time. Projects come and go, and maintaining a 250m$ distribution year over year assumes the total value of native assets secured by Ethereum grows by 25b$/yr.

Second, it holds the number of contributors constant. At a certain reward level, Protocol Guild reward may attract a larger number of contributors, diluting rewards for existing members.

Third, and most importantly, it assumes 100% of projects donate a full 1% of their native token. Going down by an order of magnitude, if 10% of projects contribute to PG, or 100% donate 0.1% of their tokens, we end up at 150k$/yr for the average PG member. This is unlikely to shift incentives enough to retain them.

All of this considered, 1% feels like the right number for the Protocol Guild Pledge. A strong norm of projects donating 1% of their token supply, adopted by 33-66% of projects would have this hypothetical at a 500k-1m/yr per member on average. At these levels, the risk/reward gap that exists today would almost certainly be closed.

Why now?

Protocol Guild is roughly two orders of magnitude away from the numbers hypothesized above. The pilot has been an amazing spark of initial validation and has allowed the guild to lay the technical, legal, and governance groundwork for a longer lasting collective. In other words, it works, but it’s now time to scale up!

To get through the Surge, Scourge, Verge, Purge, and Splurge, it’s paramount that Ethereum retains its best contributors and continues attracting new talented ones. To broaden both the number and the kinds of people who are able to participate as core developers, we need to rely on economic incentives over passion or status.

Additionally, as we scale the reach and impact of the Ethereum ecosystem, we should also strive to scale its values. Values are hard to scale because labels get co-opted and diluted to near-meaninglessness as they gain popularity (see “decentralization”, “alignment”, and, I fear, “public goods”). Luckily, the Ethereum ecosystem can still coordinate on new ones!

Projects who adopt the Protocol Guild Pledge will help seed a meme whose quantitative component (“1% of native tokens”) makes it harder to dilute. If you’re reading this, you likely have an overall sense of what, and who, it means for Ethereum L1 R&D to be sustainably supported. It’s not guaranteed that this remains the case as the space grows. A future where most notable projects have a “Protocol Guild Pledge” badge on their Github or Etherscan token page is one where it’s more likely we’ll see organic, continuing support for both core development as well as a public goods more generally from new projects entering the space.

Conclusion

Protocol Guild is currently Ethereum’s most promising tool to sustainably incentivise Ethereum L1 R&D. It complements existing funding infrastructure by aggregating the set of core contributors, keeping it updated over time, and funding these people directly.

In order to provide strong enough incentives for talented contributors to work on mainnet long term, Protocol Guild needs to scale roughly 100x. If as a community we instill a norm for projects to contribute to the Protocol Guild Pledge, I believe we’ll get there!

Many thanks to everyone who provided direct feedback on this piece, or with whom I’ve had conversations about this topic. I’ve tried to distill all of it into a coherent whole, but what remains are my personal views, and shouldn’t be attributed to Protocol Guild, AllCoreDevs, or the Ethereum Foundation. Full disclosure, I am a member of Protocol Guild. Last but not least, a special shout out to ether.fi, who committed 1% of their token supply to Protocol Guild ahead of this post even being published!

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 🎄

TL;DR 👀

• 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 👇

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, 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!

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-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 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.

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, 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.

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 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.

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 MCOPY 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 EDCON, ETHPrague, ETHShanghai, EthCC, and ETHMontreal.

See you there 👋!

While these started out as a monthly series, the cadence is slowly trending towards quarterly. Think of these updates as a digest of everything big that’s going on around AllCoreDevs. If you want a higher resolution, I recommend the more frequent ones by Christine Kim, the CL call notes by Ben Edgington or my ACD tweetstorms.

With that said, let’s get into it!

TL;DR 👀

• The contents of the Shanghai/Capella upgrade has been finalized: withdrawals, EOF, and a handful of minor changes… so long as they don’t delay withdrawals ❌

• Blobspace is coming: EIP-4844 will be at the centre of Ethereum’s next upgrade, with its summoning ceremony starting soon 🕯️

• An effort is underway to harmonize the technical side of the EL & CL upgrade processes. We’re also seeing active discussion about better incorporating the community’s input in the process 📣

• Protocol Guild published a mid-pilot report, and a rough plan to scale and better support L1 maintainers in 2023 ⛓️🛡️

Shanghai / Capella 🌃

On the last AllCoreDevs, client teams agreed to a finalized scope for the Shanghai / Capella upgrade. While the name of the upgrade might still be up for debate, teams are clear about its scope. The main feature of the upgrade is the introduction of Beacon Chain withdrawals for stakers. Getting this out ASAP is something client teams don’t want to compromise on, so other features in the upgrade need to be ready at the same time, or may be dropped.

The Shanghai EL spec lists all included EIPs:

• EIP-3540: EVM Object Format (EOF) v1

• EIP-3651: Warm COINBASE

• EIP-3670: EOF - Code Validation

• EIP-3855: PUSH0 instruction

• EIP-3860: Limit and meter initcode

• EIP-4200: EOF - Static relative jumps

• EIP-4750: EOF - Functions

• EIP-4895: Beacon chain push withdrawals as operations

• EIP-5450: EOF - Stack Validation

While the list is long, it can be broken into three distinct buckets: minor improvements, EVM Object Format and Withdrawals. Let’s go through each of these:

Minor Improvements ⚙️

EIP-3651: Warm COINBASE

This EIP fixes an oversight in EIP-2929, which changed the gas costs of accessing certain data fields based on whether clients already have them in memory (WARM) or need to retrieve them from disk (COLD).

EIP-2929 sets two pieces of data which clients have in memory to WARM at the start of each transaction: the sending and receiving addresses. EIP-3651 adds a third address to this list, the COINBASE address (a.k.a. feeRecipient), given it’s also an address clients have in memory when processing a block’s transactions.

EIP-3855: PUSH0 instruction

As the name implies, EIP-3855 introduces an opcode to push the value 0 to the stack. Pushing 0 is frequently used to pad values in the EVM, and this opcode will offer a more efficient, and cheaper, way to do this.

EIP-3860: Limit and meter initcode

This EIP adds a maximum size for initcode and introduces gas metering based on its length. The size limit adds an invariant to the EVM which will make it easier to reason about and propose changes to.

A 2 gas/32 byte cost for initcode is introduced to account for the jumpdest-analysis clients must do prior to execution, which previously was not accounted for in the gas schedule.

EVM Object Format 🧰

The majority of EIPs included in Shanghai are all part of a single feature: EVM Object Format (EOF). The work was broken down into 5 distinct EIPs to help client developers reason about each change in isolation, but to give a higher level overview, a unified spec was released this week. The 5 EOF EIPs are:

• EIP-3540: EVM Object Format (EOF) v1

• EIP-3670: EOF - Code Validation

• EIP-4200: EOF - Static relative jumps

• EIP-4750: EOF - Functions

• EIP-5450: EOF - Stack Validation

It’s worth noting that the first step for EOF was taken in the London upgrade, with EIP-3541, which reserved the 0xEF00 prefix for EOF contracts. Over the past few months, the scope of EOF for Shanghai also evolved.

In February, client teams agreed to consider two minimal EOF EIPs for Shanghai: EIPs 3540 & 3670. These would act as building blocks but wouldn’t provide the full functionality without the introduction of EIPs 4200, 4750 and 5450. While it is possible to extend EOF, backwards incompatible extensions may require a version bump. Because pre-EOF or EOF contracts with a specific version must always be executable, each new EOF version means client developers must maintain a new set of EVM execution rules in parallel to legacy ones.

Before EOF, clients only maintained one set of EVM rules at a time. The codebases also support historical EVM rules which can change every network upgrade, but once they get to the tip of the chain, only the most recent rules must be applied. With EOF, clients will maintain two parallel set of EVM rules, so they can execute code in both EOF and non-EOF contracts. In other words, EOF version bumps increase the number of parallel, rather than sequential, EVM rulesets that must be maintained.

For this reason, over the past few months, clients teams began preferring a “big EOF” approach. This way, while they must implement a larger change set, the EOF version will stay fixed longer, reducing the number of “parallel EVMs” to maintain. Hence, “Big EOF” is what was considered, and eventually included, in the Shanghai upgrade.

That said, bigger features are obviously trickier to implement and test and teams don’t want to see EOF significantly delaying Beacon Chain withdrawals. Therefore, clients agreed to remove EOF from Shanghai if, come January, implementations are not complete and quickly interoperating with each other.

With that context, let’s now briefly go over the various EOF EIPs:

EIP-3540: EVM Object Format (EOF) v1

This EIP introduces the “container” for EOF contracts. It adds markers which discriminate code and data sections in contracts, and prevents EOF contracts who don’t comply with the format to be deployed. This provides the assurance that any on-chain EOF contract would follow a valid layout, which simplifies both interactions with these contracts as well as static analysis of them.

EIP-3670: EOF - Code Validation

Building on the container introduced by 3540, EIP-3670 ensures that the code in EOF an contract is valid, or prevents it from being deployed.

This means undefined opcodes cannot be deployed in EOF contracts, which has the added benefit of reducing the number of EOF version bumps required. If a new opcode is added, validation rules can simply be changed to enable it, and there is a guarantee that no EOF deployed contract references it in its code section.

EIP-4200: EOF - Static relative jumps

EIP-4200 introduces the first EOF-exclusive opcodes: RJUMP, RJUMPI and RJUMPV, which encode destinations as signed immediate values. These new JUMP opcodes can be used by compilers to optimize gas costs, as they remove the need for runtime jumpdest-analysis that is required with the existing JUMP & JUMPI opcodes.

EIP-4750: EOF - Functions

EIP-4750 takes features from 4200 one step further: it disallows the JUMP & JUMPI opcodes, and adds an alternative for functionality that can’t be replicated with RJUMP, RJUMPI and RJUMPV. It does this by introducing specific function sections in EOF bytecode, which can be jumped to, called and returned from with new JUMPF, CALLF and RETF opcodes respectively.

EIP-5450: EOF - Stack Validation

Finally, EIP-5450 adds yet another validation check to EOF contracts, this time around the stack. The EIP prevents EOF contracts from deploying code which can result in a stack underflows, as well as some cases of overflows. With this, clients can reduce the number of validation checks they make during execution of EOF contracts because they have better assurances around stack-related exceptions with them.

As a non EVM expert, leaning heavily on the EIPs themselves, that’s as far as I can take you! If you want to dig into EOF more, I recommend Geth’s lightclients or Solidity’s Leo’s threads.

Beacon Chain Withdrawals 💸

Last but not least, the main component of “Shapella” is Beacon Chain withdrawals. The change is specified across both the consensus layer specs and EIP-4895. A now-slightly-out-of-date meta-spec ties these together.

At a high level, here is how withdrawals will work:

• When proposing a block, validators scan linearly through validator indices to find the first 16 validators with 0x01 credentials who either:

  • Have a balance above 32 ETH (i.e. have accrued validator rewards)

  • Are withdrawable (i.e. have fully exited the validator set)

• From these, the validator will create a list of withdrawals to be included in their ExecutionPayload. Each item in that list contains the following:

  • WithdrawalIndex: index among all withdrawals ever made — this helps differentiate between withdrawals for the same amount from the same validator to the same address

  • ValidatorIndex: the index of the validator whose balance is being withdrawn

  • ExecutionAddress: the ETH address on the execution layer where the withdrawal should be sent

  • Amount: the amount, in gwei (not wei), to be sent to ExecutionAddress

• When building or processing a block, EL clients will apply these withdrawals after transaction execution. In other words, processing withdrawals is similar to how proof-of-work rewards were credited, and does not compete with user transactions for block space.

A few more details worth noting:

• When processing withdrawals, there is no difference between a “full” vs. “partial” withdrawal in terms of priority/ordering. Full withdrawals happen once a validator has left the exit queue, and partial withdrawals happen periodically when the linear scan over the validator set reaches a validator’s index.

• For withdrawals to be processsed, validators must use 0x01 credentials, which represent an ETH address. At the launch of the beacon chain, only 0x00 credentials, which used BLS keypairs, were allowed. In order to enable withdrawals, validators with 0x00 credentials will need to sign a BLSToExecutionChange message. These will be enabled as part of the Capella upgrade. Validators can expect support and tutorials for multiple tools to sign this message.

• The scan over the validator set is bounded each block. If, after scanning a subset of the validator set, there aren’t 16 withdrawals to process, the validator will stop scanning and the next one will pick up from the last validator index scanned.

As always, there will be several devnets and testnets (potentially even some new ones!) for validators to run through the process and iron out any issues before things go live on mainnet.

Shanghai/Capella isn’t the only upgrade on which progress was made, though! Teams have also been looking ahead to the next one.

Cancun 🏝️

With Shanghai full, but many CFI’d EIPs not making it in, client teams began discussing what should be considered for the next upgrade: Cancun (CL name TBD) 🏝️

On the CL side, EIP-4844 had already moved towards being spec’ed as the first post-Capella upgrade. The EL doesn’t (yet!) have a spec which enables such a layout, but EL teams agreed to follow a similar path and center the next upgrade around EIP-4844.

Following the convention of using devcon city names for upgrades, cancun.md was created, with EIP-4844 being formally included in the upgrade.

This decision happened in the final minutes of the last 2022 AllCoreDevs call, so there wasn’t time to address other proposals. EIPs that were CFI’d for Shanghai but didn’t make it in were moved over to Cancun’s CFI list, and an Ethereum Magicians thread was opened to discuss Cancun candidate EIPs. Early next year, deliberations around Cancun’s scope should start in earnest.

KZG Ceremony 🕯️

One other Cancun-related thing to expect then is the KZG Ceremony 🕯️, which is a requirement for EIP-4844.

The Ceremony will generate the randomness needed to verify the validity of blob data. For it to be considered secure, only a single participant must have participated honestly. In other words, if all but one participant collude, then the entire process is cryptographically secure.

Starting in January, the ceremony will be open to everyone for several months. With a goal of getting 10,000 contributors, this is planned to be the largest such ceremony to date! If you want to be sure not to miss it, give Trent Van Epps a follow!

Post-Merge Upgrade Process 📜

As mentioned in previous updates, one big TODO with The Merge behind us is harmonizing the upgrade process for Ethereum across the EL & CL. At a high level the EL uses the Yellow Paper & EIPs to specify changes, while the CL uses an executable Python specification.

The EL process has the upside of EIPs being well known by the community and formatted in a way which clearly presents the reasoning behind a proposal. The mix of the math-heavy Yellow Paper overlaid with EIPs, and need to put specifications in context within EIPs make the execution layer specifications both hard to understand and extend.

The CL side has the inverse problem: it has a clear and approachable spec, living within a single repository, but changes aren’t specifically identifiable, and proposals get burried among the other open PRs on the repo.

With the introduction of the Ethereum Execution Layer Specification, we can hopefully bridge the gap from the EL side. And, with some process wrangling, we might be able to get EIPs introduced as part of the CL process…!

That said, as the Shanghai upgrade scope was being debated and finalized, it became clear that another “piece” may be missing from this process: somewhere for the community to voice their relative preferences about changes, engage in discussions about the overall scope of an upgrade (rather than individual EIPs), and have that be incorporated as part of decision making in the AllCoreDevs & CL calls.

It’s not quite clear what this looks like yet - and I’d love suggestions! - but with the number of stakeholders being actively involved in protocol changes and the number of domains L1 changes affect both growing, it’s apparent that something is needed.

Luckily, we’re not starting from scratch: Ethereum Magicians has been around for years now, and its IRL gatherings, as well as ad-hoc breakout rooms or community calls may be good starting points to extend.

Expect more updates on this front early 2023!

Protocol Guild Update ⛓️🛡️

With the Protocol Guild pilot halfway done, the collective published a report examining how things are going and what the planned next steps for the project are.

As a reminder, PG is a permisionless funding mechanism for Ethereum L1 client developers, protocol researchers, and supporting contributors, such as yours truly.

The mechanism is centered around individuals, not organizations. In short, every member is eligible for a share of tokens vesting in the guild, weighted by the duration of their contributions to Ethereum. Member additions and removals are done, in true Ethereum fashion, by reaching rough consensus within PG, based on a set of criteria. This list is then put on chain using 0xSplit’s split contract. Donors can then send funds either directly to the split, or to a vesting contract that feed to it.

The mid-pilot report was summarized on Twitter. Here are some highlights ✨

• The pilot raised 9.7m$, from many orgs such as Lido, Uniswap, ENS, NounsDAO and MolochDAO, as well as some recurring individual donors (s/o Tetranode 🦈!) — thank you all for making this possible❤️‍🔥!

• PG now has 128 members, up from 90 at launch, and 5m$ has been distributed among them already 💸

• On average, each member received 39,000$, with a min of 13k$ and max of 79k$ 🧧

• PG’s architecture is evolving to support L2s and remove the need for a multisig to update weights 🙅

These early results show PG working as intended: a mechanism which distributes a basket of tokens to a self-curating, growing, set of protocol contributors. Proving this wouldn’t have been possible without the generous support from pilot donors.

Looking forward, it’s now time to scale PG to its full potential: providing competitive risk-adjusted compensation for maintainers of Ethereum. The lowest hanging fruit here is for projects to contribute to PG from Day 1, as described in Danny Ryan’s PG inception tweet.

Donations for the pilot mostly came from large projects with significant treasuries. If Protocol Guild can convince projects to contribute from Day 1, when their token is still effectively worth “nothing”, then Ethereum maintainers can benefit from the entire upside trajectory of successful projects.

With enough projects participating, incentives can shift towards keeping the best people towards maintaining the protocol, rather than pulling them away from it.

To support this, as well as many other contribution types, PG will need a technical overhaul. The next version should work across both L1 and L2s, and reduce its on-chain governance footprint even more.

If you’re a project looking to contribute to Protocol Guild, please reach out — my DMs are open 📭!

Next Steps ✅

And that’s a wrap for 2022… what a year! Three months ago, we hadn’t even merged! Now, Ethereum is silently running proof-of-stake in the background and focus has shifted to what’s on the horizon.

As everyone gets back from the holidays in January, you can expect:

• Shanghai/Capella devnets and shadow forks 👻

• The KZG Ceremony going live 🕯️

• Discussions around Cancun, and how the network upgrade process should evolve to better capture the preferences of the community 🏝️

• Protocol Guild’s pilot to wrap up and post-pilot architecture to be announced ⛓️🛡️

Thanks for reading! And thank you to everyone who spent time trying to improve Ethereum over the past year - we got a lot done. Hope you all take some well-deserved holidays 🎄.

See you in 2023 👋!

Thank you to lightclients, Alex Stokes and Joe Schweitzer for reviewing drafts of this update and making sure I get the technical details right!

A whole quarter has gone by since the last one of these --- time flies! In the meantime, hopefully you noticed that Sepolia, Goerli/Prater and, of course, mainnet merged 🐼!

A third cohort of the Ethereum Protocol Fellowship was also kicked off, and old testnets were sunset. More on that last bit below 👇

TL;DR 🐼

• We did it, we merged 🎉! It was quasi-flawless 🍾!

• AllCoreDevs and CL calls are on pause for a few more weeks. Conversations about Shanghai candidate EIPs are happening on Ethereum Magicians and IRL. Calls resume on October 27 📺

• Kiln has been shut down. With Rinkeby and Ropsten's sunset dates on the horizon, infrastructure providers are starting deprecations 🌅

Post-Merge Cooldown 🏝️

The last year was, to say the least, intense. Teams worked tirelessly to get The Merge ready. After a winter of spec changes, spring of shadow forks and summer of testnet upgrades, mainnet-ready clients were finally released and everyone spent weeks refreshing bordel.wtf, waiting for TTD to hit. On September 15th, at 6:42 UTC, it happened, and Ethereum transitioned to proof-of-stake 🐼!

                 ..              .
                %@@#     .      %#@#
               -@@%%- ........ -*@@@=
               +@@%+..        ..=#@@%
               +@@-.             .*@*
               .=+.               .-.
                 ..=#%+.     *@%+. .
                . +@@@@#    .@@@@# ..
                . @@@@@#     @@@@@* ..
               . +@#-%@#     %%-%@% ..
               . %@@%@@-    =*@+@@@. .
               . #@@@%=. .   -@@@@@...
              :...+#-.. +*+  .-@@@*  .
              :.       :@@@=    -:.  ..
              ::        :%-         .-.
            .*.-.        +         .:..
           :*%*-   :    +*.        .. :*-
           =@@%+=   .:=**-+.   .  .. -###.
     .-%%  #@@@%:.    +++**#::..    -%#@@+
    +@@@%.#@@@@@%.    =*+***-:    :.@%@@@@.  +%*
   :@@@@@#@@@@@@%-.   =++*++.    :-%@%@@@@@%-#@@%-
   *@@@@@#@@@@@@@%:.  .#+-+#  .  :#@@@@@@@@@#%@@@%
   +@@@@@*@@@@@@@@#    :-:+   ...#@@@@@@@@@@*@@@@@.
   .@@@@%@@@@@@@@@@#==   .    =:@@@@@@@@@@@@#@@@@@.
    +@@@@@@@@@@@@@@@%*=.    .*%@@@@@@@@@@@@@@#@@@@.
     #@@@@@@@@@@@@@@@@@%+--+%@@@@@@%@@%@@@@@@@@@@%
      *%@@@@%+%====#%@@@@@@@@@@%%#%%%%%@@@@@@@@@@.
        .:. %=::     .-#@@@@@%-    ..-#*%@@@@@@#.
            =::..        ...        ...:-#---:.
            ....   ⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀ .....
            ...    ⠀⠀⠀⠀⠀⠀⣰⣿⣆⠀⠀⠀⠀⠀   ...
           ..      ⠀⠀⠀⠀⠀⣼⣿⣿⣿⣦⠀⠀⠀⠀   ...
           ...     ⠀⠀⠀⢀⣾⣿⣿⣿⣿⣿⣷⡀⠀⠀    ..
           ...     ⠀⠀⢠⣿⣿⣿⣿⠿⣿⣿⣿⣷⡄⠀    .:.
           ...     ⠀⣰⣿⠿⢛⣩⣤⣶⣤⣉⠛⠿⣿⣆    ..
          . ..     ⢀⣡⣴⣾⣿⣿⣿⣿⣿⣿⣿⣷⣦⣌    ..
          #+:.     ⠀⢌⡙⠻⣿⣿⣿⣿⣿⣿⣿⠟⢋⡥     .:=*
        .*%#:..    ⠀⠈⠻⣷⣦⣉⠻⠿⠛⣩⣴⣾⠟⠀   ..:*@=
        -@@#.-..   ⠀⠀⠀⠙⢿⣿⣿⣶⣿⣿⡿⠋⠀⠀   ..:%@%.
        #@@%:...   ⠀⠀⠀⠀⠈⢻⣿⣿⣿⠟⠁⠀⠀⠀  ..:-@@@:
       .%@@@=:.... ⠀⠀⠀⠀⠀⠀⠹⣿⠋⠀⠀⠀⠀⠀ ....*@@@=
       =@@@@%......                 ...=@@@@+
       *@@@@@=:...                ....:+@@@@*
       %@@@@@@+-. .              ....::#@@@@#
       %@@@@@@@+-... .           ...:=%@@@@@%
       @@@@@@@@@*:....        .....:=%@@@@@@%
       @@@@@@@@@@*-...............:*@@@@@@@@*
      .@@@@@@@@@@@*.............  :@@@@@@@@@+
       *@@@@@@@@*-  .  ......      .%@@@@@@@:
       +@@@@@@@=                    .%@@@@@@:
      .#@@@@@@+                      :@@@@@@@*
     -%@@@@@@@*                      -@@@@@@@@#.
    :%@@@@@@@@@                      .@@@%@%@@#+
    #-@#@*@@@@:                       .%@@=@+@%.
    ..-=#*@*:                           .: :.

Merge panda, courtesy of Teku

Hours later, only minor issues were reported on the AllCoreDevs call. One week post-merge, the assessment was the same on the consensus layer call. All things considered, things went about as smoothly as they could have🍾!

So, with that done, teams agreed to take a well-deserved break from the regular cadence of ACD & CL calls. That said, work on the next upgrades is still happening in the background.

Shanghai Candidate EIPs 📜

With The Merge done, eyes are starting to turn to the next network upgrade: Shanghai/Capella 🌃

On the consensus layer, Capella is expected to include Beacon Chain withdrawals, and potentially EIP-4844. On the execution layer, Shanghai already has several EIPs under consideration. So much so that, earlier this year, we decided to pause adding more to the list until The Merge had passed.

While we wait for ACD calls to resume, EIP champions who want their EIP considered for Shanghai are encouraged to signal this on Ethereum Magicians using the shanghai-candidate tag.

This way, conversations about the merit of specific EIPs can happen asynchronously, and contributors have the opportunity to take a step back without feeling like they may miss a decision about a specific EIP being included or rejected from Shanghai.

Breakout Rooms & F2F Discussions 📣

While most conversations have been happening on Ethereum Magicians and discord, calls and in-person sessions have been organized for topics where synchronous discussion is needed.

Specifically, EIP-4844 has had series of public calls covering both the work on the KZG Ceremony and the client implementation prototypes. As a reminder, the KZG Ceremony is required to provide the randomness seed to be used as part of sharding data verification. @pintail had a great ELI5 here, and more info on the process can be found in this repo.

Next week, during Devcon, an Ethereum Magicians gathering is organized to serve as both a retrospective on The Merge and an opportunity for client teams, researchers, developers, EIP champions, and other attendees to discuss future changes to Ethereum. It's also expected that there will be several follow-up sessions covering specific EIPs, or sets of proposals, such as this one on EVM-related EIPs.

This mix of async discussions and live breakouts will hopefully help formal conversations about Shanghai's scope be both better informed and more effective once they resume. This will be the main topic of the next AllCoreDevs, scheduled for October 27th.

Testnet Deprecations 🌅

As announced back in June, Kiln, Ropsten and Rinkeby are being deprecated in favor of Goerli & Sepolia.

The Kiln testnet was recently sunset and Ropsten is scheduled next, with a shut down date of December 2022. Rinkeby will stay up until mid-2023, but will not apply any post-London network upgrades, including The Merge. It therefore isn't an ideal staging environment for mainnet anymore.

In addition to this, infrastructure and tooling providers are now starting to remove support for these networks. Both Etherscan and ethers-rs have made such announcements this week. Expect more of these in the months to come.

So, if you haven't done so yet, you should be moving to Goerli or Sepolia very 🔜!

Next Steps 👀

That's it, we merged, Holy shit, we merged !!! and things didn't break! It's still a bit surreal.

timbeiko.eth

@TimBeiko

kinda wild ethereum is now just running PoS in the background like it's no biggie

1,318

2:54 PM • Oct 4, 2022

Looking ahead, planning is slowly starting for the next network upgrade, with discussions happening in both virtual and physical forums 🦄

If you want to help secure Ethereum's data layer, keep an eye out for announcements related to the KZG Ceremony. In the meantime, make sure you're moving to Goerli or Sepolia.

See you in Bogotà 👋🇨🇴!

Thanks to Joe Schweitzer & Trent Van Epps for feedback on the draft. Cover image by Ningyu He.

This one is out a little later than I would have liked, but hopefully you've followed the - deluge - of - blog - announcements over the past months. There's a lot to unpack, so let's get into it!

TL;DR 👀

• Gray Glacier went live: block times are now back to ~13s 🕰

• After Sepolia, Goerli will be the last testnet to merge --- stakers, now is the time to triple-check your setup!

  • If you have questions, join the next Merge Community Call 📣

• Kiln, Ropsten and Rinkeby are now deprecated, they will gradually be shut down after mainnet transitions to proof-of-stake 🌅

• We've had tons of community calls, mainly focused on either The Merge or EIP-4844: client implementations, specs, demos, there's a ton to dive into 🕳

Gray Glacier 🗻

The Gray Glacier upgrade recently went live, pushing back the difficulty bomb hopefully for the last time.

Why was this necessary? When previously delaying the bomb in the Arrow Glacier upgrade, the prediction script used to assess its impact on block times was off, and block times started rising faster than expected. Client teams therefore agreed to this pushback so they could focus on shipping The Merge in normal network conditions and avoid a degraded experience for users over the next few months.

The Nethermind team authored the EIP suggesting a new delay. They also wrote an excellent post explaining how they verified it would happen as expected, and why previous scripts were wrong. It's a shame we probably won't get to re-use the insights from it 🙃.

As per Etherscan, block times are back down to normal:

With this out of the way, back to The Merge!

Merge Updates 🐼

We're getting closer and closer to moving away from proof-of-work on Ethereum. With Sepolia now merged, only a single testnet merge remains: Goerli/Prater.

While the validator set on Sepolia is permissioned, anyone can run a validator on Prater, and run through The Merge with Goerli. If you run a validator on mainnet, this will be your last chance to run through the entire process on a testnet.

That said, you don't need to wait until Goerli/Prater to test things out! Ropsten is already post-merge, and its staking launchpad instance now features a merge readiness checklist ✅.

In short, there are three things to remember for stakers:

1. EL & CL Required: post-merge, to run a validator, you need to have both a full execution layer (EL) client (e.g. besu, erigon, geth, nethermind) and consensus layer (CL) client (e.g. lighthouse, lodestar, nimbus, prysm, teku) running in parallel. A few notes:

   • This is also true for non-staking nodes: to follow the chain, you will need to run an EL/CL combo.

   • Like today, stakers can run multiple validator clients on a single node. In other words, the many validators <> single EL <> single CL setup works.

2. JWT Token: to ensure that the EL <> CL client communication channel is secure, the clients need to authenticate each other. This is done using a JWT token. Some clients will generate one automatically if not passed on startup, but be sure to check your client's documentation to configure this!

3. Fee Recipient: last but not least, post-merge, validators receive priority fees from transactions when creating a block. To receive the funds, rather than burning them, a Fee Recipient address must be set. The good news is that these fees are paid on the EL, and therefore are immediately transferable by the address where they are received.

Again, if you haven't tested all of this, now is the time to stand up a node on a testnet and make sure things work as expected.

⚡️ If you'd like to go even further, and have your validators accept MEV-extracting blocks post-merge, you can run mev-boost. The Flashbots team published a piece about its design and how it fits within the broader Ethereum roadmap here ⚡️

The vast majority of merge-related changes have to do with how to run a node on the network. For end-users, no action is required. Smart contract and infrastructure providers can refer to this post for a deep dive into changes which may affect them. At a high level, they are:

1. The zeroing out of several PoW-related values in the EL block headers (difficulty, ommers, block reward, etc.)

2. The DIFFICULTY opcode being renamed to PREVRANDAO and serving as an indicator of whether The Merge happened on the network (see EIP-4399)

3. Block production going from a ~13s average time with high variance to exact multiples of 12s

4. The introduction of a finalized tag in the JSON RPC API, which returns the last finalized block on the network

All these changes can currently be tested on Ropsten, Sepolia & Kiln, and will be live on Goerli once it transitions to proof-of-stake. A Merge Community Call has been scheduled for July 15th to provide an opportunity for users and developers to ask questions about all things merge-related 😁!

Testnet Deprecation 🌅

While there was a full announcement about this, it's worth repeating that, post-merge, the two testnets maintained by client teams will be Goerli (using Prater for its Beacon Chain) and Sepolia. Kiln, Rinkeby and Ropsten will be deprecated. Kovan has already been.

Goerli, which post-merge will refer to today's Goerli/Prater network combo, will continue having an open validator set where stakers can test things before they go live on mainnet.

Sepolia, on the other hand, has a permissioned validator set. This provides application developers with a more stable network. The chain, being relatively new, also makes it easy for users to quickly sync its state and history.

The deprecated testnets will be shut down gradually over the next year. First, Kiln will be shut down shortly after The Merge happens on mainnet. Then, Ropsten is expected to be sunset before 2023. Finally, users of Rinkeby will have ~1 year to migrate before the network stops being supported.

It is worth noting that while Ropsten and Rinkeby will not be shut down right away, they may not have the same protocol rules as the Ethereum mainnet. Rinkeby will not run through The Merge so will be one upgrade behind as soon as mainnet transitions to proof-of-stake. Similarly, while Ropsten is already post-merge, no further network upgrades will be deployed on the network. If one were to happen before 2023, Ropsten would also fall behind mainnet.

If you haven't done so, now is the time to plan your testnet migration!

Community Calls 📣

In the past two months, we've had several community calls, here's an overview!

Merge Community Call 🐼

In June, a Merge Community Call provided an overview of the latest Merge progress, as well as a forum for people to ask questions about the upgrade. If you plan on attending the next one, I highly recommend watching the recording for this, as several great questions were asked. Again, the next call is scheduled for July 15, 14:00 UTC.

EIP-4844 🏗

Also known as "proto-danksharding", EIP-4844 proposes an intermediate sharding specification for Ethereum which sets the foundation for full sharding, while also immediately enabling lower transaction fees on L2s. A full website details the proposal and its benefits. There are currently two parallel 4844 development "tracks": the preparation of a KZG Ceremony and prototype implementations of the changes in clients.

The KZG Ceremony is necessary to provide a random input for the proving scheme used to verify shard data. If that last sentence didn't make sense to you, I recommend reading pintail's excellent tweetstorm explaining the purpose of the ceremony in more detail.

At a high level, the ceremony requires specifications to be written, clients who run the specification to be implemented, a coordinating server which aggregates participants' inputs to the ceremony and extensive audits of all these things. Researchers and implementers are having regular calls to coordinate and share progress updates.

A summary of the current status of the ceremony specifications was given on a recent 4844 Breakout Call. Beyond the specs themselves, a ceremony client and coordinator were prototyped during the EthPrague hackathon! Work on the production client and coordinator implementations has also begun. A rough timeline of the implementation work, audits and public ceremony is available here.

On the 4844 Breakout, the Optimism and Coinbase teams demoed a Geth/Prysm prototype which implemented the core EIP-4844 functionality. As seen in the recording, a node pair is stood up and a file is submitted as a blob on the network. The file is then retrieved from the network, and its contents are verified to match the original. The code for the prototype is available here. This was the first time 4844 was seen working in the wild!

The rest of the call focused on various design & implementation issues related to the EIP. The notes contain an overview, and an Open Issues List will be used as a central place to track the various concerns, potential solutions and next steps in addressing them. Since the call, fixes related to blob verification times have been merged into the specs 💪.

Merge Clients PEEPanEIP 😸

The Ethereum Cat Herders' PEEPanEIP series usually has EIP authors go over their proposed changes and answer hosts' questions. For The Merge, the Cat Herders have recently produced both a general overview of the changes with Mikhail Kalinin, who wrote most of the merge specs, as well as a series of deep dives with client teams.

The series is still in progress, but so far we've had appearances by Erigon, Geth, Nimbus and Besu. Prysm, Nethermind and others are scheduled in the coming weeks. If you want to contribute to client diversity but aren't sure what client to use, this series provides a great overview of the various EL and CL implementations. Stay tuned for the full set of deep dives!

Next Steps ✅

With Gray Glacier out of the way, client teams are now squarely focused on The Merge. Goerli being both the last testnet and the one with the largest community, we'd like its merge to resemble what we expect to happen on mainnet as much as possible. This way, stakers, node operators and developers can have one proper dress rehearsal before The Real Thing.

Keep an eye out on blog.ethereum.org and other community news sources for information about this final testnet transition! Once Goerli has successfully transitioned, there's only one more network left: mainnet 🚢

One year after the first Rayonism prototypes, we now have robust merge implementations across all Ethereum clients.

The path from where we are today to fully transitioning Ethereum to proof-of-stake is now clearly in sight. We need:

• [ ] A few mainnet Shadow Forks without issues

• [ ] Clients passing the various merge test suites

• [ ] Smooth deployments across existing public testnets

... and that's it! Once these things happen, and we've observed them be stable for a few weeks, we'll be ready to move to mainnet!

Let's expand on each of them.

Shadow Forks 👻

Over the past year, we've added a new step to our network upgrade process: Shadow Forks.

There have been a few explainers written about shadow forks already. In short, a shadow fork is a new devnet created by forking a live network with a small number of nodes. The shadow fork keeps the same state, history & chain ID as the main chain.

Running these allows us to observe how clients perform in conditions as close to public networks as possible. For the nodes on the shadow fork, The Merge effectively happens. After that, transactions from the main chain can be replayed on the fork, allowing us to see how nodes behave under mainnet conditions. We can also sync new nodes to the shadow fork to ensure that they still join the network as expected.

During these shadow forks, every execution layer (EL) and consensus layer (CL) client combination is tested, and the goal is for each pair to transition and keep running smoothly afterwards. With 4 EL and 5 CL clients, there are 20 pairs to test!

So far, we've had multiple Goerli shadow forks along with two mainnet ones. The second mainnet shadow fork (MSF2) went almost perfectly. Another one, MSF3, is planned for this week. If MSF3 happens without issues and remains stable afterwards, we could move towards upgrading existing testnets. To play it safe, we will continue to launch shadow forks regularly until (and perhaps even during!) testnet deployments.

In parallel to this, we are also doubling down on several other testing efforts.

Merge Testing 🗜

The Merge has been a unique upgrade to test because it spans both the execution and consensus layers of Ethereum. While we have extensive testing tools for each of these layers in isolation, a lot of new infrastructure to test cross-layer interactions has been necessary.

Hive Tests

Hive is the integration testing platform we historically used for the EL. Over the past few months, we've added the ability for it to mock CL behaviour and test various ELs against that. This has helped us test the new Engine APIs which EL and CL clients use to communicate. To test the PoW -> PoS transition, a simulator which mocks the EL behaviour will need to be added as well.

Client teams are currently prioritizing supporting Hive and ensuring they pass all test suites, while the testing teams are focused on adding EL mocking to it.

Kurtosis

In addition to our existing testing infrastructure, we have partnered with [Kurtosis] (https://www.kurtosistech.com/) to automatically spin up staging networks which we run through The Merge on a daily basis.

These help us find implementation issues across clients and monitor various network health metrics. As things stabilize on that front, the next step is to create harsher network conditions to see how clients recover. For example, pausing EL or CL clients right before the transition and unpausing them after, or removing their database post-merge and checking how they handle syncing.

... Everything Else!

In addition to improving Hive and working with Kurtosis, a long tail of testing tools were built by the client, research and testing teams to help us catch every possible edge case. They include fuzzers, bad block generators, EL/CL mockers, debugging APIs and more fuzzers. A wishlist of other tools is available here.

Our priority is getting clients to pass unit/spec tests as well as integration tests in Hive and Kurtosis. However, these other tools mentioned above can help us identify and debug edge cases we missed and then subsequently incorporate in routine test suites.

On a more human front, The Merge has massively increased the amount of cross-team coordination & collaboration on testing. CL and EL teams have had to work each other closely for the first time, ensuring that their software works with each client on the other layer. This had lead to more, and deeper, collaboration across our entire testing infrastructure 😁

Public Testnets 🏗

Once shadow forks are going smoothly and test suites are passing across all clients, we will be ready to deploy The Merge to the existing public testnets, namely Ropsten, Goerli and Sepolia.

While public testnets do not stress test clients as much as mainnet shadow forks, they require broader coordination within the Ethereum ecosystem.

The Merge requires more from node operators than previous Ethereum upgrades. In past upgrades, node operators and miners on the EL only needed to update a single piece of software: their EL client. For The Merge, they will need to download, configure and run a CL client in parallel.

On the CL side, it was always strongly recommended to run an EL node when operating a validator. Pre-merge, though, this could be outsourced to third party service providers. For The Merge, stakers will need to run an EL to verify the validity of blocks and receive transaction fees when proposing a block (or risk losing them if outsourcing their EL!).

Node operators, stakers, and infrastructure providers should make sure they test their configurations on Kiln to be ready for deployments on testnets. EthStaker has also published various tutorials on how to do this.

Once Ropsten, Goerli and Sepolia have forked and stabilized (assuming no further issues are found) we will then be ready to set a merge date for mainnet!

Mainnet 🍾

The process for transitioning the Ethereum mainnet to proof-of-stake will be identical to the process followed for testnets. That said, it is worth re-emphasizing that the transition happens in three steps:

1. Clients release software which supports The Merge and starts "listening" for a specific Total Difficulty, called Terminal Total Difficulty (TTD), value to be hit on the proof-of-work chain

2. Once the TTD is hit, the next block gets produced by the validator who is assigned to the next Beacon Chain slot. This block will be the first post-merge block and contain both end user transactions and proof-of-stake consensus data (e.g. attestations, deposits, slashings, etc.).

3. The first post-merge block is finalized. At this point, Ethereum has no more reliance on proof-of-work as part of its fork choice rule. In other words, we've fully moved to PoS 🎉

The image below by Danny Ryan illustrates the process:

The leftmost blocks show the EL and CL moving in parallel pre-merge, where PoW (EL) blocks contain transactions and Beacon Chain (CL) blocks contain proof-of-stake consensus data.

The second PoW block from the left is when TTD would have been hit or exceeded. The third block on the bottom is the first post-merge block, containing both the proof-of-stake consensus data and the execution layer transactions.

The fourth block, and subsequent ones, have no link back to proof-of-work. Once these are finalized, the network could only be disrupted beyond that point in circumstances comparable to a 51% attack under proof-of-work.

In other words, by that point, we've merged 🍾!

The Merge is by far the most complex upgrade we've ever planned for Ethereum. Teams and individual contributors have been working tirelessly for over a year now, and the finish line is finally in sight.

While everyone is excited to see Ethereum transition to proof-of-stake, this is not the time to cut corners: ensuring a safe and seamless transition for Ethereum users and the rich ecosystem built on the network is our #1 priority. We're almost there 😁!

Wen merge? 🔜.

Thank you to Trent Van Epps, Danny Ryan, Mario Vega, and others for reviews & additions to this update.

TL;DR 👀

So much has happened since January that I've struggled to find the time to write it down! Here are the highlights:

• Kiln, the latest merge testnet, has launched. The PoS transition on it revealed some implementation issues, and now it's all hands on deck for merge testing 🛠

• Shanghai, the next Ethereum upgrade, is being sketched out. EVM upgrades, Beacon Chain Withdrawals, L2 Fee Reductions and more are planned 🌃

• Work on an executable spec for Ethereum's execution layer is progressing nicely. Next step: harmonizing the EL + CL upgrade processes 📜

• Protocol Guild, an initiative to provide client developers and researchers with token-based compensation, now has over 100 members and is launching a pilot soon 💰

Kiln 🔥🧱

Following Kintsugi, the Kiln testnet was recently launched. It incorporated changes to The Merge specifications based on edge cases discovered on Kintsugi, as well as some renamings. While the specs for The Merge now seem mostly final, running through the transition on Kiln surfaced implementation issues in several clients. Teams are now doubling down on testing to ensure that all implementations are safe and stable. Danny covered this in his latest Finalized post.

Additionally, we're now asking the broader developer community to use Kiln and make sure their products work as expected. Shoutout to Kurtosis, Tenderly, Lido, Uniswap, EthStaker, Infura and Blockdaemon who've each taken a stab at it!

Assuming no critical issues are found, Kiln is expected to be the last new public testnet to be launched. The next step, once we are comfortable with client implementations and infrastructure/tooling readiness, will be to run The Merge on existing testnets, such as Ropsten, Goerli, Sepolia, etc.

As with every upgrade, we'll monitor the testnets after the upgrade to ensure they are stable. Once we are confident testnets are running as expected, we will schedule the transition for the Ethereum mainnet!

While we are close, and this is an incredibly exciting moment for the entire community, the safety of transition, more than any target date, is the #1 priority for The Merge. This is, by far, the most complex upgrade to Ethereum ever done. We want to get it right 😁.

When decided, testnet and mainnet upgrade timelines will be communicated across community publications such as Week in Ethereum, What's New in Eth2, the EF blog and many others. Anything which currently advertises a target date is wrong, as no date has been set. Be extra vigilant for potential scams/fake announcements over the coming months!

A note on the difficulty bomb 💣

The difficulty bomb, which was pushed back in the Arrow Glacier upgrade last year, is expected to be felt on the network around June. Its progression is being tracked here. While it would be ideal to transition to PoS before we need to push back the bomb, three things are worth noting:

1. The bomb's impact on block times is gradual. This means that once it starts being felt, there is still a 4-8 week range where blocks are slower, but not drastically so (think 14-17 seconds).

2. Historically, when the bomb was delayed, we've opted to push it back 6+ months because we usually planned to have another network upgrade by then. That said, there is no hard rule about how far the bomb must be delayed. It is entirely possible to delay the bomb by a month or two if that is a more appropriate delay than 6+ months.

3. Again, a safe merge >>> a quick merge. We want the transition to go smoothly, and Ethereum’s stability and security is our #1 concern.

Shanghai 🌃

As mentioned in the previous update, with the specs for The Merge mostly frozen, planning efforts have started around Shanghai. A specification for the upgrade is available here. Three major changes are tentatively planned for the upgrade, along with some small wins. Let's dive into them!

EVM Object Format ⚙️

For years, researchers and client developers have struggled with improving the EVM without breaking existing contracts. Last year, the Ipsilon team came up with a clever solution: provide new functionality to contracts which are deployed with a specific identifier, but leave existing contracts executing as is. This is now know as EVM Object Format, or EOF for short.

In the London upgrade, we reserved part of this identifier by disabling the deployment of new contracts starting with the 0xEF byte. A few contracts starting with this byte were deployed before London went live, but now that it no longer is possible to do so, we can add a second byte (called the Magic Byte 🪄) to the 0xEF prefix and get a sequence which we can guarantee isn't used by any contract.

EIP-3540 describes this in detail and highlights the first tangible benefit of the approach: the separation of code and data, which is beneficial for on-chain code validation. This could also pave the way toward introducing new contract code sections types that could help enable currently complicated features, such as Account Abstraction, control flow in the EVM and EIP-3074.

A companion EIP to 3540, EIP-3670 will enable code validation for EOF contracts upon deployment.

Beacon Chain Withdrawals 🏧

Another major feature for Shanghai is the activation of Beacon Chain withdrawals. After several proposals, we've arrived at a design that client teams are satisfied with: EIP-4895: Beacon chain push withdrawals as operations.

A meta-spec outlines how the entire process works. At a high level, in each slot, the Beacon Chain can process a set number of full or partial withdrawals. These withdrawals are tracked in receipts which contain the amount, destination address and unique index of each withdrawal. As part of the block creation and validation process, these withdrawals are then credited on the execution layer, similarly to how proof-of-work issuance is credited to miners today.

A tracking issue for the various changes required at the consensus layer to enable this is available in the consensus-specs repository. The option for partial withdrawals will allow validators to withdraw their accumulated rewards while maintaining the 32 ETH stake required to remain a validator and continue earning rewards.

Layer 2 Fee Reductions 📉

The last large thing we hope to include in Shanghai is a reduction of fees on layer 2. Because L2s post their transaction data (and/or proofs) on L1, a large part of end users' transaction fees come from the amortized gas costs of L1 data storage. Sharding offers a cheaper alternative for L2s to post their data, but while the specification seems to have settled, a full sharding implementation isn't ready yet.

In the meantime, two options are available to reduce these costs: either a CALLDATA cost reduction on mainnet, or a "proto-sharding" implementation, possible with the introduction of a new transaction type on Ethereum, called Shard Blob Transactions.

CALLDATA Cost Reduction

The simplest way to reduce transaction fees on L2s is to lower the cost of storing data on L1. EIP-4488 proposes to do this, reducing the cost from 16 gas per byte of CALLDATA to 3 gas/byte. This reduced storage cost would translate to lower L2 fees [1].

While the gas cost reduction itself is a simple change, it does have some second order effects. First, increasing the CALLDATA in blocks leads to larger block sizes. To balance this, the EIP proposes a cap to the maximum amount of CALLDATA in a block. Second, even with this cap, this EIP would increase the rate at which historical chain data grows on the execution layer. To address this, out of band historical data retrieval needs to be developed, and guarantees about historical data on the Ethereum P2P network need to be changed, as proposed in EIP-4444.

While the increase in historical chain data would happen gradually, including this EIP implies we will need to deal with the issue with increased urgency after it goes live. Additionally, little from this EIP would be reused in a full sharding implementation. It would primarily be a temporary solution. That said, the EIP is a relatively simple change to implement and does provide significant fee reductions on L2s.

Shard Blob Transactions

Another proposal, which gets us closer to a full sharding deployment, is EIP-4844 [2], which introduces Shard Blob Transactions. As with Beacon Chain withdrawals, this proposal has a meta spec linking to consensus layer specifications and other resources.

At a high-level, this new type of transaction would include commitments to blobs of data which are gossiped on the Beacon Chain. This proposal can be thought of as a "mini-sharding", where instead of relying on data availability sampling, every node on the network needs to validate all the data in blobs. Like in the full sharding context, these blobs of data are only guaranteed to be made available for some time on the network, rather than stored forever. To keep node requirements manageable, blob data is limited to 1MB/slot compared to 16mb/slot in full sharding.

EIP-4844 would lay the groundwork needed for a full sharding implementation. Notably, all future changes would be limited to the consensus layer. From the execution layer's perspective, sharding would be up and running!

The Optimism team, which has been working on the EIP, has launched a website which provides an overview of the EIP, aggregates various spec links and highlights positive community reactions to the effort.

[1] Due to other components involved in pricing L2 transactions, the reduction wouldn't be a full 5x. Optimism has a good explanation of L2 fee components here. Also, ZK rollups wouldn't benefit to the same extent as Optimistic rollups.

[2] EIP-4488 (CALLDATA cost reduction) and EIP-4844 (Shard Blob Transactions) have frustratingly similar EIP numbers for competing proposals 😅

Small Improvements ✨

In addition to these three large changes, a handful of small improvements are also being considered for Shanghai, namely:

• EIP-3651, which lowers the gas cost to access the COINBASE address, fixing an oversight in EIP-2929

• EIP-3860, which limits the size of initcode and introduces gas metering for the field

• EIP-3855, which adds a new opcode, PUSH0, that, as you'd expect, pushes 0 onto the EVM stack

In addition, there are several other EIPs proposed for the upgrade (see a rough list here). EOF, Withdrawals and Layer 2 fee reductions would already make Shanghai one of the largest upgrades to date, so we now need to be very diligent in prioritizing what we include.

Once we start implementing and testing the various EIPs, we will have a better feel for whether we have any extra capacity. Of course, we still need to get The Merge done before that!

Ethereum Execution Layer Specification (EELS) 📜

As you may have noticed above, several proposals for Shanghai now span both the execution and consensus layers. Historically, we've used different processes to introduce changes on each layer.

On the EL, Core EIPs contain changes' specifications. The Ethereum Yellow Paper is the reference specification for the network, but is often updated only after an upgrade is live, sometimes with a significant delay. This means the effective specification for the EL is often "the Yellow Paper + EIPs X, Y, Z".

On the CL, an executable specification is used as a reference, and changes are specified directly in it. The specification can then be used to generate tests for changes.

So, while the EL process is well understood by the community (and provides an easy to reference description of changes), from a technical perspective, it isn't ideal. Conversely, while the CL process is cleaner technically, it is harder for the broader community to follow. Luckily, work has begun on EELS: an executable spec for Ethereum's EL!

Having an executable specification across both the EL and CL should allow us to harmonize the change process on both layers. There are still many kinks to work out, but conversations have started about how to best do the migration. An Ethereum Magicians thread is now dedicated to the topic. While EELS is still under development, we may be able to use it during the Shanghai upgrade in parallel to the current process.

Hopefully, merging the EL & CL processes is simpler than merging the actual CL and EL 😅.

Protocol Guild 💰

Last but not least, I want to touch on Protocol Guild, which now has a full explainer website. Compensation for protocol maintainers has been a hot topic lately and PG hopes to be part of the solution. Full disclosure: I am a PG member and would receive funds from it.

You can think of compensation in three buckets: base pay, aligned incentives, and potential upside. Currently, base pay for client developers and researchers is handled through their respective employer. While some of these may provide incentives in the form of equity, the Ethereum Foundation announced its 39,000 ETH Client Incentive Program last year to ensure all client teams have a significant stake in Ethereum.

PG differs from both base compensation and the incentive program in that it aims to provide its members with exposure to a variety of tokens from projects building on ETH, rather than ETH itself. The Guild is composed of protocol engineers, researchers and a handful of folks coordinating protocol work, like myself. It currently sits at about 100 members.

In short, the Guild allows sponsors to donate tokens, which then vest over time to recipients. The recipient set can be updated, which allows for new contributors to be added and stale contributors to be removed periodically.

The Guild is still an early experiment, but if successful, could be a base-layer-focused complement to initiatives such as Gitcoin and Retroactive Public Goods Funding.

After a successful Gitcoin grant, the next step for PG is testing the smart contract architecture. In parallel to this, outreach for initial donors will begin. The plan is to run PG for ~1 year with a limited amount of donations to ensure that both the technical and governance components work smoothly. Hopefully, this pilot proves that we can create new mechanisms to coordinate public goods funding on Ethereum!

Next Steps ✅

Our main priority remains The Merge, with a renewed focus on testing. Over the next month, we are hoping to finalize implementations, run multiple short-lived devnets, and gather feedback from application, infrastructure and tooling providers. Everything else (Shanghai, execution specs, Protocol Guild) should also keep moving along in the background.

Expect another update in a month or two. In the meantime, we'll also have the chance to discuss all of this face to face at Devconnect — see you in Amsterdam 👋🏻🇳🇱!

This update comes a bit later than I would have liked. A lot has happened since the last one! Here are the highlights:

• Kintsugi was launched: you can now test post-merge Ethereum on it 🍵

• We found a couple issues on the network, leading to refinements in the spec 🐞

• Once clients have those fixes, and a new auth mechanism, another round of devnets will be launched 🚨

• Applications should start testing deployments on Kintsugi now. Its next version, Kiln, will be the dress rehearsal before existing testnets transition 🏗

• We have a community call in a few weeks to discuss all this 📣

• Shanghai is slowly being planned, with a focus on valuable EIPs which had been deprioritized, along with beacon chain withdrawals 🏧

Kintsugi & Beyond 🍵

Right before the holidays, the Kintsugi testnet launched. This was the first public, easily accessible, multi-client testnet running post-merge Ethereum!

We learned a lot from it, specifically when we encountered a bug that led to delays in finalization. On January 7th, the fuzzer running on the testnet caused a fork by creating ExecutionPayloads with hashes replaced by their parent's hash, which some clients erroneously marked as valid. Marius, who triggered the issue, had a write up on Twitter: https://twitter.com/vdWijden/status/1479414824794832900

While this bug was fairly easy to fix, it helped us discover other, more subtle, issues, which only happened when the network was in a state with multiple deep forks. Again, Marius has a thread. In short, when consensus clients sent payloads to execution clients across several forks, these would all be executed by default, slowing down clients, triggering unnecessary sync processes and, in the worst cases, causing the node to panic and shut down.

To address this, a change was made to the Engine API specification which loosened the requirements for execution clients when receiving payloads. Instead of processing them by default, the clients can choose to simply store payloads on a non-canonical chain (but must still process those on the main chain).

This change will be included in the next release of the specs. Alongside it, one more significant change will be introduced: an authentication mechanism for execution and consensus clients to use with the Engine API (PR).

The authentication mechanism will prevent users from accidentally exposing their Engine API over the open Internet, which happens periodically with JSON RPC endpoints today. While the worst case for JSON RPC endpoints being exposed is mild (someone spamming your node with requests), if the Engine API is exposed, validators could lose funds. Specifically, an attacker could send VALID responses for invalid payloads or even propose invalid ones on the network, leading to slashings. The authentication ensures that a node's consensus and execution clients are only talking to each other.

Once these changes are implemented in clients, we will launch new short-lived devnets to test implementations and interoperability. As these stabilize, expect a new Kintsugi-style testnet, Kiln, running the latest specs.

For applications, I recommend starting to look at Kintsugi today to ensure that things work as intended. While the merge only has minor changes at the execution layer (listed here), it is worth being sure that tooling, infrastructure, deployment flows, etc. all work smoothly.

That said, Kintsugi will be sunset in the coming weeks, so if you need "weeks" rather than "days" to stage a deployment, waiting for Kiln is recommended. A community call is planned for February 11th to discuss all of this in more detail!

Assuming no major issues are found, Kiln should be the last new testnet before we start looking to fork existing ones! Of course, testing of various kinds will continue throughout the process. Ensuring the network's security along with a smooth transition remains the #1 focus. Onwards!

Shanghai 🇨🇳

With the merge work nearing "the beginning of the end", discussions about what to include in the first post-merge upgrade, Shanghai, are beginning. Over the past year or two, most protocol work has centred around large initiatives such as EIP-1559 and the transition to proof of stake.

The intense focus required to ship these massive change has resulted in other, "normal-sized", proposals being deprioritized. A lot of these can bring significant value to Ethereum, and are now being considered for Shanghai. Some notable ones:

• EVM Object Format, which enables versioning of contracts and makes it easier to introduce new functionality into the EVM.

• BLS Precompiles, which provides the EVM with native execution of BLS operations.

• EIP-3074, which provides UX improvements and gas costs savings for end users.

• EIP-4488, which reduces CALLDATA costs, lowering the cost of transacting on rollups.

• EIP-1153, which introduces opcodes for transient storage, that applications can use to lower end user fees.

This isn't an exhaustive list (here's one!), but highlights that there are several valuable things we can do in Shanghai. We now need to think hard about what to prioritize! Specifically, EVM Object Format is slated for discussion about inclusion on the next AllCoreDevs call. If you have any feedback, now is a good time to share it on Ethereum Magicians.

Aside from these proposals, another feature high on the priority list for Shanghai is withdrawals from the beacon chain. While there is no formal EIP yet, it is something that needs to be taken into account when planning he upgrade. Expect more on this as soon as the merge specifications are finalized!

Next Steps ✅

As mentioned, over the next few weeks, you can expect client releases which implement the latest version of the specification. Once these are out, ephemeral devnets will be stood up for testing. Then, the Kiln testnet will launch for an (hopefully!) final round of public testing. Assuming all goes well there, we will begin transitioning existing testnets to proof of stake. A successful transition across all existing testnets is the last step before setting the date for The Merge on mainnet!

In parallel, Shanghai is slowly being planned, with an eye towards longstanding proposals we've wanted to implement for a while but simply didn't have the bandwidth for. Expect a beacon chain withdrawal spec 🔜.

Thanks for reading!

TL;DR 👀

• Arrow Glacier is happening next week - upgrade your nodes 🏔

• Kintsugi Merge devnets are being stood up - expect a long-lived one for the holidays 🍵

• A new proposal, EIP-4488, could make rollup transactions cheaper, but there are tradeoffs. A deep dive on this below 👇🏻

Arrow Glacier Arrives 🏹🧊

As mentioned in the last update, the Arrow Glacier upgrade is scheduled for block 13,773,000, which is expected on December 8, 2021. If you run an Ethereum node, you should upgrade it now. The list of client versions which support the upgrade is as follows:

• Geth 1.10.12

• Besu 21.10.0

• Nethermind 1.11.7

• Erigon 2021.11.01-alpha

• EthereumJS VM 5.6.0

For a complete overview of the upgrade, see the full announcement. Hopefully, this is the last time the difficulty bomb is delayed before Ethereum's transition to proof of stake 💣!

Kintsugi Progress 🍵

After the Amphora interop event, client teams have been hard at work on another sprint of merge devnets: Kintsugi 🍵

The goal of this effort is to incorporate the learnings from Amphora into the specification, test them on a devnet, find what breaks, add fixes to the spec, and do it all again the week after. This rapid pace of iteration allows us to see the latest spec in production weekly, and to gradually gain confidence in the client implementations.

A tracker is available with the various milestones. So far, three devnets have been launched. We are expecting to launch one more ephemeral devnet next week, and then to have a longer-lived one over the holidays. This last Kintsugi devnet will allow application developers, infrastructure and tool providers, and curious users to experiment with the (nearly!) final post-merge Ethereum spec.

For those most eager to try things, basic instructions to connect to the current devnets are available here. The full specifications for The Merge are split across the consensus specs, execution specs and Engine API specs.

CALLDATA Cost Reduction 📉

Rollups are expected to be the primary method by which computation on Ethereum is scaled. They allow users to execute their transactions on a separate sub-chain (the L2/rollup) that commits TX data to Ethereum. This removes the need for these transactions to be executed on mainnet but maintains the security and network effects of Ethereum, while allowing far more scalability. The main cost of rollup transactions is then the cost of storing their data on the L1 chain, which is currently done using a transaction's CALLDATA.

The cost of CALLDATA therefore dictates, to a large extent, the cost of transactions on rollups. [0] As of this writing, a simple ETH transfer costs a few dollars on optimistic rollups (ORs) and ~0.25$ on zero-knowledge rollups (ZKRs). While this might not seem particularly high, more complex transactions require higher fees and most of Ethereum's usage is still happening on L1. As users transition to L2, these costs will keep increasing.

To preempt this, EIP-4488 was introduced. It proposes to reduce the CALLDATA cost from 16 gas/byte to 3 gas/byte, a >5x reduction. Because CALLDATA directly increases the block size, the EIP also adds a cap on the maximum CALLDATA in a block. To accommodate non-rollup transactions, this cap can be extended by transactions who only use a small amount (<300 bytes) of CALLDATA. This helps mitigate fee market issues that come up with any scheme that adds two separate limits, in this case gas and CALLDATA.

The benefits of this EIP are clear: posting rollup data to L1 would become 5x cheaper than today relative to other EVM operations. These cost savings would continue until L1 blocks continuously hit the CALLDATA cap, which would require several times Ethereum's current usage to happen on rollups. By then, sharding may be live, which will provide another reduction in rollup transaction costs. In other words, transaction fees are the biggest pain point for users using Ethereum right now, and this EIP would provide another incentive for migration towards rollups.

There are drawbacks, though. First, the EIP would increase the rate at which the Ethereum blockchain's storage requirements grows. In the worst case, assuming all blocks hit the maximum amount of CALLDATA, the increase would be of ~3.0 TB per year. That said, while we are still far from there, Ethereum's rate of growth is already hard to manage. Ever increasing chaindata will long term be unsustainable. Proposals to cap it, such as history expiry (e.g. EIP-4444) and state expiry, are already on the roadmap. Agreeing to EIP-4488 would increase the urgency with which these changes need to be deployed to mainnet.

Second, several months ago, client teams agreed to prioritize Ethereum's transition to proof of stake above everything else. If we waited until after The Merge, it is likely this would not happen before Q4 2022, one year from now. Combining it with The Merge adds too much complexity. Hence, we are left with the option of potentially doing it before The Merge.

While any delays would likely be minimal, due to the simplicity of the change and ability of most client teams to parallelize its implementation, it does go against "The Process" and the prior decisions client teams had committed to. Also, EIPs are often discussed for months prior to being accepted in network upgrades. In this case, a decision would have to be made in the next few weeks if we plan to deploy it prior to The Merge. While this is highly unusual, rollups' importance within the Ethereum roadmap and the prevalence of high L1 fees may justify deviations from the usual processes.

If you have strong opinions about this, I encourage you to share them on the EIP's Ethereum Magicians thread. Regardless of whether EIP-4488 goes live before The Merge, the process by which we make the decision will be an important precedent in Ethereum governance.

Next Steps ✅

• Arrow Glacier is happening next week: upgrade your nodes!

• A Merge community call is scheduled for tomorrow to share the latest progress and answer questions from projects building on Ethereum;

• A long-lived Kintsugi devnet should go live before the holidays;

• Hopefully, a decision on EIP-4488 is made before the holidays as well.

Thank you to Ansgar Dietrichs, Vitalik Buterin, Danny Ryan and Dankrad Feist for reviewing drafts of this update.

[0] These are other factors which determine the total cost of a rollup transaction. For an example, see Optimism's documentation.

As promised in the previous update, this one will cover the post-merge Ethereum client architecture in depth. With the progress made during the Amphora Interop event, the specification is now close to final 🎉

Before we dive into The Merge, though, a short update on the difficulty bomb!

Arrow Glacier 🏹🧊

On AllCoreDevs #124 (recording, tweets), we agreed to push back the difficulty bomb, set to go off in December 2021, to June 2022. To do so, we will have a network upgrade, Arrow Glacier, which contains a single EIP, EIP-4345, that pushes back the bomb.

Arrow Glacier is scheduled for block 13,773,000, expected on December 8th, 2021.

We debated various options for the Ice Age pushback on AllCoreDevs. June was chosen because we had reasonable confidence that The Merge could happen before, and we wanted to avoid having to organize another difficulty bomb pushback right before it.

Of course, The Merge is independent from the bomb: it will require a separate network upgrade and is activated based on a PoW total difficulty threshold. This means that we do not need to "wait" for the difficulty bomb to go off in order to transition Ethereum to proof of stake. Similarly, if we encountered issues with the transition, we could decide to push back the bomb once more.

Hopefully, Arrow Glacier will be the last network upgrade on PoW Ethereum 🤞🏻 Onto The Merge!

Post-Merge Architecture 🏗

The architecture for The Merge leverages the fact that Ethereum already has battle-tested clients built for both its execution (Eth1) and beacon (Eth2) chains. Given that these exist, it makes sense to keep using them.

At a high-level, at The Merge, clients will switch from following PoW to following PoS to determine Ethereum's latest valid block. Aside from that, most of the clients' functionality, and, more importantly, the EVM, its state, and how it executes transactions, will stay the same.

Post-merge, the current Eth1 and Eth2 clients respectively become the execution and consensus layers (or engines) of Ethereum. This means that node operators of either Eth1 or the Beacon Chain clients will need to run the "other half" of the stack to have a fully validating node. Danny Ryan has great diagrams illustrating this. They've been minted as NFTs, with the proceeds going towards the engineers and researchers working on The Merge.

The above shows what a full Ethereum client will look like post-merge. Let's use this as our starting point to dive into each component!

Beacon Node 🚨

Today, Beacon Nodes are tasked with coming to consensus on empty (from end users' standpoint!) blocks. These contain pieces of consensus-related information, called Operations, such as attestations, the deposit contract root and validator slashings/exits, but do not contain any "transactions" in the Eth1 sense (e.g. sending ETH or interacting with smart contracts). The Merge is where this changes.

As The Merge happens, Beacon Nodes will watch the current PoW chain and wait for it to hit a predefined total difficulty threshold, called TERMINAL_TOTAL_DIFFICULTY. Once a block with total difficulty >= TERMINAL_TOTAL_DIFFICULTY is produced, it will be considered the final PoW block. Subsequent blocks will be produced and attested to by the validators on the Beacon Chain.

To do this, Beacon Nodes will communicate with their execution engine (formerly the Eth1 client) and ask it to either produce or validate ExecutionPayloads. These payloads are the post-merge equivalent of Eth1 blocks. They contain information such as the parent's hash, the state root, the base fee, and a list of transactions to execute. Once these have been produced or validated, the Beacon Node will share them with other nodes on the p2p network.

To establish communication between the consensus and execution layers, a new set of JSON RPC endpoints is introduced: the Engine API.

Engine API ⚙️

The Engine API is the communication interface between the consensus and execution layers. It is exposed on a separate port than the execution layer's public JSON RPC API. For simplicity, calls to the API are always initiated by the consensus layer and the API introduces only three methods: engine_executePayload, engine_forkchoiceUpdated and engine_getPayload. Let's go over what each of these does:

• engine_executePayload asks the execution layer to validate that an ExecutionPayload conforms to all protocol rules.

  After receiving a payload via this call, the execution layer will either return VALID/INVALID or, if it still has not synced to the tip of the chain, SYNCING. Because a block's validity is dependent on its parents' validity, if the execution layer is missing historical data to assess the payload's validity, it will fetch it from the network.

• engine_forkchoiceUpdated is how the consensus layer informs the execution layer of a new head and finalized block on the network. In the case where the consensus layer needs the execution layer to produce a new ExecutionPayload on top of the latest head block, it will pass a payloadAttributes field along with this call.

  ThepayloadAttributes field contains information relevant for the execution engine to produce an ExecutionPayload, specifically the timestamp, random and feeRecipient (formerly coinbase) values. Upon receiving this call, the execution layer will update its head, sync as needed, and, if required, begin building an ExecutionPayload with the values from payloadAttributes.

• engine_getPayload asks the execution layer to return its best ExecutionPayload whose build process was previously initiated in an associated call to engine_forkChoiceUpdated.

  This is how, when a validator must produce a block, it gets a valid one from its execution engine. Other nodes will then, upon receiving that block from the p2p layer, call engine_executePayload to assess its validity.

... and that's it! With these three new endpoints, the consensus and execution layers can communicate information about the state of the chain and transactional payloads. Now, let's dive into how the execution engine works some more.

Execution Engine 🛠

As stated above, the execution engine is what becomes of Eth1 clients after The Merge. At that point, anything related to consensus is removed from their purview. Their main focus becomes state management, as well as block creation and validation, which is modified slightly. The bulk of the changes are described in EIP-3675.

First, The Merge will require some change to the block format. Several fields, which are only relevant for PoW and not PoS, will be set to 0 (or their data-structure's equivalent). These are fields which either relate to mining (difficulty, mixHash, nonce) or to ommers (ommers, ommersHash), which are not possible in PoS. The length of extraData will also be capped to 32 bytes on mainnet.

Second, because issuance will only happen on the Beacon Chain post-merge, the execution layer will stop processing block and uncle rewards. That being said, the execution engine will still be in charge of handling transaction fees. Indeed, as it creates an ExecutionPayload, the execution engine ensures that all transaction senders can pay at least the current baseFeePerGas and that any extra fees are sent to feeReceipient. Note that feeReceipient refers to a "legacy" Ethereum address, and not a Beacon Chain validator.

Third, once PoS has taken over from PoW, execution engines will stop gossiping blocks. This means deprecating the NewBlockHashes (0x01) and NewBlock (0x07) handlers at the p2p layer. Again, the execution layer will still be in charge of syncing the network state, gossiping transactions and maintaining its transaction pool.

The following diagram, again by Danny Ryan, shows the execution layer dropping PoW and relying on the Beacon Chain as The Merge happens.

We've now covered all the core components of how clients process blocks and communicate internally post-merge. Now, let us briefly touch on the various "edges" of the system.

P2P Networking, User APIs and Sync 📡

As the first diagram in this post shows, post-merge, both the execution and Beacon Chain layers participate in a p2p network. Aside from block gossiping being deprecated on the execution layer side, everything else in the p2p network remains unchanged: Beacon Nodes will gossip attestations, slashings, etc. and the execution layer will share transactions, sync state, etc. each on their independent p2p network.

Similarly, the user APIs for both the Beacon Chain and the execution layer will remain independent, with the exception of the newly created Engine API.

The one component which will live across both layers is sync. Several syncing strategies are being developed for every possible edge case pre and post merge. These are still being refined and tested, and may be the subject of a future deep dive.. 👀

Next Steps 👀

Since Amphora, the focus has been on specification refinements and devnet testing. Over the coming weeks, expect the specifications to have settled to a point where we do not expect any more major modifications.

In the meantime, the Pithos testnet is up and running with more client combinations being tested daily, and a community call is scheduled for next week for infrastructure & tooling providers to get up to speed on The Merge. See you then 👋🏻

This one is a bit different from the others. First, I’ve decided to move these to Mirror! Using the platform for the 1559 NFT project was a really positive experience, and I’ve been looking for an excuse to use it again, so here we are. I’ll keep maintaining a list of updates on HackMD so they re easy to find in one place.

Second, given our current focus on The Merge, this post isn’t an “update” but a deep dive into the roadmap evolution which led to the current architecture choice. In a few weeks, expect a similar post going over the details of how the Ethereum network will operate post-merge.

Merge Pre-History 📜

The Merge will swap out Ethereum’s current proof of work consensus algorithm for the proof of stake mechanism running on the beacon chain. This design is the result of several iterations on the “Ethereum 2.0” roadmap. Let's recap how things changed over the past few years.

Phases 0️⃣, 1️⃣, 2️⃣

For several years, proof of stake and sharding R&D were both pretty independent from each other. During a 2018 research workshop in Taipei, a decision was made to unify both research initiatives into a single, three phrased, "Ethereum 2.0" roadmap. The workshop and general philosophy at the time is well summarized by Ben Edginton here. It was during this event that Hsiao-Wei Wang presented this now famous diagram of what "Ethereum 2.0" would look like:

This diagram pictures what each phase of the then new roadmap would deliver:

• Phase 0 would bring the beacon chain;

• In Phase 1, data shards would be added;

• In Phase 2, virtual machines would be added to each shard to enable computation in the system.

The number of shards was initially set to 100, then raised to 1024, and most recently lowered back to 64.

Early Merge 🌅

As work on the beacon chain started in 2018, it became clear that this three-phased Ethereum 2.0 roadmap would take several years to fully deliver. This, along with the growing pains from the rapid adoption of Ethereum, led to a revival of research initiatives on the proof of work chain. The umbrella term "Ethereum 1.x" was coined for these initiatives at Devcon IV, in 2018. The biggest one of these was research into Stateless Ethereum, a paradigm that would remove untouched state from the network in order to bound its growth rate.

The increased focus on making the PoW chain long-term sustainable paired with the realization that the beacon chain would be ready much earlier than other components of the Ethereum 2.0 roadmap led to an “Early Merge” proposal. This proposal would have the existing EVM chain launch as "Shard 0" of the Ethereum 2.0 system. Not only would this expedite the move to proof of stake, but it would also make for a much smoother transition for applications, as the move to proof of stake could happen without any migration on their end.

Shortly after this proposal, Danny Ryan explored how we could accomplish all this by leveraging the existing Eth1 clients in his Eth1+Eth2 client relationship post. This would massively reduce the development work to deliver a post-merge system and leverage clients which had been battle tested for years on mainnet. Following this path would also give researchers more time to figure out the open questions around Phases 1 & 2, explored here, as well as Stateless Ethereum, which is also still an active area of research.

Rollup Centric Roadmap 🎯

Fast forward to late 2020: Phase 0 is now 99% done with the beacon chain launching soon. While the work on Phase 1 is progressing nicely, Phase 2, which would enable computation on the shards introduced in Phase 1, still has many unsolved questions:

• How to transition smoothly from the current EVM chain to the sharded VMs?

• What alternative VMs can actually be deployed, performance-wise?

• How would we ensure that various VMs are indeed safe?

• How would state and balances be reconcilled across all the VMs?

• … and more

At the same time, progress on rollups (i.e. Layer 2 scaling) is rapidly happening. Several teams announce testnets, with promising early results.

Around this time, Vitalik wrote a long Ethereum Magicians post arguing that we should focus our short and medium term scaling efforts around rollups. Not only would they be on mainnet before Phase 2 would be done, but they would also be the largest beneficiaries of Phase 1. Rollups generate a lot of data, and shards can offer cheaper storage for it than the EVM chain. From the post itself:

This approach would have several impacts on the Phase 0-2 roadmap. Specifically:

• Phase 0 (the beacon chain) which was now running on testnets ahead of mainnet launch, could become Ethereum’s consensus engine as soon as the PoW chain was ready, rather than after Phase 2;

• Phase 1 (data sharding), still several years away, went from being a critical blocker to scaling to an incremental improvement which would reduce the cost of already developed scaling solutions (e.g. rollups);

• Phase 2 (sharded execution), the more complex feature with the most open research questions, could be pushed out several years or cancelled entirely without any impact on the scaling roadmap.

The research community quickly rallied around this proposal and within a month had produced an ethresear.ch post detailing the current plan for The Merge!

Current & Future Roadmap 🗺

Executable Beacon Chain ⛓

The current architecture for the merge was first detailed in the "Executable Beacon Chain" post by Mikhail Kalinin in November 2020. In short, it combined the following insights from the various iterations to the Ethereum 2.0 roadmap:

• The beacon chain is live, and can now be used as a consensus engine;

• Rollups are the best short term solution for scaling computation;

• The current Eth1 clients form the best basis for the execution layer post-merge;

• The move to proof of stake can be done with minimal impact on the currently running applications.

The one big change Mikhail proposed was that instead of having the current EVM chain be "Shard 0," it could be coupled to the beacon chain directly.

This is a simple but important insight: Eth1 execution clients are already built in a way where the consensus algorithm can be swapped. Mainnet uses proof of work, but testnets and private Ethereum networks use various proof of authority consensus algorithms (clique, IBFT, etc.).

In his post, Mikhail proposed to have proof of stake "simply" be a new consensus algorithm that clients use. In other words, to merge the current proof of work chain with the beacon chain. The following diagram by Trent Van Epps illustrates the transition:

This approach would minimize the work that client teams on the PoW chain need to do, while still delivering all the benefits of the Early Merge and Rollup Centric Roadmap [1].

Rayonism ☀️

To validate that the Executable Beacon Chain architecture was viable, clients prototyped it over the course of a month-long hackathon named Rayonism.

Within a few weeks, all combinations of Eth1/Eth2 clients were turned into hybrid, post-merge, clients running transactions in the EVM and coming to consensus via the beacon chain.

At a high level, the current Eth2 nodes were repurposed as the consensus layer of the network, and the current Eth1 nodes as its execution layer. The consensus layer's functionality was expanded to send the latest chain head information to, and request blocks from, the execution layer. The execution layer was still in charge of processing blocks, gossiping transactions, storing and managing the state and handling JSON RPC requests.

This experiment validated that the Executable Beacon Chain architecture was sound and could be use as the basis for the transition to proof of stake, now dubbed The Merge.

PoW -> PoS transition ⛏

One thing that was not tested as part of Rayonism was the transition from a live PoW network to one running under PoS. After a few iterations, a specification for this is now roughly finalized.

To transition from proof of work to proof of stake, a TERMINAL TOTAL DIFFICULTY will be set in clients [2]. Once a block is seen exceeding that difficulty on the proof of work chain, clients will enter a transition mode where they begin listening to the proof of stake layer for consensus. As soon as the consensus layer has finalized a block whose difficulty exceeds the TERMINAL TOTAL DIFFICULTY, the execution layer will stop listening for and gossiping PoW blocks entirely. And then, voilà, The Merge is done 🎉!

For applications, this won't cause any disruption to contracts or users. A few opcodes will be updated and that's about it. For beacon chain node operators, the merge will require choosing an execution engine . Similarly, if you are running a node on the proof of work network, the merge will require choosing a consensus client. You can expect multiple devnets, tutorials and calls to discuss this as the work on the merge progresses!

Next Steps 🛠

While the general approach for The Merge is now set, there is still a long list of things that client teams need to do over the next few months. The bulk of the TODOs are tracked here, and notable ones include finalizing post-merge sync protocols, setting up integration tests for the entire process, launching devnets & running them under adverse conditions, and planning for a variety of contingencies during the transition.

If you'd like to dig into the actual specs, EIP-3675 details the changes that will be required for the execution-layer clients, and the merge folder in the consensus specs details the changes to the consensus layer.

Once things are a bit more settled, expect another post going into the details of how Ethereum clients will work post-Merge. Thanks for reading, and see you next time 👋🏻!

Thanks to Danny Ryan, Trent Van Epps and Mikhail Kalinin for feedback on drafts fo this post.

[1] One notable change is that "Stateless Ethereum" is no longer a prerequisite for the move to proof of stake.

[2] Relying on the total difficulty rather than the block or slot number allows for better management of re-orgs during the transition phase. For more on this, see "Transition process" section of EIP-3675.