Summary of the latest meeting of Ethereum core developers: Testnet Cancun upgrade time confirmed again.

Title: "Ethereum All Core Developers Execution Call #178 Writeup"

Author: Christine Kim

Translator: Luccy, BlockBeats

Editor's Note:

The Ethereum All Core Developers Execution (ACDE) consensus call is held every two weeks to mainly discuss and coordinate changes to the Ethereum execution layer (EL). This 178th ACDE call meeting reaffirmed the KanKun upgrade time on the Goerli test network as January 17, and designated January 30 and February 7 as the upgrade dates for the Sepolia and Holesky test networks, respectively. If everything goes smoothly, developers will release the Goerli client next week, and if any issues arise within the first 24 hours after the fork, the upgrade time will be rescheduled.

In addition, the meeting discussed the activation date of the Cancun/Deneb (Dencun) upgrade on the public test network 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, detailed the key points of the meeting, and BlockBeats has translated the original article as follows:

On January 4, 2024, Ethereum developers gathered on Zoom for the All Core Developers Execution (ACDE) call #178 meeting. The ACDC call is a bi-weekly series of meetings, typically hosted by Tim Beiko, the Ethereum Foundation's protocol support manager, 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 alias "Lightclient." Developers confirmed the next three public test network activation dates for the Cancun/Deneb (Dencun) upgrade and discussed the code change priorities for the next hard fork upgrade, Prague/Electra, which are typically referred to as Ethereum Improvement Proposals (EIPs). This meeting is one of the series of meetings where developers discuss and coordinate changes to the Ethereum execution layer (EL).

Dencun Update

During the holiday period, there were no specific updates for the Dencun upgrade. Since the last ACDC call on December 21, client teams have been preparing a new version for the Goerli test network. Due to previous delays in upgrade testing caused by Prysm, Geth developer Marius van der Wijden requested an update from the Prysm client team on their progress in 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 it is not the version 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 will be recommended for running on the mainnet and testing on the Sepolia and/or Holesky test networks. Client teams have been preparing a new version for the Goerli test network.

Although Tsao indicated that the Prysm team is satisfied with the proposed January 17 activation date for the Goerli hard fork discussed in ACDE #177, he suggested determining the activation dates for the Sepolia and Holesky hard forks after the Goerli hard fork. Since ACDE #177, Tim Beiko, the Ethereum Foundation's protocol support manager, has proposed the fork times for all three Ethereum public test networks (Goerli, Sepolia, and Holesky). The proposed 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 inquired whether client teams other than Prysm were satisfied with the proposed Goerli hard fork activation time. All client teams on the call, including Geth, Lodestar, Lighthouse, Teku, and Besu, confirmed that the time seemed suitable for them, and they will be ready to release for Goerli node operators by next week at the latest. The Lighthouse client team noted that, like Prysm, their release might be a pre-release due to ongoing testing of certain network features on their client.

Dencun Schedule Discrepancy

Next, Lightclient opened the discussion on the proposed activation times for the Sepolia and Holesky test networks. A Prysm developer using the alias "Potuz" suggested not finalizing the dates for the last two test networks before the mainnet upgrade. "We should try not to set the dates now as it might be the case that Goerli is not doing well, and a retreat is an issue. Adding a new version with the correct epoch but no changes is easy. Removing a version and fixing mistakes is a problem. It takes more than a few weeks," Potuz said.

Lightclient emphasized that client teams do not need to release a new version within a week after the Goerli hard fork, so it may not be necessary to remove versions unless issues related to the upgrade are discovered around January 24. Geth developer Marius van der Wijden stated that, given that developers can change them at any time, he believes setting dates for the Sepolia and Holesky test networks will not be an issue, even if Goerli encounters problems.

In the Zoom chat, Ethereum Foundation DevOps engineer Barnabas Busa wrote that, in his view, it only makes sense to cut new versions for the Sepolia and Holesky upgrades after confirming that the Goerli version is running smoothly. Lighthouse developer using the alias "Sean," who agreed with this view, suggested setting a "tentative" date for the Sepolia hard fork but deciding whether to proceed with the January 30 plan after confirming the normal operation of the Goerli version.

Potuz proposed adding an extra week of testing time between the Goerli and Sepolia hard fork activations, essentially two weeks of analysis time instead of three. "Two weeks are too tight. This is the issue I pointed out," Potuz said, adding that if the Goerli client version has been thoroughly analyzed and tested, there may not be a need for a three-week turnaround between the Sepolia and Holesky hard fork activations.

Potuz's viewpoint sparked controversy. Ansgar Dietrichs from the Ethereum Foundation stated that the time between the activation of the first public test network upgrade and the mainnet activation is typically a "dead time" that developers do not need to extend. However, Dietrichs also pointed out that the desire to extend the time between test network upgrades is an issue that developers should discuss more seriously in the overall context of the hard fork, not just in the Dencun upgrade. "If there is a desire to extend the process, then we should probably have the discussion when there is time, not just before the hard fork," Dietrichs said.

Lightclient agreed with Dietrichs, stating that if the discussion had taken place, for example, earlier in October, developers might have been more willing to extend the time for the Dencun test network. "I think part of the reason is that we wanted to release this upgrade in the fall of last year, so now we're really trying to make it happen, and I think we've set some more positive timelines," Lightclient said.

Sticking to Positive Timelines

Based on the viewpoints shared by developers in the meeting, Parithosh Jayanthi, 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 25, after the Goerli upgrade. Marius van der Wijden opposed relying solely on the ACD meeting to reconsider the activation date for the test network upgrades. "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 is good to go now,' and then we have to wait two weeks to actually do Sepolia."

Attempting to appease all parties, Geth developer Guillaume Ballet suggested creating two sets of tentative dates for the Sepolia hard fork, one to be used by developers if the results of the Goerli hard fork are positive, and the other to be used if the results are negative. However, both Lightclient and Dietrichs opposed this idea, as an assessment of the nature of errors and issues on Goerli must be made before developers can actually set a new timeline for the Sepolia hard fork.

Incidentally, a developer using the alias "Danceratopz" from the Ethereum Foundation testing team asked if developers would like to wait to evaluate blob expiry on the Goerli test network before upgrading Sepolia. The background is that blob expiry refers to the removal of blob data from the Ethereum state after approximately two weeks. For more information about blobs and proto-danksharding, please refer to this Galaxy Research report.

Sean from Lighthouse and Justin Florentine from the Besu team both supported evaluating blob expiry on one of the three test networks before activating Dencun on the mainnet. Florentine emphasized that waiting for blob expiry on the test network would also help Layer-2 rollup protocol teams and application developers prepare for the Dencun upgrade. Sean stated that while observing blob expiry on Goerli is not necessary, it could be a reason to extend the testing period between Sepolia and Holesky, so that developers and Layer-2 teams can experience the full blob lifecycle on Sepolia. There was no clear consensus among other developers at the meeting regarding Sean's suggestion.

In contrast, Lightclient asked developers during the call if they were willing to stick to the timeline proposed by Beiko, which is to upgrade Sepolia on January 30 and then upgrade Holesky a week later on February 7. As developers did not express any more apparent objections, Lightclient stated that developers will stick to the original timeline. Potuz wrote in the Zoom chat that he would prefer to upgrade both Sepolia and Holesky test networks on February 7, rather than a week earlier. In a Discord message after the call, Lightclient confirmed that the timeline for the Dencun test network will remain unchanged.

Prague/Electra

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

The second point van der Wijden mentioned is the decoupling capability of upgrades on the execution layer (EL) and consensus layer (CL). He noted that there are 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 discussing whether it makes sense to hard fork them, and whether it can be done without the execution layer, or whether it needs the execution layer, we still need to do a joint hard fork, so I agree to do a smaller hard fork. So, high priority is definitely Verkle, and we should push it based on these two points."

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

Focusing on Verkle

Developers are divided on whether Prague/Electra should focus on Verkle or prioritize smaller code changes that can be released faster than Verkle. Ballet emphasized that in his view, there is no such thing as a "small fork," and the longer developers wait to implement Verkle, the more difficult it becomes to implement Ethereum state updates. Similarly, Tomasz K. Stańczak, a developer from the Nethermind client, suggested taking an ambitious approach, committing to include more EIPs in Prague/Electra than may actually be feasible. "Leverage the team's capabilities, and we have to show that we handle the biggest challenges in a year. If by March, Verkle shows more and more difficulties to the team, then maybe people will question again and say, 'Okay, let's drop Verkle.' But then we will have a pretty decent set of other EIPs that we will include," Stańczak said, specifically pointing out some important EIPs that could be included in Prague/Electra, such as those related to staking, restaking, and account abstraction.

In response to Stańczak, 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, with one of them, Verkle, being "an 18 to 24-month project." Andrew Ashikhmin, a developer from the Erigon client, supported releasing smaller EIPs in Prague/Electra and working on Verkle in parallel in future forks. Ballet supported Stańczak's proposal to focus Prague/Electra on Verkle and remove it from the upgrade if significant issues requiring more time to resolve are discovered during its implementation.

Focusing Solely on CL Upgrades

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

However, Ansgar Dietrichs stated that there are some EIPs primarily focused on CL that require minor changes to EL, which can be easily implemented by EL client teams. These EIPs still require a coordinated hard fork between EL and CL. Dietrichs then added that from the CL perspective, Data Availability Sampling (DAS) is the most important code change to be released after EIP 4844. There is some disagreement between Dietrichs and Lightclient on whether DAS needs a hard fork to be implemented.

Focus on EOF and Other EIPs

An anonymous developer named "Rodiazet" working at the Ethereum Foundation's Ipsilon team, which focuses on Ethereum Virtual Machine (EVM) research, advocated for the implementation of EOF in Prague/Electra. As background, EOF (EVM Object Format) is a series of improvements to the EVM, initially considered for inclusion in the Cancun/Deneb upgrade. See the previous ACDE#158 for more information about EOF.

In addition to Verkle, developers proposed several other EIPs worth considering, such as EIP 5920 (PAY opcode) and EIP 2537 (precompile for BLS12-381 curve operations). The candidate list of EIPs for Prague/Electra can be found in the upgrade meta-thread on the Ethereum Magicians website. While most developers support prioritizing Verkle in some way after Cancun/Deneb, it is currently unclear to what extent Verkle should be prioritized in Prague/Electra over smaller EIPs that could be implemented faster and more easily in 2024. Lightclient emphasized that developers do not need to make final decisions about the content of Prague/Electra in this week's call. He suggested continuing the discussion on this topic in the upcoming ACD call.

Developers quickly delved into EIPs not discussed in the call but listed on the Prague/Electra Meta Thread, including but not limited to the following EIPs:

EIP-7002: Execution Layer Triggerable Exits
EIP-7549: Move Committee Indexing Out of Attestation
EIP-3074: AUTH and AUTHCALL opcodes
EIP-6110: On-chain Validator Deposits
EIP-6913: SETCODE instruction
EIP-7377: Migration Transactions
EIP-4444: Binding Historical Data in Execution Clients
EIP-6404: SSZ Transaction Root 6
EIP-6465: SSZ Withdrawal Root 4
EIP-6466: SSZ Receipt Root 4
EIP-7212: Precompile for secp256r1 curve support

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

Formalizing EIP 7587

Finally, Ethereum Foundation researcher Carl Beekhuizen brought up the discussion about EIP 7587, which reserves a set of precompile addresses for Layer-2 protocols. See the previous call record for background on EIP 7587. Beekhuizen asked how best to formalize this EIP as an informational EIP and create a standard for future Ethereum governance processes. Ahmad Bitar, a developer from Nethermind, suggested including the EIP in the EIP 1 document, which outlines the guidelines for the EIP process. Lightclient suggested further discussing this topic on the Ethereum Magicians website and revisiting it in the next ACD call as needed.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。