Summary of the latest Ethereum core developer meeting: No changes to the Electra specification for now, creating a universal EL request

Original title: 《 Ethereum All Core Developers Consensus Call #132 Writeup》

Original author: Christine Kim

Original translation: Lucy, 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 132nd ACDC call, where developers shared the latest information on the first Pectra developer test network (Pectra Devnet 0), discussed open issues about the specification, and highlighted research projects related to network launch and data availability sampling. The issues involved include Electra open issues, unresolved issues related to Electra, and research open issues.

In terms of Electra open issues, developers focused on the impact of EIP 7251 and EIP 7549, as well as the proposal to add a new EIP that would create a general EL request. For outstanding issues related to Electra, discussions included changes to the validator committee index type, changes to validator deposit data processing, and more. Christine Kim, vice president of research at Galaxy Digital, took a detailed note of the highlights of this meeting, and BlockBeasts compiled the original text as follows:

On March 21, 2024, Ethereum developers gathered on Zoom for the All Core Developers Consensus (ACDC) call #132. The ACDC call is a series of meetings held every two weeks, and the weekly call is hosted by Ethereum Foundation researcher Alex Stokes, where developers discuss and coordinate changes to the Ethereum Consensus Layer (CL). This week, developers shared an update on their preparations for the first Pectra developer testnet, also known as Pectra Devnet 0. They discussed open issues regarding the Pectra Devnet 0 specification and briefly highlighted two unfinished research projects related to network launch and data availability sampling.

Electra Open Issues

Ethereum Foundation developers have published the initial CL specs and test vectors for Pectra Devnet 0. However, there are several outstanding issues regarding these specs that may or may not be resolved in time for the first devnet launch. Stokes highlighted that one of these issues is related to EIP 7251 (increase MAX_EFFECTIVE_BALANCE). Developers seem to be leaning towards making the merge of validator staked ETH an execution layer (EL) triggerable action. However, for now, merges are defined as CL actions in the initial Electra spec. “This is good because most of the processing logic required for the beacon chain is the same regardless of the source,” Stokes said.

Another outstanding issue that developers discussed on the call is related to EIP 7549 (move committee index outside of attestations). The EIP changes how validator attestations are aggregated and how blocks are formatted. When Pectra is activated, pre-upgrade proofs will be aggregated so that they are no longer compatible with new proofs submitted on-chain. Stokes highlighted two possible solutions in a GitHub issue ahead of the call. He wrote: · Clients broadcast both formats in the last Deneb epoch, taking care not to produce skewerable messages. · Extend blocks with extra fields for pre-Electra proofs, and allow only the Deneb style during the first epoch of Electra. · Deneb is the combined upgrade name for the latest hard fork activated on ethereum. Electra is the CL upgrade name for the next immediate hard fork on ethereum. · Developers discussed both options on the call. Ultimately, they decided not to change the Electra spec for now and instead see how these missing proofs affect network security on the devnet.

The third outstanding issue that developers discussed on the Electra-related call was the addition of a new EIP to the upgrade that would create a generic EL requests . The EIP proposed by Geth developer "Lightclient" would simplify the process of sending update messages from EL to CL. Due to the rise of smart contract-based staking solutions, there has been a large influx of EIPs activated on Ethereum, and it is proposed for Pectra to trigger various validator actions directly from EL instead of CL. Lightclient's proposal creates a general framework for propagating "contract-triggered requests" from EL to CL. Given that this EIP will change the way Pectra is designed, specifically the implementation of EIP 6110 and EIP 7002, Lightclient stressed that he wants feedback from the client team on his proposal as soon as possible. The developers agreed to try and finalize Lightclient's EIP by the end of this week, so that its specification can be built and shared by Monday, April 22.

The developers then discussed two other outstanding issues related to EIP 7549 and EIP 7251, raised by Teku developer Mikhail Kalinin. The first is about changes to validator committee index types , while the latter proposes changes to validator deposit data processing . Stokes encouraged developers to review both proposals in more detail for further discussion in the coming weeks.

Finally, the last outstanding issue related to the Electra specification discussed by developers was the blob count increase . Parithosh Jayanthi, developer operations engineer at the Ethereum Foundation, said he hopes to analyze blob activity after the Dencun upgrade and, based on this analysis, recommend a one-time increase in blob counts to be included in the Electra upgrade. Ethereum Foundation researcher Ansgar Dietrichs highlighted that he has also made a proposal to activate a gradual increase in blob count , which should be considered in parallel with Jayanthi’s proposal to include Electra.

Research Open Questions

During this week’s ACD call, developers briefly discussed two research projects. The first is a new research paper by Ethereum Foundation researcher Anders Elowsson, which proposes a new model for thinking about and implementing changes to Ethereum’s issuance policy. The full post can be read here . Stokes encouraged developers on the call to check out the post.

The second research project proposed by Lighthouse developer Adrian Manning is related to proof subnets. As Manning said on GitHub, “This PR introduces the concept of ‘network shards’, which is just an abstraction that labels node IDs with a number (network shard). We can then use this network shard (number) to assign topics that nodes must subscribe to for a long time.” Manning is seeking final comments on his proposal so that his team can start working on ethereum’s data availability sampling solution, PeerDAS. For information on data availability sampling, read this Galaxy Research report. Nethermind developer Lukasz Rozmej asks about the EIP 7547 (inclusion list) has been approved for inclusion in the Electra upgrade. The developer reiterated that EIP 7547 has not yet been approved for inclusion.

Saulius Grigaitis, a developer building an Ethereum CL client called "Grandine," raised questions about Ethereum's fork choice rules in light of the ongoing PeerDAS research. Grigaitis asked developers to include ideas in the PeerDAS working group.

「 Original link 」

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群： https://t.me/theblockbeats

Telegram 交流群： https://t.me/BlockBeats_App

Twitter 官方账号： https://twitter.com/BlockBeatsAsia