Latest Ethereum Core Developers Meeting Summary: No Immediate Changes to Electra Specification, Create Universal EL Request
TechFlow Selected TechFlow Selected
Latest Ethereum Core Developers Meeting Summary: No Immediate Changes to Electra Specification, Create Universal EL Request
Electra is the name of the next immediate hard fork CL upgrade on Ethereum.
Navigating Web3 tides with focused insightsWritten by: Christine Kim
Translation: Luccy, BlockBeats
Editor's note: The All Core Developers Consensus (ACDC) call takes place every two weeks to discuss and coordinate changes to Ethereum’s consensus layer (CL). This was the 132nd ACDC meeting. During the session, developers shared updates on the first Pectra developer testnet (Pectra Devnet 0), discussed open specification issues, and highlighted ongoing research projects related to network propagation and data availability sampling. Topics included open Electra-related issues, unresolved matters tied to Electra, and open research topics.
Regarding open Electra issues, developers focused on the implications of EIP 7251 and EIP 7549, as well as a proposal for a new EIP that would introduce generalized EL requests. Discussions around pending Electra-related matters covered changes to validator committee indexing types and modifications to validator deposit data handling. Galaxy Digital Research Vice President Christine Kim provided a detailed summary of the meeting, which BlockBeats has translated below:
On March 21, 2024, Ethereum developers gathered on Zoom for All Core Developers Consensus (ACDC) Call #132. The ACDC calls are biweekly meetings hosted by Ethereum Foundation researcher Alex Stokes, where developers discuss and coordinate upgrades to Ethereum’s consensus layer (CL). This week, participants shared updates on preparations for the first Pectra developer testnet (also known as Pectra Devnet 0). They discussed open specification issues related to Pectra Devnet 0 and briefly highlighted two ongoing research initiatives concerning network propagation and data availability sampling.
Open Electra Issues
Ethereum Foundation developers have published the initial CL specifications and test vectors for Pectra Devnet 0. However, several unresolved questions remain regarding these specs—some may be resolved before the first devnet launch, while others might not. Stokes emphasized one such issue related to EIP 7251 (increasing MAX_EFFECTIVE_BALANCE). Developers appear inclined to treat validator ETH staking consolidation as an execution-layer (EL)-triggered operation. For now, however, consolidations are defined in the initial Electra spec as a consensus layer (CL) operation. "This is fine because most of the processing logic required on the beacon chain is largely the same regardless of origin," said Stokes.
Another unresolved issue discussed during the call concerned EIP 7549 (moving committee index outside attestation). This EIP alters how validator attestations are aggregated and how blocks are formatted. When Pectra activates, pre-upgrade attestations will no longer be compatible with newly submitted on-chain attestations. In a GitHub issue prior to the call, Stokes outlined two possible solutions:
-
Clients broadcast both formats during the last Deneb epoch, taking care not to produce slashable messages.
-
Extend pre-Electra blocks with additional fields and only allow Deneb-style attestations during Electra’s first epoch.
Deneb refers to the latest combined hard fork upgrade activated on Ethereum. Electra is the name of the next immediate hard fork CL upgrade for Ethereum.
Developers discussed both options during the call. Ultimately, they decided to hold off on modifying the Electra specification for now and instead observe how missing attestations impact network security on the devnet.
A third unresolved topic discussed during the call was adding a new EIP to the upgrade that would enable generic EL requests. Proposed by Geth developer "Lightclient," this EIP aims to streamline the process of sending update messages from the EL to the CL. With the rise of smart contract-based staking solutions, there has been a surge in EIPs proposing that various validator operations be triggered directly from the EL rather than the CL, particularly for Pectra. Lightclient’s proposal introduces a general framework for propagating “contract-triggered requests” from the EL to the CL. Given that this EIP could alter the design of Pectra—especially the implementation of EIP 6110 and EIP 7002—Lightclient stressed the need for client teams to provide feedback promptly. Developers agreed to try to finalize Lightclient’s EIP by the end of the week so its specification can be built and shared before Monday, April 22.
Next, developers discussed two additional open 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 second proposes modifications to how validator deposit data is processed. Stokes encouraged developers to review both proposals in greater detail ahead of further discussions in the coming weeks.
Finally, the last open issue related to the Electra specification discussed during the call was increasing the blob count. Parithosh Jayanthi, DevOps engineer at the Ethereum Foundation, expressed interest in analyzing blob activity post-Dencun upgrade and suggested a one-time increase in blob count to be included in the Electra upgrade based on those findings. Ansgar Dietrichs, Ethereum Foundation researcher, added that he had also proposed enabling a gradual increase in blob count, which should be considered alongside Jayanthi’s proposal for inclusion in Electra.
Open Research Issues
During this week’s ACDC call, developers briefly touched upon two research initiatives. The first is a new research article by Ethereum Foundation researcher Anders Elowsson, proposing a novel model for thinking about and implementing changes to Ethereum’s issuance policy. The full post can be read here. Stokes encouraged attendees to review the article.
The second research initiative, presented by Lighthouse developer Adrian Manning, relates to attestation subnets. As Manning explained in a GitHub PR: “This PR introduces the concept of ‘network shards,’ which is just an abstract notion labeling node IDs with a number (network shard). We can then use this network shard (number) to assign long-term subscription topics for nodes.” Manning is seeking final feedback on his proposal so his team can begin work on PeerDAS, Ethereum’s data availability sampling solution. For more information on data availability sampling, refer to this Galaxy Research report.
Nethermind developer Lukasz Rozmej asked whether EIP 7547 (Inclusion Lists) had been approved for inclusion in the Electra upgrade. Developers reiterated that EIP 7547 has not yet been approved.
Saulius Grigaitis, a developer building Grandine—an Ethereum CL client—raised a question about Ethereum’s fork choice rule in light of ongoing PeerDAS research. Grigaitis invited other developers to contribute ideas to the PeerDAS working group.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@galaxyhq
