Ethereum Developer Conference Review: Cancun Upgrade, Hard Fork and Prague

Author: Christine Kim, Vice President of Research, Galaxy;Compilation: Qin Jin Carbon Chain Value

On January 4, 2024, Ethereum developers gathered at Zoom for All Core Developers Execution (ACDE ) on Call #178. The ACDE call, typically hosted by Ethereum Foundation protocol lead Tim Beiko, is a biweekly series of meetings where developers discuss and coordinate changes to the Ethereum Execution Layer (EL). This week’s meeting was hosted by an anonymous Geth EL developer who goes by the screen name “Lightclient.” The developers have reconfirmed the next three public testnet activation dates for the Cancun/Deneb (Dencun) upgrade. They also discussed priorities for code changes (EIPs) in Prague/Electra, the next hard fork upgrade after Dencun.

Dencun Update

There will be no Dencun upgrade during the holidays Specific updates. Since the last ACDE conference call on December 21, the client team has been preparing a new version for the Goerli testnet. Due to previous delays in upgrade testing due to Prysm, Geth developer Marius van der Wijden asked the Prysm client team to provide an update on their progress in cutting the new version. Prysm developer Terence Tsao confirmed that the Prysm team will prepare a new version of the Goerli hard fork next week. However, the version for Goerli will be a "pre-release" version, which means it will not be the version of Prysm recommended for use on the Ethereum mainnet. After the Goerli hard fork, the Prysm team plans to release another version with certain changes and updates, which users are recommended to run on the mainnet and tested on the Sepolia or Holesky testnets.

While Tsao stated that the Prysm team is comfortable with the Goerli hard fork activation date of January 17th, as discussed on ACDE #177, he suggested that The activation date for Sepolia and Holesky hard forks will be determined after the Goerli hard fork. Since ACDE #177, Tim Beiko, head of protocol support at the Ethereum Foundation, has proposed public testnet fork times for the three Ethereum public testnets: Goerli, Sepolia, and Holesky. The recommended fork activation time is as follows:

Goerli--January 17, 2024--Era 231680--Timestamp 1705473120

Sepolia--January 30, 2024--Era 132608--Timestamp 1706655072

Holesky--February 7, 2024--Era 29696—Timestamp 1707305664

Lightclient asked other client teams outside of Prysm if they agreed with Beiko’s proposed activation time for the Goerli hard fork. All client teams participating in the call (including Geth, Lodestar, Lighthouse, Teku, and Besu) confirmed that they feel the timing is good to have a release for Goerli node operators next week at the latest. The Lighthouse client team noted that given that they are still testing some networking features of their client, the version they release may be a pre-release version like Prysm.

Dencun timeline divergence

Subsequently, Lightclient discussed Sepolia Discuss the recommended activation time for the Holesky testnet. A Prysm developer (pseudonym) with the online name "Potuz" suggested delaying the determination of the upgrade dates for the last two testnets before the mainnet. "We should try not to commit to a date now because things might not go well with Goerli and going back from there is a problem. It would be easy to add a new version with the correct epoch and make no changes. It would be easier to delete a version and fix the bugs That's a problem. It's much longer than a few weeks," Potuz said.

Lightclient emphasized that the client team does not need to release a new version until a week after the Goerli hard fork, so unless it is on Goerli on January 24th or later Upgrade issues are found, otherwise the new version will not necessarily be deleted. Geth developer Marius van der Wijden said that he sees no harm in setting dates for the Sepolia and Holesky testnets, since developers can change the dates at any time if problems arise on Goerli.

Barnabas Busa, DevOps engineer at the Ethereum Foundation, wrote in the Zoom chat room that in his opinion, only after confirmation After Goerli's version is running normally, it is necessary to release new versions for Sepolia and Holesky upgrades. A Lighthouse developer who goes by the online name "Sean" agreed, saying that developers can set a "tentative" date for the Sepolia hard fork, but should first see the progress of Goerli before January 30. Condition.

Potuz recommends adding a week of testing between Goerli and Sepolia hard fork activations, essentially using two weeks for analysis instead of three. He said adding a week of testing time allows the client release to "soak" for a few days before the client team needs to cut a new version again for the next testnet upgrade. "Two weeks is too close. That's what I'm pointing out." Potuz added that if the Goerli client distribution is fully analyzed and tested, it may not take three days between Sepolia and Holesky hard fork activation. Weekly turnaround time.

Potuz's views sparked controversy. Ansgar Dietrichs of the Ethereum Foundation said that the time between the activation of the first public testnet of the upgrade and the activation of the upgraded mainnet is usually the "deadline" for developers. Need to be extended. However, Dietrichs also pointed out that developers should discuss the desire to extend the interval between testnet upgrades more seriously in the context of a hard fork, not just the Dencun upgrade. Dietrichs said: "If someone wants a longer process, then we should discuss this issue when we have time, not before the hard fork."

Lightclient agrees with Dietrichs and believes that if discussions had been held as early as October, developers would likely be more tolerant of extending Dencun's testnet schedule. Lightclient said: I think part of it is, we wanted to complete the upgrade last fall, so now that we are really trying to achieve that goal, I think our timeline should be a little more aggressive.

Stick to an aggressive schedule

According to the developer’s According to the views shared on the conference call, Ethereum Foundation DevOps engineer Parithosh Jayanthi suggested delaying the Sepolia hard fork upgrade by about a week and setting the date of the Sepolia hard fork at the ACDE conference call on January 25 after the Goerli upgrade. Marius van der Wijden objected to relying entirely on the ACDE call to renegotiate the testnet upgrade activation date. "What I really want to avoid is us having to make another All Core Devs call to confirm the date," he said, adding: I hate having to make another All Core Devs call just to say, 'OK, Sepolia is available now. It’s started.” Now we have to wait two weeks before we can actually start implementing Sepolia.

To appease the emotions of all parties, Geth developer Guillaume Ballet suggested creating two sets of tentative dates for the Sepolia hard fork, should the outcome of the Goerli hard fork be If the outcome of the Goerli hard fork is negative, developers can stick with one set of dates; if the outcome of the Goerli hard fork is negative, developers can stick with another set of dates. However, both Lightclient and Dietrichs are opposed to this idea because the nature of the bugs and issues on Goerli must be assessed before developers can set a new timeline for the Sepolia hard fork.

By the way, a developer with the pseudonym "Danceratopz" on the Ethereum Foundation test team asked if the developer wanted to wait until Goerli was evaluated. Test blob expiration issues on the network before upgrading Sepolia. As background, blob expiration refers to the removal of blob data from the Ethereum state after approximately two weeks.

Sean from Lighthouse and Justin Florentine from the Besu team both favor evaluating blob expiration on one of three testnets before activating Dencun on the mainnet . Florentine emphasized that waiting for blob expiration on the testnet will also help the second-layer Rollup protocol team and application developers prepare for the Dencun upgrade. Sean from Lighthouse said that while observing blob expiration on Goerli is not necessary, it may be a reason to extend the testing period between Sepolia and Holesky so that developers and second-tier teams can go through the entire blob on Sepolia life cycle. Other developers on the call didn't explicitly agree with Sean's suggestion.

Instead, Lightclient asked developers on the conference call if they would stick to Beiko's proposed schedule of upgrading Sepolia on January 30, followed a week later by February 7 Upgrade Holesky on a daily basis. Since there are no more disagreements among the developers, Lightclient said the developers will stick to the original schedule. Potuz wrote in a Zoom chat that he hopes to upgrade both the Sepolia and Holesky testnets on February 7, rather than upgrading the former a week earlier. In a Discord message after the call, Lightclient reconfirmed that Dencun’s testnet schedule remains unchanged for the time being.

Prague/Electra

Next, developers discuss Which EIPs should be prioritized for the next upgrade (Prague/Electra) after Dencun is installed. Marius van der Wijden said developers should focus on completing Prague/Electra’s Merkle tree upgrade rather than other EIPs. He added two caveats to this view, the first being the readiness of the Merkel tree. As discussed on ACDE #177, the developers are planning a dedicated ACDE call to delve into the implementation details of the Merkle tree and its readiness for hard fork upgrades.

The second consideration mentioned by Van der Wijden is the ability to decouple upgrades on EL from the consensus layer (CL). Van der Wijden mentioned that 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. “I think it’s important that the consensus layer people discuss whether they need to hard fork these [emergency] changes, whether it can be done without EL involvement, or whether EL involvement is required, which we need anyway Do a joint hard fork, and then I can live with a smaller hard fork.” "So the Merkle tree is definitely a top priority and we should push for it with these two points in mind," van der Wijden said.

Ethereum Foundation researcher Ansgar Dietrichs wrote in a Zoom chat room that he was “strongly opposed” to focusing the Prague/Electra upgrade on the Merkel tree because of concerns about the Merkle tree. The complexity of the code changes required for Kerr trees will likely mean that the upgrade will be delayed until 2025. Nethermind client developer Lukasz Rozmej agrees with Dietrichs. "My experience tells me that state redesign is very difficult and takes a very long time," Rozmej said, adding, "While I think Merkle trees are very good and great progress is being made, I Think if we just focus on Merkel, the next hard fork will be at least a year away, if not longer. So my suggestion is to maybe focus on some smaller hard forks while each team works on Merkel and allocate appropriate resources, workload, brain power, whatever you want to call it, to this topic."

Sponsored Business Content

Focus on Merkel< /strong>

Developers disagree on whether Prague/Electra should focus on Merkel or prioritize smaller code changes that can be released faster than Merkel one. Ballet emphasized that in his opinion, "there are no minor forks," and the longer developers wait before implementing Merkle, the harder it will be to implement Ethereum state updates. Tomasz K. Stańczak, also a developer of the Nethermind client, suggested an ambitious approach, committing to more EIPs than Prague/Electra might include. [Let’s] leverage the capabilities of our team, and in this year we have to prove we can handle our biggest challenges. If Merkel finally signals to the team that more and more difficulties are piling up by March, then people may again raise questions and say "Okay, Merkel is out". But we will continue to use a pretty good set of other EIPs that we will include, Stańczak said, specifying that in addition to Merkel, some other important EIPs that Prague/Electr may include, such as those related to staking, re-staking and EIP related to account abstraction.

In response to Stańczak's question, Lightclien said that after developers have committed to a set of EIPs, it may be difficult to continue discussing which EIPs should be included in Prague/Electra. One of the EIPs (referring to Merkel) is "a project that will take 18 to 24 months." Andrew Ashikhmin, the developer of the Erigon client, favored releasing a smaller EIP in the Prague/Electra fork while developing Merkle for use in subsequent forks. Ballet endorsed Stańczak's suggestion to focus on developing Merkel in Prague/Electra and to remove it from the upgrade if major problems in its implementation were found to require more time to resolve.

Focus on CL upgrade

About EL (execution layer ) and CL (consensus layer) upgrade decoupling issue, Potuz mentioned that Prague/Electra only has one EIP proposal that only requires changes to the CL. "The only change is the removal of the Certification Index Board...and all the other changes, even those that seem to only involve CL, like Max EB, are dependent on other changes in EL. So I think purely A CL fork is not going to happen. At least, I don’t think it will happen this year, and not next year. We don’t have enough pure CL proposals,” Potuz said.

Despite this, Ansgar Dietrichs said that some EIPs are mainly CL-centric upgrades that only require slight changes to EL and the EL client team can Easy execution. These EIPs still require EL and CL to coordinate the hard fork. Dietrichs later added that he believes Data Availability Sampling (DAS) is the most important code change after EIP 4844 from a CL perspective. Dietrichs and Lightclient have some disagreements over whether DAS requires a hard fork to be implemented.

Follow EOF and other EIPs

A network name A developer under the pseudonym "Rodiazet" works on the Ethereum Foundation's Ipsilon team, which is dedicated to research on the Ethereum Virtual Machine (EVM). As background, EOF is the abbreviation of EVM Object Format, a series of improvements to EVM that was originally considered for inclusion in the Cancun/Deneb upgrade.

In addition to Merkel, the developers also proposed some other EIPs for consideration, such as EIP 5920 (PAY opcode) and EIP 2537 (BLS12-381 curve operation precompiled). The full list of Prague/Electra candidate EIPs can be found in the upgrade meta thread on the Ethereum Magician website. While most developers are in favor of prioritizing Merkel to some extent after Cancun/Deneb, it is unclear to what extent Merkel should be prioritized for Prague/Electra over those in 2024 Small EIPs that can be implemented faster and easier. Lightclient emphasized that developers do not need to make final decisions on Prague/Electra content during this week's conference call. He suggested continuing the discussion on the topic during an upcoming ACDE conference call.

The developers quickly then talked about EIPs in the Prague/Electra topic that had not yet been discussed on the call, including but not limited to the following EIPs:

< strong>EIP-6913: SETCODE instruction

EIP-7377: Migration transaction

EIP-4444: Binding historical data in execution client

EIP -6404: SSZ transaction root

EIP-6465: SSZ extraction root

EIP-6466: SSZ receipt root

EIP-7212: Precompile secp256r1 Curve Support

For a detailed overview of the views on the above EIP, please see the full call recording posted on YouTube.

EIP 7587 is officially confirmed

Finally, the Ethereum Fund Society researcher Carl Beekhuizen revived discussions about EIP 7587, which would reserve a set of precompiled addresses for use by layer 2 protocols. Beekhuizen asked developers how best to formalize the EIP into an informational EIP that creates norms for future Ethereum governance processes. Nethermind developer Ahmad Bitar suggested incorporating the EIP into the EIP 1 document, which outlines guidelines for the EIP process. Lightclient recommends discussing this topic further on the Ethereum Magician website and revisiting it as needed during the next ACDE call.