Ethereum Developer Meeting Recap: Cancun Upgrade, Hard Fork, and Prague
TechFlow Selected TechFlow Selected
Ethereum Developer Meeting Recap: Cancun Upgrade, Hard Fork, and Prague
The meeting also discussed the priority of code changes for the next hard fork upgrade, Prague/Electra, following Dencun.
Navigating Web3 tides with focused insightsAuthor: Christine Kim, Vice President of Research at Galaxy
Translation: Qin Jin, Carbon Value Chain
On January 4, 2024, Ethereum developers gathered on Zoom for All Core Developers Execution (ACDE) Call #178. ACDE calls are typically hosted by Tim Beiko, protocol support lead at the Ethereum Foundation, and serve as a biweekly series where developers discuss and coordinate changes to Ethereum’s execution layer (EL). This week's meeting was chaired by an anonymous Geth EL developer using the pseudonym "Lightclient." Developers reaffirmed the upcoming activation dates for the Cancun/Deneb (Dencun) upgrade across three public testnets. They also discussed priorities for code changes (EIPs) in the next hard fork after Dencun—Prague/Electra.
Dencun Update
No specific updates were made regarding the Dencun upgrade during the holiday period. Since the previous ACDE call #177 on December 21, client teams have been preparing new versions for the Goerli testnet. Due to prior delays in upgrade testing caused by Prysm, Geth developer Marius van der Wijden asked the Prysm client team for an update on their progress toward cutting a new release. Prysm developer Terence Tsao confirmed that the Prysm team would be ready with a new version for the Goerli hard fork next week. However, the version for Goerli will be a "pre-release," meaning it won't be the recommended version for running on the Ethereum mainnet. After the Goerli hard fork, the Prysm team plans to release another version incorporating certain changes and updates, which they will recommend users run on mainnet and test on either Sepolia or Holesky testnets.
While Tsao expressed satisfaction with the proposed Goerli hard fork activation date of January 17, as discussed during ACDE #177, he suggested finalizing the activation dates for Sepolia and Holesky only after the Goerli hard fork. Since ACDE #177, Tim Beiko, protocol support lead at the Ethereum Foundation, has proposed fork timing for all three major Ethereum public testnets—Goerli, Sepolia, and Holesky. The suggested fork activation times are as follows:
-
Goerli — January 17, 2024 — Epoch 231680 — Timestamp 1705473120
-
Sepolia — January 30, 2024 — Epoch 132608 — Timestamp 1706655072
-
Holesky — February 7, 2024 — Epoch 29696 — Timestamp 1707305664
Lightclient asked other client teams besides Prysm whether they agreed with Beiko’s proposed Goerli hard fork activation time. All participating client teams—including Geth, Lodestar, Lighthouse, Teku, and Besu—confirmed that the timing works well and that they expect to release versions for Goerli node operators by next week at the latest. The Lighthouse client team noted that their release might also be a pre-release, similar to Prysm’s, as they are still testing certain networking features of their client.
Dencun Timeline Disagreement
Next, Lightclient opened discussion on the proposed activation times for the Sepolia and Holesky testnets. A Prysm developer using the pseudonym "Potuz" suggested holding off on committing to upgrade dates for the last two testnets before mainnet. "We should try not to commit to dates right now because things could go wrong on Goerli, and rolling back from there is problematic. Adding a new version with the correct epoch without any changes is easy. Removing a version and fixing bugs is problematic—it takes much longer than a few weeks," Potuz said.
Lightclient emphasized that client teams wouldn’t need to cut a new release until one week after the Goerli hard fork, so unless issues with the upgrade are discovered on Goerli on or after January 24, there wouldn’t necessarily be a need to withdraw the new version. Geth developer Marius van der Wijden stated he saw no harm in setting dates for the Sepolia and Holesky testnets, since developers could always adjust them if problems arise on Goerli.
Barnabas Busa, DevOps engineer at the Ethereum Foundation, wrote in the Zoom chat that, in his view, new versions for Sepolia and Holesky upgrades should only be released once the Goerli version is confirmed to be working properly. A Lighthouse developer using the pseudonym "Sean" agreed, saying developers could set a "tentative" date for the Sepolia hard fork but should first observe how Goerli progresses before January 30.
Potuz suggested adding a one-week buffer between the Goerli and Sepolia hard fork activations, effectively reducing the analysis window from three weeks to two. He argued that the extra week would allow client releases to “soak” for several days before teams need to cut new versions again for the next testnet upgrade. "Two weeks is too close. That’s the issue I’m pointing out." Potuz added that if Goerli client releases are thoroughly analyzed and tested, there may not need to be a full three-week turnaround between Sepolia and Holesky hard fork activations.
Potuz’s viewpoint sparked debate. Ansgar Dietrichs from the Ethereum Foundation said the time between the first public testnet activation and the mainnet activation of an upgrade is typically treated as a developer “deadline,” and doesn’t usually need to be extended. However, Dietrichs also noted that the desire to extend testnet upgrade intervals should be more seriously discussed in the context of hard forks generally, not just for Dencun. "If someone wants a longer process, we should discuss this when we have time—not right before a hard fork," Dietrichs said.
Lightclient agreed with Dietrichs, noting that had the discussion occurred earlier—say, in October—developers might have been more open to extending Dencun’s testnet timeline. "I think part of it is also that we wanted to get this done last fall, so now we’re really pushing to meet that goal. I think our schedule should be a bit more aggressive," Lightclient said.
Maintaining an Aggressive Timeline
Based on input shared during the call, Parithosh Jayanthi, DevOps engineer at the Ethereum Foundation, suggested postponing the Sepolia hard fork upgrade by about a week and finalizing the Sepolia hard fork date during the ACDE call on January 25—after the Goerli upgrade. Marius van der Wijden opposed relying entirely on ACDE calls to re-discuss testnet upgrade activation dates. "What I really want to avoid is having to do another All Core Devs call just to confirm the date," he said, adding, "I hate having to do another All Core Devs call just to say 'Okay, Sepolia can now begin.' And then we have to wait two weeks before we can actually start implementing Sepolia."
To accommodate various concerns, Geth developer Guillaume Ballet suggested creating two sets of tentative dates for the Sepolia hard fork—one to use if the Goerli hard fork outcome is positive, and another if it’s negative. However, both Lightclient and Dietrichs opposed the idea, arguing that assessing the nature of bugs or issues on Goerli must come before setting alternative timelines for Sepolia.
Incidentally, a developer from the Ethereum Foundation’s test team using the pseudonym "Danceratopz" asked whether developers wanted to wait and assess blob expiry issues on the Goerli testnet before upgrading Sepolia. For context, blob expiry refers to the deletion of blob data from Ethereum’s state after approximately two weeks.
Lighthouse’s Sean and Besu’s Justin Florentine both supported evaluating blob expiry on one of the three testnets before activating Dencun on mainnet. Florentine emphasized that waiting for blobs to expire on a testnet would also benefit Layer 2 rollup protocol teams and application developers preparing for the Dencun upgrade. Sean from Lighthouse said that while observing blob expiry on Goerli isn’t strictly necessary, it could justify extending the testing period between Sepolia and Holesky so developers and Layer 2 teams could experience the full blob lifecycle on Sepolia. Other developers on the call did not explicitly agree with Sean’s suggestion.
Instead, Lightclient asked participants on the call whether they were comfortable sticking with Beiko’s proposed timeline—upgrading Sepolia on January 30 and Holesky one week later on February 7. With no further objections raised, Lightclient indicated that developers would proceed with the original schedule. Potuz wrote in the Zoom chat that he would prefer upgrading both Sepolia and Holesky testnets on February 7 rather than upgrading Sepolia one week earlier. In a Discord message after the call, Lightclient reiterated that the Dencun testnet timeline remains unchanged for now.
Prague/Electra
Next, developers discussed which EIPs should be prioritized for the next upgrade after Dencun—Prague/Electra. Marius van der Wijden said developers should focus on completing the Merkle tree upgrade for Prague/Electra rather than pursuing other EIPs. He added two caveats to this view. First, the readiness of the Merkle tree implementation. As discussed during ACDE #177, developers plan to hold a dedicated ACDE call to dive into implementation details and assess hard fork readiness for the Merkle tree.
The second caveat mentioned by van der Wijden was the possibility of decoupling upgrades on the execution layer (EL) from those on the consensus layer (CL). He noted there are some “high-priority, super urgent” EIPs on the CL that may need to be implemented faster than the Merkle tree upgrade on the EL. "It’s important that consensus layer folks discuss whether these [urgent] changes require a hard fork, whether they can be done without EL involvement, or whether EL participation is needed—in which case we’d need a joint hard fork anyway—and then I’m fine with a smaller hard fork," van der Wijden said. "So the Merkle tree is absolutely top priority, and we should push it forward keeping these two points in mind."
Ansgar Dietrichs, researcher at the Ethereum Foundation, wrote in the Zoom chat that he “strongly opposes” making the Merkle tree the central focus of the Prague/Electra upgrade, as its complex code changes could likely delay the upgrade until 2025. Lukasz Rozmej, a Nethermind client developer, echoed Dietrichs’ view. "My experience tells me that redesigning state is extremely difficult and takes a very long time," Rozmej said, adding, "While I think the Merkle tree is excellent and great progress is being made, I believe if we focus solely on Merkle, the next hard fork will take at least a year or longer. Therefore, my suggestion is to perhaps focus on some smaller hard forks, while each team continues working on Merkle and allocates appropriate resources, effort, brainpower—whatever you want to call it—to this topic."
Focusing on Merkle
Developers were divided on whether Prague/Electra should focus on the Merkle tree or prioritize smaller code changes that could ship faster than Merkle. Ballet emphasized that, in his view, “there’s no such thing as a small fork,” and the longer developers wait before implementing Merkle, the harder it becomes to implement Ethereum state updates. Tomasz K. Stańczak, also a developer at Nethermind, advocated for an ambitious approach—committing to more EIPs than Prague/Electra might otherwise include. "Let’s leverage the capabilities of our teams this year to prove we can tackle the biggest challenges. If Merkle eventually shows teams increasing difficulties mounting by March, people might reconsider and say, ‘Alright, Merkle is off.’ But we’ll continue with a fairly solid set of other EIPs we plan to include," Stańczak said, specifying additional important EIPs that Prague/Electra could include beyond Merkle, such as those related to staking, restaking, and account abstraction.
In response to Stańczak, Lightclient said it might be difficult for developers to continue discussing which EIPs should be included in Prague/Electra after committing to a set of proposals, especially when one of them—the Merkle tree—is “a project that requires 18 to 24 months.” Andrew Ashikhmin, developer of the Erigon client, favored releasing smaller EIPs in the Prague/Electra fork while simultaneously developing Merkle for inclusion in a later fork. Ballet supported Stańczak’s suggestion—focusing development on Merkle in Prague/Electra, but removing it from the upgrade if significant implementation challenges emerge requiring more time.
Focusing on CL Upgrades
Regarding the potential to decouple EL (execution layer) and CL (consensus layer) upgrades, Potuz pointed out that only one EIP proposal for Prague/Electra requires changes purely to the CL. "The only change is removing the committee index from attestations... and all other changes—even those that appear to involve only CL, like Max EB—depend on other changes in the EL. So I don’t think a pure CL fork will happen. At least, I don’t think this year or next. We simply don’t have enough pure CL proposals," Potuz said.
Nevertheless, Ansgar Dietrichs said some EIPs are primarily CL-focused and require only minor EL modifications that EL client teams could easily implement. These EIPs would still require coordinated hard forks between EL and CL. Dietrichs then added that, from the CL side, Data Availability Sampling (DAS) is the most important code change following EIP-4844. Dietrichs and Lightclient disagreed slightly on whether DAS requires a hard fork to implement.
Focusing on EOF and Other EIPs
A developer using the pseudonym "Rodiazet," who works with the Ipsilon team at the Ethereum Foundation focused on Ethereum Virtual Machine (EVM) research, contributed to the discussion. For context, EOF stands for EVM Object Format—a suite of EVM improvements originally considered for inclusion in the Cancun/Deneb upgrade.
In addition to Merkle, developers mentioned other EIPs for consideration, such as EIP-5920 (PAY opcode) and EIP-2537 (precompiles for BLS12-381 curve operations). A complete list of candidate EIPs for Prague/Electra can be found in the upgrade meta-thread on Ethereum Magicians. While most developers agree that Merkle should be prioritized to some extent after Cancun/Deneb, it remains unclear to what degree Merkle should take precedence over smaller EIPs that could be implemented faster and more easily in 2024. Lightclient stressed that developers don’t need to make a final decision on Prague/Electra’s contents during this week’s call. He suggested continuing discussion on the topic during upcoming ACDE calls.
Subsequently, developers briefly touched on EIPs within the Prague/Electra scope that hadn’t yet been discussed on the call, including but not limited to:
-
EIP-7002: EL-triggerable exits
-
EIP-7549: Move committee index outside attestation
-
EIP-3074: AUTH and AUTHCALL opcodes
-
EIP-6110: Deposit validators on-chain
-
EIP-6913: SETCODE instruction
-
EIP-7377: Migration transactions
-
EIP-4444: Pruning historical data in execution clients
-
EIP-6404: SSZ transaction root
-
EIP-6465: SSZ withdrawal root
-
EIP-6466: SSZ receipt root
-
EIP-7212: Precompile for secp256r1 curve support
For a detailed overview of perspectives on the above EIPs, refer to the full recording of the call published on YouTube.
Formalizing EIP-7587
Finally, Carl Beekhuizen, researcher at the Ethereum Foundation, revisited the discussion around EIP-7587, which proposes reserving a set of precompile addresses for Layer 2 protocols. Beekhuizen asked developers how best to formalize the EIP as an informational document to establish norms for future Ethereum governance processes. Ahmad Bitar, a Nethermind developer, suggested incorporating the EIP into EIP-1, the document outlining guidelines for the EIP process. Lightclient suggested further discussion on Ethereum Magicians and revisiting the topic on a future ACDE call as needed.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@galaxyhq
