The meeting also discussed the priority of code changes in the next hard fork upgrade Prague/Electra after Dencun.

Author: Christine Kim, Vice President of Galaxy Research

Translator: Qin Jin, Carbon Value

On January 4, 2024, Ethereum developers gathered on Zoom for All Core Developers Execution (ACDE) Call #178. The ACDE call is typically hosted by Tim Beiko, the protocol lead of the Ethereum Foundation, and is a bi-weekly series of meetings for developers to discuss and coordinate changes to the Ethereum execution layer (EL). This week's meeting was chaired by an anonymous Geth EL developer with the pseudonym "Lightclient." The developers once again confirmed the activation dates for the next three public testnets after the Cancun/Deneb (Dencun) upgrade. They also discussed the priority of code changes (EIPs) for the Prague/Electra hard fork upgrade following Dencun.

Dencun Update

There were no specific updates on the Dencun upgrade during the holiday period. Since the last ACDE call on December 21, the client teams have been preparing a new version for the Goerli testnet. Due to the previous delay in upgrade testing caused by Prysm, Geth developer Marius van der Wijden requested the Prysm client team to provide the latest progress on their new version. Prysm developer Terence Tsao confirmed that the Prysm team will be ready with a new version for the Goerli hard fork next week. However, the version for Goerli will be a "pre-release" version, meaning it will not be the recommended Prysm version for use on the Ethereum mainnet. Following the Goerli hard fork, the Prysm team plans to release another version with certain changes and updates recommended for running on the mainnet and testing on the Sepolia or Holesky testnets.

While Tsao expressed satisfaction with the Goerli hard fork activation date of January 17, as 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 protocol support lead of the Ethereum Foundation, has proposed public testnet fork times for the 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 -- Epoch 132608-- Timestamp 1706655072
• Holesky--February 7, 2024 -- Epoch 29696—Timestamp 1707305664

Lightclient inquired whether other client teams outside of Prysm agreed with Beiko's proposed Goerli hard fork activation time. All client teams participating in the call (including Geth, Lodestar, Lighthouse, Teku, and Besu) confirmed that they believed the timing was right and that they could release versions for Goerli nodes by next week at the latest. The Lighthouse client team noted that, as they are still testing certain network features of their client, the version they release may be a pre-release version similar to Prysm's.

Dencun Timeline Divergence

Subsequently, Lightclient initiated a discussion on the proposed activation times for the Sepolia and Holesky testnets. A Prysm developer with the pseudonym "Potuz" suggested deferring the determination of the upgrade dates for the final two testnets before the mainnet. "We should try not to commit to dates right now as Goerli might not go smoothly, and returning from there is a problem. Adding a new version with the correct epoch without any changes is easy. Removing a version and fixing mistakes is a problem. This takes much longer than a few weeks," Potuz stated.

Lightclient emphasized that the client teams would only need to release a new version for the Sepolia and Holesky testnets one week after the Goerli hard fork, so it might not be necessary to remove the new version unless upgrade issues are discovered on Goerli on or after January 24. Geth developer Marius van der Wijden expressed his belief that setting dates for the Sepolia and Holesky testnets would not be harmful, as developers could change the dates at any time if issues arose on Goerli.

Barnabas Busa, a DevOps engineer at the Ethereum Foundation, wrote in the Zoom chat room that, in his view, it would only be necessary to release a new version for Sepolia and Holesky upgrades after confirming that the Goerli version is running normally. A Lighthouse developer with the pseudonym "Sean" agreed, stating that developers could set a "tentative" date for the Sepolia hard fork but should first assess the progress on Goerli before January 30.

Potuz suggested adding an additional week of testing time between the Goerli and Sepolia hard fork activations, essentially allowing for two weeks of analysis instead of three. He stated that adding a week of testing time would allow the client release to "soak" for a few days, and then the client teams would only need to cut a new version for the next testnet upgrade. "Two weeks is too close. That's the issue I want to point out," Potuz added, suggesting that if the Goerli client release undergoes thorough analysis and testing, there might not be a need for a three-week turnaround between the activations of Sepolia and Holesky.

Potuz's viewpoint sparked controversy. Ansgar Dietrichs from the Ethereum Foundation referred to the time between the activation of the first public testnet upgrade and the mainnet upgrade as the developers' "deadline" and stated that it did not need to be extended. However, Dietrichs also pointed out that the desire to extend the interval between testnet upgrades should be discussed more seriously in the context of hard forks, not just for the Dencun upgrade. Dietrichs said, "If someone wishes for a longer process, we should discuss this when we have time, not just before the hard fork."

Lightclient agreed with Dietrichs' viewpoint, stating that if the discussion had taken place as early as October, developers might have been more accommodating to extending the testing timeline for Dencun. Lightclient said, "I think part of the reason is that we wanted to finish the upgrade in the fall of last year, so now we are really working hard to achieve this goal, and I think our schedule should be more proactive."

Adhering to a Proactive Schedule

According to the developers' discussions during the conference call, Parithosh Jayanthi, a DevOps engineer at the Ethereum Foundation, suggested postponing the Sepolia hard fork upgrade by about a week and setting the date for the Sepolia hard fork after the Goerli upgrade to January 25th during the ACDE conference call. Marius van der Wijden opposed relying solely on ACDE calls to reconsider the activation dates for testnet upgrades. He said, "What I really want to avoid is having to have another All Core Devs call to confirm the date," adding, "I hate having another All Core Devs call just to say 'okay, Sepolia can start now.' And now we have to wait two weeks to actually start implementing Sepolia."

To appease all parties, Geth developer Guillaume Ballet suggested creating two tentative dates for the Sepolia hard fork. If the results of the Goerli hard fork are positive, developers can stick to one set of dates; if the results are negative, developers can use the other set of dates. However, both Lightclient and Dietrichs opposed this idea, stating that an assessment of errors and issues on Goerli must be made before developers set a new timeline for the Sepolia hard fork.

Incidentally, a developer with the pseudonym "Danceratopz" from the Ethereum Foundation testing team asked whether developers would prefer to wait for an assessment of the blob expiration issue on the Goerli test network before upgrading Sepolia. As background knowledge, 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 agreed to assess the blob expiration on one of the three testnets before activating Dencun on the mainnet. Florentine emphasized that waiting for blob expiration on the testnet would also benefit the second-layer Rollup protocol team and application developers in preparing for the Dencun upgrade. Sean stated that while observing blob expiration on Goerli might not be necessary, it could be a reason to extend the testing period between Sepolia and Holesky, allowing developers and the second-layer team to experience the entire blob lifecycle on Sepolia. Other developers on the call did not explicitly agree with Sean's suggestion.

In contrast, during the conference call, Lightclient asked the developers if they were willing to adhere to Beiko's proposed schedule, which is to upgrade Sepolia on January 30 and Holesky one week later on February 7. As there were no further objections from the developers, Lightclient stated that the developers would stick to the original schedule. In a Zoom chat, Potuz expressed a desire 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 confirmed that the testnet schedule for Dencun would remain unchanged for the time being.

Prague/Electra

Next, the developers discussed which EIPs should be prioritized for the Prague/Electra upgrade after Dencun. Marius van der Wijden suggested that the developers should focus on completing the Merkle tree upgrade for Prague/Electra rather than other EIPs. He supplemented this viewpoint with two points of consideration, the first being the readiness of the Merkle tree. As discussed in ACDE #177, developers are planning to hold a dedicated ACDE conference call to delve into the implementation details of the Merkle tree and the readiness for its hard fork upgrade.

The second point mentioned by van der Wijden was the ability to decouple upgrades on the execution layer (EL) from the consensus layer (CL). He noted 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 for the consensus layer folks to discuss whether they need to hard fork these [urgent] changes, whether they can be done without EL involvement, or whether they need EL involvement, and we need to do a joint hard fork anyway, and then I can accept a smaller hard fork," van der Wijden said. "So, the Merkle tree is absolutely paramount, and we should push it in consideration of these two points."

Ansgar Dietrichs, a researcher at the Ethereum Foundation, wrote in the Zoom chat that he "strongly opposes" focusing the Prague/Electra upgrade on the Merkle tree, as the complexity of the code changes required for the Merkle tree likely means the upgrade would be delayed until 2025. Lukasz Rozmej, a developer from the Nethermind client, also agreed with Dietrichs. Rozmej stated, "My experience tells me that redesigning the state is very difficult and takes a very long time," adding, "While I think the Merkle tree is great and making great progress, I think if we focus only on the Merkle, the next hard fork will take at least a year, if not longer. Therefore, my suggestion is to possibly focus on some smaller hard forks, while each team is dedicated to the Merkle and allocates appropriate resources, workloads, brainpower, call it what you will."

Focusing on the Merkle

There were differing opinions among the developers on whether Prague/Electra should focus on the Merkle or prioritize smaller code changes for faster release. Ballet emphasized that, in his view, "there are no small forks," and the longer developers wait before implementing the Merkle, the more difficult it becomes to implement Ethereum state updates. Tomasz K. Stańczak, also a developer from the Nethermind client, suggested taking an ambitious approach, committing to adopting more EIPs than Prague/Electra might include. "[Let's] leverage the capabilities of the team, and we have to prove that we can handle the biggest challenges in this year. If the Merkle eventually shows the team that more and more difficulties are piling up by March, then people might ask questions again and say 'okay, Merkle is off.' But we will continue with a pretty decent set of other EIPs that we will include," Stańczak said, specifying other important EIPs that Prague/Electra might include, such as those related to staking, restaking, and account abstraction.

In response to Stańczak's proposal, Lightclient stated that it might be difficult to continue discussing which EIPs should be included in Prague/Electra after committing to a set of EIPs, one of which (referring to the Merkle) is "a project that will take 18 to 24 months." Andrew Ashikhmin, a developer from the Erigon client, agreed to release smaller EIPs in Prague/Electra and simultaneously develop the Merkle for use in a later hard fork. Ballet supported Stańczak's suggestion, which is to focus on developing the Merkle in Prague/Electra and, if significant issues are found during its implementation, to remove it from the upgrade.

Focusing on CL Upgrades

Regarding the issue of decoupling EL (Execution Layer) and CL (Consensus Layer) upgrades, Potuz mentioned that there is only one EIP proposal for Prague/Electra that requires changes only to the CL. "The only change is the removal of the Authentication Index Committee… and all other changes, even those that seem to only involve the CL, such as Max EB, depend on other changes in the EL. So, I don't think a pure CL fork is going to happen. At least, I don't think this year, nor next year. We don't have enough pure CL proposals," Potuz said.

However, Ansgar Dietrichs still mentioned that some EIPs are primarily focused on CL-centric upgrades and only require minor changes to the EL, making it easy for EL client teams to execute. These EIPs still require coordination between EL and CL for the hard fork. Dietrichs then added that, in his view, Data Availability Sampling (DAS) is the most important code change after EIP 4844 from the CL perspective. There was some disagreement between Dietrichs and Lightclient regarding whether DAS needs a hard fork to be implemented.

Focus on EOF and Other EIPs

A developer with the pseudonym "Rodiazet" working in the Ethereum Foundation's Ipsilon team, which focuses on Ethereum Virtual Machine (EVM) research, brought up the background that EOF stands for EVM Object Format, which is a series of improvements to the EVM originally considered for inclusion in the Cancun/Deneb upgrade.

In addition to the Merkle, developers also proposed several other EIPs for consideration, such as EIP 5920 (PAY opcode) and EIP 2537 (Precompile for BLS12-381 curve operations). The complete list of candidate EIPs for Prague/Electra can be found in the upgrade meta-thread on the Ethereum Magicians website. While most developers agreed to prioritize the Merkle to some extent after the Cancun/Deneb meeting, it is still unclear to what extent the Merkle should be prioritized for Prague/Electra over smaller EIPs that could be implemented faster and easier in 2024. Lightclient emphasized that developers do not need to make a final decision on the content of Prague/Electra in this week's conference call. He suggested continuing the discussion on this topic in the upcoming ACDE conference call.

Subsequently, the developers quickly discussed EIPs in the Prague/Electra theme that had not been discussed in the call, including but not limited to the following EIPs:

• EIP-7002: EL-triggered exits
• EIP-7549: Moving the committee index out of authentication
• EIP-3074: AUTH and AUTHCALL opcodes
• EIP-6110: On-chain validator deposit
• EIP-6913: SETCODE instruction
• EIP-7377: Migration transactions
• EIP-4444: Binding historical data in the execution client
• EIP-6404: SSZ transaction root
• EIP-6465: SSZ extraction root
• EIP-6466: SSZ receipt root
• EIP-7212: Precompile for secp256r1 curve support

For a detailed overview of the opinions on the above EIPs, please refer to the complete call recording posted on YouTube.

Formalizing EIP 7587

Finally, Ethereum Foundation researcher Carl Beekhuizen revisited the discussion about EIP 7587, which preserves a set of precompile addresses for use by second-layer protocols. Beekhuizen inquired how to best formalize EIP 7587 to make it an informational EIP and create a specification for future Ethereum governance processes. Nethermind developer Ahmad Bitar suggested incorporating the EIP into the EIP 1 document, which outlines the guidelines for the EIP process. Lightclient proposed further discussion on this topic on the Ethereum Magicians website and reconsidering the topic as needed in the next ACDE conference call.

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