Partnered With:

Summary of the latest meeting of Ethereum core developers: Constantinople upgrade will take place on January 17th on the Goerli testnet, with priority given to Prague/Electra code changes.

Read this article in 21 Minutes

On January 4th, all core developers of Ethereum participated in the 178th All Core Developers Execution (ACDE) conference call.

The original title: "Ethereum All Core Developers Execution Call #178 Writeup"

The original author: Christine Kim

The original translation: Luccy, BlockBeats

Editor's note:

The Ethereum All Core Developers Execution (ACDE) consensus call is held every two weeks to discuss and coordinate changes to the Ethereum Execution Layer (EL). This is the 178th conference call of the ACDE. During this call, the KanKun upgrade time on the Goerli test network was reconfirmed to be January 17th, and January 30th and February 7th were respectively designated as the Sepolia test network upgrade and the Holesky test network upgrade dates. If everything goes smoothly, developers will release the Goerli client next week. If there are any issues within the first 24 hours after the fork, the upgrade time will be rescheduled.

In addition, the meeting discussed the activation date of the public test network for the Cancun/Deneb (Dencun) upgrade, and reiterated the priority of the EIPs for the hard fork upgrade Prague/Electra. Developers discussed the importance of the Verkle tree upgrade in Prague/Electra, and made suggestions on how EIP 7587 could be formalized as an informational EIP to standardize future Ethereum governance processes.

Christine Kim, Vice President of Research at Galaxy Digital, made a detailed record of the key points of this meeting, and BlockBeats translated the original text as follows:

On January 4th, 2024, Ethereum developers gathered on Zoom for the All Core Developers Execution (ACDE) call #178 meeting. The ACDC conference is a bi-weekly series of meetings typically hosted by Tim Beiko, the protocol support manager at the Ethereum Foundation, where developers discuss and coordinate changes to the Ethereum execution layer (EL). This week, the call was hosted by a Geth EL developer using the pseudonym "Lightclient". Developers confirmed the activation dates for the next three public testnets for the Cancun/Deneb (Dencun) upgrade and discussed the code change priorities for the Prague/Electra hard fork upgrade that will follow Dencun. These changes are typically referred to as Ethereum Improvement Proposals (EIPs). This meeting is one of a series of meetings where developers discuss and coordinate changes to the Ethereum execution layer (EL).

Dencun Update

During the holiday period, Dencun did not undergo any specific updates. Since the last ACD conference call on December 21st, the client team has been preparing a new version for the Goerli testnet. Due to previous delays in upgrade testing caused by Prysm, Geth developer Marius van der Wijden requested an update from the Prysm client team regarding their progress on cutting a new version. Prysm developer Terence Tsao confirmed that the Prysm team will prepare a new version for the Goerli hard fork next week. However, the Goerli version will be a "pre-release", meaning that this is not the version recommended by Prysm for use on the Ethereum mainnet. After the Goerli hard fork, the Prysm team plans to release another version with certain changes and updates that will be recommended for users to run on the mainnet and test on the Sepolia and/or Holesky testnets. The client team has been preparing a new version for the Goerli testnet.

Despite Tsao's satisfaction with the activation date of the Goerli hard fork discussed on ACDE #177 on January 17th, the Prysm team suggests determining the activation date of the Sepolia and Holesky hard forks after the Goerli hard fork. Since ACDE #177, Tim Beiko, the protocol support lead at the Ethereum Foundation, has proposed the fork times for all three Ethereum public testnets (Goerli, Sepolia, and Holesky). The proposed fork activation times are as follows:

· Goerli - January 17, 2024 - Epoch 231680 - Timestamp 1705473120

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

· Holesky - February 7th, 2024 - Era 29696 - Timestamp 1707305664

Lightclient inquiry, whether the client teams other than Prysm are satisfied with the proposed Goerli hard fork activation time by Beiko. All client teams on the conference call, including Geth, Lodestar, Lighthouse, Teku, and Besu, confirmed that the time looks good for them, and they will be ready to release for Goerli node operators no later than next week. The Lighthouse client team pointed out that, like Prysm, their release may be a pre-release due to ongoing testing of certain network features on their client.

Dencun Timeline Disagreement

Next, Lightclient opened up a discussion to everyone about the activation time proposed for the Sepolia and Holesky testnets. A Prysm developer, who goes by the pseudonym "Potuz," suggested not to confirm the dates for the last two testnets before the mainnet upgrade. "We should try not to confirm the dates now because the situation with Goerli may not be good, and rolling back is a problem. Adding a new version with the correct epoch but no changes is easy. Removing a version and fixing errors is a problem. This takes more than a few weeks," Potuz said.

Lightclient emphasizes that the client team does not need to release a new version within a week after the Goerli hard fork, so it may not be necessary to delete the version unless upgrade-related issues are discovered around January 24. Geth developer Marius van der Wijden said that since developers can change them at any time, he believes that setting a date on the Sepolia and Holesky testnets will not be a problem, even if Goerli encounters problems.

The DevOps engineer of the Ethereum Foundation, Barnabas Busa, wrote in a Zoom chat that in his opinion, it only makes sense to upgrade Sepolia and Holesky to the new version after confirming that the Goerli version is running normally. "Sean", a Lighthouse developer who agrees with this view, said that developers can set a "tentative" date for the Sepolia hard fork, but should decide whether to continue with the January 30th plan after confirming that the Goerli version is running normally.

Potuz suggested adding an extra week of testing time between the Goerli and Sepolia hard fork activations, essentially giving two weeks for analysis instead of three. He said the additional week of testing time would provide time for client releases to "soak" for a few days before the client teams need to cut a new version for the next testnet upgrade. "Two weeks is too tight. That's the issue I pointed out," Potuz said, adding that if the Goerli client version is thoroughly analyzed and tested, there may not be a need for three weeks of turnaround time between the Sepolia and Holesky hard fork activations.

Potuz's views have sparked controversy. Ansgar Dietrichs of the Ethereum Foundation stated that the "dead time" between the activation of the first public test network upgrade and the main network activation is usually not necessary for developers to extend. However, Dietrichs also pointed out that the desire to extend the time between test network upgrades is a more serious issue that developers should discuss in the context of the hard fork, not just in the Dencun upgrade. "If there is a desire to extend the process, then we may need to discuss it when we have time, rather than before the hard fork," Dietrichs said.

Lightclient agrees with Dietrich's point of view, stating that if the discussion had taken place earlier, for example in October, developers might have been more willing to extend the testing period of the Dencun testnet. "I think part of the reason is that we wanted to release this upgrade last fall, so now we're really working hard to make it happen, and I think we've set some more positive timelines," said Lightclient.

坚持积极的时间表

Positive Schedule to Stick to

According to the views shared by developers at the meeting, Parithosh Jayanthi, a DevOps engineer at the Ethereum Foundation, suggested delaying the Sepolia hard fork upgrade by about a week and setting a date for the Sepolia hard fork at the ACD meeting on January 25th, after the Goerli upgrade. Marius van der Wijden opposed relying solely on the ACD meeting to re-discuss the activation date of the test network upgrade. "I really don't want us to have to go to another All Core Devs to confirm the date," he said, adding, "I don't want to attend another All Core Devs meeting just to say, 'Okay, Sepolia can now proceed.' And then we have to wait two weeks to really proceed with Sepolia."

Attempting to appease all parties, Geth developer Guillaume Ballet suggested creating two tentative dates for the Sepolia hard fork, one to be used by developers if the result of the Goerli hard fork is positive, and another to be used if the result is negative. However, Lightclient and Dietrichs both opposed this idea, as the nature of the errors and issues on Goerli must be evaluated before developers can actually set a new schedule for the Sepolia hard fork.

By the way, a pseudonymous developer from the Ethereum Foundation's testing team, with the screen name "Danceratopz", asked if the developer would like to wait and evaluate the expiration of the blob on the Goerli test network before upgrading to Sepolia. The background is that the expiration of the blob refers to the removal of blob data from the Ethereum state in about two weeks. For more information on blobs and proto-danksharding, please read this Galaxy Research report.

Lighthouse's Sean and Besu team's Justin Florentine both support evaluating the expiration of blobs on one of the three testnets before activating Dencun on the mainnet. Florentine emphasized that waiting for the expiration of blobs on the testnet will also help Layer-2 scroll protocol teams and application developers prepare for the Dencun upgrade. Sean from Lighthouse stated that although 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 Layer-2 teams can experience the full lifecycle of blobs on Sepolia. Regarding Sean's suggestion, there was no clear consensus among other developers at the meeting.

On the contrary, Lightclient asked developers in a phone call if they were willing to stick to Beiko's proposed schedule, which is to upgrade Sepolia on January 30th and then upgrade Holesky one week later on February 7th. As there were no more obvious objections from the developers, Lightclient stated that they would stick to the original schedule. Potuz wrote in the Zoom chat that he preferred to upgrade Sepolia and Holesky testnets at once on February 7th instead of upgrading the former one week in advance. In a Discord message after the phone call, Lightclient confirmed once again that the schedule for the Dencun testnet will remain unchanged.

Prague/Electra

Next, developers discussed which EIPs should be prioritized in the next upgrade after Dencun, Prague/Electra. Marius van der Wijden suggested that developers should focus on delivering the Verkle tree upgrade in Prague/Electra, rather than other EIPs. He raised two points in support of this view, the first being the readiness of Verkle. As discussed in ACDE #177, developers plan to hold a dedicated ACDE conference call to delve into the implementation details of Verkle and whether it is ready for a hard fork upgrade.

The second point mentioned by van der Wijden is the decoupling ability to upgrade in the Execution Layer (EL) and the Consensus Layer (CL). Van der Wijden mentioned that there may be some "high-priority, very urgent" EIPs in the Consensus Layer that may need to be implemented faster than the Verkle upgrade on the EL. He said: "I think the people in the Consensus Layer are discussing whether it makes sense to hard fork them, whether it can be done without the participation of the Execution Layer, or whether the participation of the Execution Layer is needed. In any case, we need to have a joint hard fork, so I agree to a smaller hard fork. Therefore, Verkle is definitely the high priority, and we should push it based on these two points."

Ethereum Foundation researcher Ansgar Dietrichs wrote in a Zoom chat that he "strongly opposes" focusing on Verkle in the Prague/Electra upgrade, as this could mean that the upgrade will be delayed until 2025 due to the complexity of the code changes required by Verkle. Lukasz Rozmej, a developer of the Nethermind client, also agrees with Dietrichs' view. "My experience tells me that state redesign is very difficult and takes a very long time," Rozmej said, adding, "Although I think Verkle is great and it is making great progress, I think if we only focus on Verkle, it will take at least a year to do the next hard fork, or even longer. Therefore, my suggestion is to focus on some smaller hard forks, and each team will commit to Verkle and allocate appropriate resources, workforce, intelligence, or whatever you want to call it, for this topic."

Focus on Verkle

Developers have different opinions on whether Prague/Electra should focus on Verkle or prioritize smaller code changes that can be released faster than Verkle. Ballet emphasizes that there is no such thing as a "small fork", and the longer developers wait before implementing Verkle, the more difficult it will be to implement Ethereum state updates. Similarly, Tomasz K. Stańczak, a developer for the Nethermind client, suggests taking an ambitious approach and promises to include more EIPs in Prague/Electra than may actually be possible. "We need to use the team's capabilities and we must show that we can handle the biggest challenges of the year. If by March, Verkle shows more and more difficulties to the team, then maybe people will question and say, 'Okay, let's give up Verkle.' But then we will have a pretty good set of other EIPs that we will include," Stańczak said, specifically pointing out other important EIPs that can be included in Prague/Electra, such as those related to staking, re-staking, and account abstraction.

Regarding Stańczak's response, Lightclient stated that after committing to a set of EIPs, it may be difficult for developers to continue discussing which EIPs should be included in Prague/Electra, one of which is Verkle, which is "an 18 to 24 month project." Andrew Ashikhmin, the developer of the Erigon client, supports the release of smaller EIPs in the Prague/Electra fork and parallel work on Verkle in future forks. Ballet supports Stańczak's proposal to focus on Verkle in Prague/Electra and remove it from the upgrade when significant issues that require more time to resolve are discovered during its implementation.

Specializing in Upgrades for CL Only

Regarding the topic of decoupling EL and CL upgrades, Potuz mentioned that Prague/Electra only proposed one EIP, which only requires changes to CL. "The only change that is purely CL is the removal of the attestation index committee. And all other changes, even those that seem to be only CL changes, such as Max EB, depend on other changes from EL. So, I don't think a pure CL fork will happen. At least, I don't see it happening this year or next. We don't have enough pure CL proposals," said Potuz.

Developers quickly delved into EIPs that had not yet been discussed on the Prague/Electra Meta Thread, including but not limited to the following EIPs:

· EIP-7377: Migration Transaction

· EIP-6465: SSZ Withdrawal Root 4

· EIP-6466: SSZ Receipt Root 4