By Christine Kim

Compiled by: 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 about the first Pectra developer test network (Pectra Devnet 0), discussed open issues about specifications, and highlighted research projects related to network releases 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 will create a general EL request. For outstanding issues related to Electra, discussions included changes to the index type of the validator committee, changes to the processing of validator deposit data, etc. Christine Kim, vice president of research at Galaxy Digital, took detailed notes on the key points 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 bi-weekly series of meetings 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 Questions

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 the issues is related to EIP 7251 (increase MAX_EFFECTIVE_BALANCE). Developers seem to be leaning towards making the merge of validator staked ETH as 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," said Stokes.

Another outstanding issue that developers discussed on the call was related to EIP 7549 (Moving the committee index outside of attestations). The EIP changes how validator attestations are aggregated and how blocks are formatted. When Pectra is activated, attestations prior to the upgrade will no longer be compatible with new attestations submitted on-chain. Stokes highlighted two possible solutions in a GitHub issue before the call. He wrote:

  • Clients broadcast both formats in the last Deneb epoch, taking care not to produce slashable messages.

  • Extends blocks with extra fields for pre-Electra proofs, and allows only Deneb style during the first era of Electra.

Deneb is the combined upgrade name of the latest hard fork activated on Ethereum. Electra is the CL upgrade name of the next immediate hard fork on Ethereum.

Developers discussed both options on a conference call. Ultimately, they decided not to change the Electra specification for now, but to see how these missing proofs affect network security on the devnet.

The third outstanding issue discussed by developers on the Electra-related call was the addition of a new EIP to the upgrade that would create a generic EL request. 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, especially the implementation of EIP 6110 and EIP 7002, Lightclient emphasized that he hopes to get 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 concerns changes to the validator committee index type, while the latter proposes changes to the handling of validator deposit data. 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 increase in blob counts. Parithosh Jayanthi, developer operations engineer at the Ethereum Foundation, said that he hopes to analyze blob activity after the Dencun upgrade and, based on this analysis, recommend a one-time increase in blob counts for inclusion in the Electra upgrade. Ansgar Dietrichs, a researcher at the Ethereum Foundation, stressed that he also has a proposal to activate a gradual increase in blob counts, which should be considered in parallel with Jayanthi's proposal for inclusion in Electra.

Research open questions

During this week’s ACD call, developers briefly discussed two research projects. The first was 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 abstract concept 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 term.” Manning is seeking final comments on his proposal so that his team can start working on PeerDAS, Ethereum’s data availability sampling solution. For information on data availability sampling, read this Galaxy Research report.

Nethermind developer Lukasz Rozmej asked if EIP 7547 (inclusion list) has been approved for inclusion in the Electra upgrade. The developer reiterated that EIP 7547 has not been approved for inclusion.

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