Original Title: "Ethereum All Core Developers Execution Call #177 Writeup"

Author: Christine Kim

Translator: Sharon, 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 177th ACDE call, which preliminarily determined the fork times for Goerli, Sepolia, and Holesky, which are January 17th, January 31st, and February 7th, respectively.

In addition, developers discussed the precompiled address range for L2 and the Prague/Electra upgrade. They also decided to skip the ACD call next Thursday and reconvene ACDE #178 on January 4th. Christine Kim, Vice President of Research at Galaxy Digital, detailed the key points of this meeting, which BlockBeats has translated below:

On December 21, 2023, Ethereum developers participated in the 177th All Core Developers' Execution (ACDE) conference call via Zoom. Hosted by Tim Beiko, the Protocol Support Manager at the Ethereum Foundation, the ACDE conference call is a bi-weekly series of meetings where developers discuss and coordinate changes to the Ethereum Execution Layer (EL).

This week, developers have confirmed the tentative dates for activating the Cancun/Deneb upgrade on all three public Ethereum test networks. The schedule for the test network upgrades is as follows:

Goerli fork will take place on January 17th;

Sepolia fork will take place on January 31st;

Holesky fork will take place on February 7th.

Due to unexpected errors and client release issues, the above dates may change in the next few weeks, as the developers need to update. In addition, the developers discussed the performance of the second Goerli shadow fork, the precompiled address range of L2, and the expected upgrade of Prague/Electra. The developers agreed to cancel the All Core Developers' Call (ACDC) conference call scheduled for next Thursday, December 28th, and plan to hold a regular ACD meeting on Thursday, January 4th.

Goerli Testnet Fork

The DevOps team of the Ethereum Foundation launched the second shadow fork of the Goerli test network on December 19th. This shadow fork was activated by 290 nodes distributed in New York, Frankfurt, Bangalore, and Sydney, with each node running 100 validators. Almost all Ethereum clients, except for the Erigon client, were able to join the shadow fork and upgrade successfully.

The DevOps engineer of the foundation, Parithosh Jayanthi, stated that since the fork was initiated, the network participation rate has fluctuated between 99% and 100%, indicating that almost all validators on the Goerli testnet fork are able to connect to the network correctly.

He pointed out that due to the upgrade of Cancun/Deneb, the average bandwidth of nodes on the network has increased by about 200kbps. Nevertheless, during the blob spam and blob latency testing, there were no block reorganization events or significant block propagation delays on the network. However, Jayanthi also noted that block propagation events are emitted differently in different CL clients. Some CL clients will emit event logs for blocks before verification, while others will only emit events after verification.

To read a more detailed analysis of the Goerli Shadow Fork (GSF) #1, please refer to the article written by the Foundation DevOps team here.

Jayanthi said that the DevOps team plans to deprecate GSF#1 when it ends on Thursday, December 21. Gajinder Singh, a developer for Lodestar and EthereumJS clients, noted that he is still conducting additional testing on the shadow fork. Jayanthi agreed to verify with Singh to ensure that he can replicate these tests on Devnet#12 before GSF#1 is shut down.

Next Step

Based on the results of GSF#1, developers discussed the next steps for testing the Cancun/Deneb upgrade. Beiko asked the Prysm client team if they were willing to set a tentative fork date for the Goerli test network in January. James He, a developer for the Prysm client, stated that the team is still working on resolving some errors in their client and plans to review a tentative release date for the fixed version before January 8th.

Other client teams also tend to set the Goerli fork date in mid-January rather than at the end of January. Developers have tentatively agreed to activate the Cancun/Deneb upgrade on January 17th.

Beiko said that the client team needs to share the updated version of their software before January 8th or 9th, so that Goerli node operators have time to upgrade their devices if they decide to fork on January 17th. Beiko will also release a blog post during the week of January 8th on the Ethereum Foundation blog to announce the Goerli fork date, so that Goerli users are aware of the network-wide upgrade.

Ansgar Dietrichs asked developers whether target dates should still be set for the two additional Ethereum public test networks that will be upgraded before the Ethereum mainnet. After some discussion, the developers agreed to set a target upgrade date for the Sepolia test network within two weeks after Goerli, i.e. January 31; and for the Holesky test network one week later, i.e. February 7.

Developers plan to bundle a single client release and announcement post for Sepolia and Holesky testnet upgrades to shorten the turnaround time between the two Cancun/Deneb activations. In a Zoom chat, Dietrichs said, "I think in the past we usually had fewer testnets, so bundling releases seems like a good, practical choice."

Ethereum Foundation's DevOps engineer Barnabas Busa mentioned that upgrading the Holesky test network before the Sepolia test network upgrade may be more useful in capturing network-related errors as Holesky hosts more validators than the Sepolia test network. However, despite being smaller in scale, Sepolia hosts more users than Holesky.

Therefore, if upgraded before Holesky, the L2 team may have more time to test its operations. Developers agreed to upgrade Holesky before continuing to upgrade Sepolia and re-evaluate this order after the Goerli fork. Jayanthi said, "I think we will learn the most from Goerli because the validator set is small. There are many unique node settings, etc."

Precompiled Address Range

Next, developers discussed the precompiled address range of L2.

Precompile is an address on Ethereum, similar to a smart contract, that can execute complex cryptographic calculations that may be too expensive to execute directly through the Ethereum Virtual Machine (EVM). SHA3, RIPEMD160, and BLAKE2 are examples of precompiled hash functions supported on Ethereum.

Due to L2's desire to expand smart contract execution capabilities by adding new precompilation features, which may not yet exist on Ethereum, there is a question of whether L2 should use precompiled addresses that Ethereum may use in the future.

Dietrichs explained in his comment on GitHub that "in the future, many new EVM precompiles will first be introduced on (some or all) L2...and may or may not subsequently be introduced on L1. It is now very desirable to propose a precompile address scheme that ensures that for any given RIP precompile, the address is reserved on L1, meaning that no conflicting precompile has ever been introduced at that address, and if introduced on L1 in the same form, it is used for that RIP precompile."

RIP refers to the newly created "Rollup Improvement Proposal" process. The RIP process is a voluntary standard chosen by L2, aimed at standardizing and coordinating EVM-related changes. The first precompiled contract that L2 seeks to adopt in a standard way is the precompiled contract for secp256r1 elliptic curve signature verification. For more information on this proposal, please read the relevant RIP document.

Dietrichs stated during the conference call that L2 can allocate precompiled addresses in two ways.

First of all, the EVM changes launched on L2 can allocate numbers within the same precompiled address range as Ethereum, or use a range that is different from Ethereum's precompiled address range.

Ethereum Foundation researcher Danny Ryan supports the use of different address scopes for L2, as there is still a lot of uncertainty around the RIP process. He said: "I support adding a scope for L2, where if significant adoption occurs before EIP is adopted on L1, different orders and content selected from that scope can be used for L1, as it is still very unclear what will happen with RIP."

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia