Original Title: "Ethereum All Core Developers Consensus Call #126 Writeup"

Author: Christine Kim

Translated by: Luccy, BlockBeats

Editor's Note:

The Ethereum All Core Developers Consensus Call (ACDC) is held every two weeks to discuss and coordinate changes to the Ethereum consensus layer (CL). This is the 125th ACDC call, which also covered discussions on changes to the Ethereum reward curve and prospects for other changes that may be introduced in the hard fork upgrade.

During the call, developers discussed topics related to the upcoming Ethereum Electra upgrade, including discussions on confirmed EIPs and some alternative EIPs that will be included in Electra. In addition, the meeting also discussed updates on the Deneb upgrade, including the activation plan for Deneb on the Sepolia and Holesky test networks. In the latter part of the meeting, developers also discussed the Prague upgrade after the Electra upgrade.

Christine Kim, Vice President of Research at Galaxy Digital, provided a detailed record of the key points of this meeting, which BlockBeats has translated as follows:

On January 23, 2024, Ethereum developers gathered on Zoom for the All Core Developers Consensus (ACDC) call #126 meeting. The ACDC conference call is a bi-weekly series of meetings hosted by Ethereum Foundation researcher Danny Ryan, where developers discuss and coordinate changes to the Ethereum consensus layer (CL). This week, developers discussed which code changes should be prioritized in the Electra upgrade.

Here are the Ethereum Improvement Proposals (EIPs) that have been confirmed to be included in the Electra upgrade:

· EIP 6110, on-chain supplier verification deposit· EIP 7002, execution layer triggers exit.

· EIP 7549, removing committee index from proofs

(Note: As per the instructions given, I have translated the Chinese text into English without considering the context or industry-specific terms. I have also retained the English words and phrases as they are, without translating them.)

Due to time constraints, developers have agreed to continue discussing EIP 7251 (increasing MAX_EFFECTIVE_BALANCE), EIP 7594 (peer data availability sampling), and EIPs related to SSZ at the next ACDC meeting. They also agreed not to prioritize EIP 6914 (reusing validator indices) and EIP 7547 (including lists) for the Electra upgrade, as they hope to keep the upgrade scope narrow and ideally implement it on the mainnet by the end of this year.

Deneb Upgrade Latest News

Danny Ryan briefly introduced the latest updates on the Deneb upgrade. On Wednesday, January 24, 2024, the Ethereum Foundation released a blog post detailing all the latest client releases for the Deneb upgrade on Sepolia and Holesky. These two test networks will be the last two testnets for the Deneb upgrade before it is activated on the Ethereum mainnet. Sepolia is scheduled to activate Deneb on January 30th, while Holesky will activate it one week later on February 7th.

Electra Discussion

The remaining time of the call was used to discuss the next upgrade candidate EIP, which was later named Prague/Electra after Deneb. Prague is the name of the Ethereum Execution Layer (EL) upgrade, while Electra is the name of the Consensus Layer (CL) upgrade. Last week, developers reviewed the Prague proposal, which mainly affects the EL protocol. This week, developers reviewed the Electra proposal, which mainly affects the CL protocol.

EIP 6110: On-chain Supplier Verification Deposit

Teku developer Mikhail Kalinin introduced EIP 6110, which proposes to append validators' deposits to EL blocks. The motivation for this code change is to reduce the complexity of client software design and improve the user experience for validators. Danny Ryan called this EIP a "major security improvement" for Ethereum. Tim Beiko, the protocol support manager and ACDC conference chair of the Ethereum Foundation, added that EIP 6110 is one of two CL-focused EIPs that the EL client team has expressed support for in the Prague/Electra upgrade. Like some other CL-focused EIPs proposed for Electra, EIP 6110 requires protocol-level changes to EL. Given the support of the CL and EL client teams for EIP 6110, developers agreed to include this code change in Prague/Electra.

EIP 6914: Reusing Validator Indices

EIP 6914 will allow the index number of a fully exited validator to be reassigned to a new incoming validator. The motivation behind this is to prevent unbounded growth of validator indices over time. The EIP was proposed by Lighthouse developer "Dapplion", who noted that while this code change is crucial for the long-term health of Ethereum, it does not need to be prioritized in Electra. Developers unanimously agreed not to prioritize EIP 6914 in Electra.

EIP 7002: Execution Layer Can Trigger Exits

Danny Ryan shared the background of EIP 7002. "There are two validator keys. There are active keys and withdrawal credentials. Active keys manage staking. Withdrawal credentials ultimately own the funds. Since phase zero, there may be a flaw in this relationship, where only active credentials can trigger an exit. Therefore, if the active key is lost, or if the relationship between having an active key and having withdrawal credentials is more dynamic, there may be quite dire situations and consequences." Ryan explained in detail that one of the main benefits of this EIP is to implement more trustless staking pool designs on Ethereum. As another EIP supported by the EL client team with a focus on CL, the CL client team is eager to include EIP 7002 in Electra. Like EIP 6110, 7002 will require minor changes to EL. Ryan pointed out that the implementation of this EIP is transitioning from a stateful precompile to EVM bytecode. He called on EVM bytecode experts to closely monitor the implementation and provide help with review after being drafted by Geth developers "Lightclient".

EIP 7251: Increase Maximum Effective Staking

Next, Mike Neuder, a researcher at the Ethereum Foundation, introduced EIP 7251, which proposes to increase the maximum effective stake of validators from 32 ETH to 2048 ETH. To understand the background of why this code change is necessary, please read the Galaxy Research Report on validator set size growth. Neuder pointed out that due to its complexity and dependencies on other code changes (such as EIP 7002), this proposal is "more controversial" than other proposals. Lighthouse developer Sean expressed support for the proposal, but suggested considering implementing these changes in multiple hard forks rather than upgrading all at once due to its complexity. Neuder supported this idea. Lodestar developer Gajinder Singh disagreed with splitting the implementation of EIP 7251 into multiple forks, fearing it would cause more trouble for developers in the long run.

One of the biggest complexities in EIP 7002 is the merge function for staking within the protocol, which will allow existing validator node operators to merge staking from multiple validators while minimizing loss of earnings. According to the design proposed by Neuder and colleagues, validator node operators will only lose rewards for a period of 256 epochs (approximately 27 hours). Neuder stated that he and his colleagues have consulted major staking service providers such as Lido, Coinbase, and Figment regarding the design of EIP 7002 and have received their support for this code change.

Terence Tsao, a developer representing the Prysm team, stated that they do not support the inclusion of EIP 7002 in Electra because the EL client team hopes to execute the Prague/Electra upgrade before the end of the year. Tsao said, "We believe that the complexity of this EIP is too great to accommodate the upcoming minor fork in October or November." For Prysm team's comprehensive view on which EIP should be included in Electra, please refer to this blog post. Prysm developer "Potuz" added that in his opinion, there is no "mini version" that can significantly reduce the complexity of EIP 7002 so that it can still be included in Electra. Regarding EIP 7002, Potuz said, "I don't understand how this can be implemented in any form in 2024."

However, Potuz also added that if developers are willing to extend the implementation scope of Electra to 2025, the Prysm team will provide upgraded priorities and push for many other code changes, including EIP 7002, as well as EIPs related to separating from the formal proposal generator and data availability sampling. He said: "We are very conservative because we know we have never forked twice in a year, especially in CL. If our scope is this year, it is unrealistic to try to include so many EIPs." Given the resistance encountered in including this code change in Electra, Ryan suggested continuing to discuss other proposed EIPs for Electra and discussing EIP 7002 again in another conference call.

EIP 7547: List Inclusion

EIP 7547 created a mechanism through which validators can force certain transactions to be included in a block. Its main motivation is to improve Ethereum's resistance to censorship. Neuder, who drafted the proposal along with several other developers, explained that 67% of block producers on Ethereum are already censoring transactions, and over 90% of validators are receiving blocks from third-party producers. There is a clear need to enhance censorship resistance on Ethereum. However, Neuder pointed out that there are some open design issues in the implementation of the mandatory transaction inclusion list, mainly related to the exact conditions that need to be met.

Tsao interjected that the Prysm team has been implementing EIP 7547 and has separated the formal proposal generator in the past few months. However, due to the complexity of EIP 7547, he does not believe that this code change is a suitable candidate for Electra. Sean and Potuz are both concerned about the complexity of EIP. Singh suggested that the client team switch to fully implementing the builder coverage flag feature, which is a mechanism that will cause validators to revert to local block production if audit activity is detected on EL. Builder coverage flag feature should be implemented comprehensively.

Due to developers' opposition to the changes made to this code, Ryan suggested not prioritizing it for the Electra upgrade. Potuz reiterated that if developers could change their expectations for the fork scope and mainnet activation time, the Prysm team would support including EIP 7547 in Electra.

EIP 7549: Removing Committee Index from Proofs

Next, Dapplion shared EIP 7549, which is a code change that only affects CL. This code change will make the aggregation of consensus votes more efficient and can be implemented in various ways, ranging from low to high complexity. Ethereum Foundation researcher Dankrad Feist supports the simplest way to implement EIP 7549, which is to simply set the value of the "index" field in "AttestationData" to zero in the CL client. Danny Ryan also supports this strategy. Developers agreed to incorporate EIP 7549 into Electra in the simplest form.

EIP 7594: Peer-to-Peer Data Availability Sampling (PeerDAS)

Ryan introduced EIP 7594, which is a proposal aimed at extending the target blob count of EIP 4844 beyond 3 blobs per block. The way developers are expanding Ethereum's data availability is by enabling nodes to sample blob data instead of downloading the entire blob. Although the design of EIP 7594 is not complex, its implementation at the network layer will require a significant amount of effort and testing from client teams. Tsao asked whether EIP will be combined with an increase in the target blob count, and if not, whether EIP will require consensus-level changes to be implemented. Ryan confirmed that in its current form, EIP 7594 does not require any consensus changes and can be implemented independently of hard fork upgrades. However, he noted that whether EIP 7594 should be paired with an increase in the blob count is an undecided issue, which will require consensus changes for updates.

· EIP-6465: SSZ Withdrawal Root

Change Equity Incentives

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