skip to content

Ethereum All Core Developers Consensus Call #133 Writeup

Ethereum All Core Developers Consensus Call #133 Writeup - Galaxy Research

On May 2, 2024, Ethereum developers gathered over Zoom for All Core Developers Consensus (ACDC) call #133. The ACDC calls are a bi-weekly meeting series where developers discuss and coordinate changes to the consensus layer (CL) of Ethereum, also called the Beacon Chain. This week the call was chaired by Ethereum Foundation (EF) Researcher Alex Stokes. Developers discussed progress on Electra Ethereum Improvement Proposal (EIP) implementations. They also discussed research on a few parallel initiatives including confirmation rules and data availability sampling. Lido co-founder Vasiliy Shapovalov and Lighthouse developer “Dapplion” presented a new EIP, EIP 7684, to strengthen the security guarantees of smart contract-based staking pools.

As a closing remark, Stokes reminded developers that the next ACDC call is cancelled. CL client teams will reconvene for the next ACDC on May 30, 2024.

Confirmation Rule Research

Roberto Saltini, Lead Researcher in Formal Verification of Distributed Systems at ConsenSys, presented research on a confirmation rule for Ethereum that can be used to determine if a block will be part of the canonical chain before the block becomes finalized. The rule relies on a set of assumptions about the network such as the absence of any validator controlling more than 1/3 of ETH staked. Based on the research findings, Saltini has submitted a pull request on GitHub to introduce a confirmation rule that Ethereum nodes can rely on to confirm blocks. He asked for feedback from developers on the rule’s implementation and pointed to the full research paper where developers can get more details about the rule’s motivation and set of assumptions.


Andrew Coathup, the editor of a weekly Ethereum newsletter called Week In Ethereum News, asked on the meeting agenda if the “Considered For Inclusion” (CFI) for EIP 7547, Inclusion Lists, should be removed given that the EIP will not be included in the Electra upgrade. Stokes was under the impression that the CFI status is not generally removed from EIPs once it is granted by developers. EF Protocol Support Lead Tim Beiko said that in his view the CFI status is removed from all EIPs that do not end up making it into an upgrade once the scope of the upgrade is finalized. Regardless of the meaning or utility of the CFI label, what’s clear is that EIP 7547 will not be included in Electra. Developers may re-discuss the EIP later for a different upgrade.

Then, developers discussed preparations for Pectra Devnet 0, the first developer-focused, multi-client test network implementing client software that supports Prague and Electra EIPs. EF researchers have released a new version of Electra specifications that contains bug fixes from the prior one and new test vectors. EF Researcher Hsiao-Wei Wang said that she has received reports of issues in the latest release and said that a hotfix for the specifications will be ready early next week. In the meantime, she encouraged developers to reach out if they encounter any new bugs.

Developers are aiming to launch Pectra Devnet 0 in roughly two weeks. It was clear from the discussion that CL client teams would not be ready for a launch the following week, but possibly the week after, starting May 13. EF Developer Operations Engineer Barnabas Busa shared a link to the client tracker document for keeping tabs on the readiness of client teams for Devnet 0. On the call, representatives of various client teams shared more detailed updates on their progress.

Lighthouse – Instead of working on the implementation of Electra EIPs one by one, the team is working on implementing all Electra EIPs in tandem according to the area of the client code base these EIPs impact. For example, working on all changes impacting state, then blocks, then networking, and so on. Thus, while the client tracker document may not reflect much progress on each individual EIP, “Sean” from the Lighthouse team assured developers that progress was being made. He noted that most of the time’s focus and energy has been on EIP 7549, Move committee index outside Attestation, which he noted “touches a lot of the code base.”

Lodestar – The team is making progress and working on the implementation of EIP 7549.

Teku – The implementation of EIP 6110 and EIP 7002 are both complete. MaxEB and EIP 7549 are a work in progress.

Prysm – The team is taking a similar approach to Lighthouse for implementing Electra EIPs. James He representing the Prysm team noted that EIP 7549 requires a lot of work and has slowed down the team’s progress.

Grandine - Saulius Grigaitis, representing the Grandine client, said “huge work” still needs to be done for completing the attestation refactoring necessary for EIP 7549.

Nimbus - The team is taking a similar approach to Lighthouse and Prysm for implementing Electra EIPs. “Dustin” from the Nimbus team expressed concerns about the challenges of implementing EIP 7549.

Speaking more to the implementation of EIP 7549, Dustin asked whether there may have been a “process failure” in the way the code change was presented and then approved for inclusion in Electra. Though presented as “a minor change,” the EIP is proving to be more difficult to implement than developers initially expected. Sean agreed with Dustin’s concerns and asked if there was a process through which developers could readjust the scope of a fork after implementation work has started. Stokes said that developers will “make it work” and that in the future, they should “be mindful” of these types of unexpected learnings about EIP complexity. Dapplion also chimed in saying that the original EIP 7549 was a simpler proposal and that developers should be mindful of the consequences of changing the details of an EIP on an upgrade’s overall complexity and scope. “If an EIP mutates, we should be mindful of the consequences even if its already considered for inclusion,” said Dapplion.


Shapovalov presented EIP 7684, Return deposits for distinct credentials. The main motivation for this code change is to prevent front-running attacks against smart contract-based staking pools. The EIP document states, “Some staking operations feature two distinct entities, one operating the validating key, and one funding the deposit. The funding entity delegates control of the stake operation but must retain ultimate control of funds. If the funding entity naively submits a single deposit with the full stake amount and the other entity's validating key, it is subject to a front-run attack.” While there are workarounds to prevent such attacks, the mitigation techniques are difficult to deploy exclusively through smart contracts and as Shapovalov notes often expensive and inefficient. To offer a more effective solution, the EIP suggests the creation of “a distinct execution withdrawal credential” that can automatically withdraw deposits for validator records.

Shapovalov said that he is presenting the EIP to raise awareness about the code change but not necessarily to have it included in Electra. It is a small enough code change in terms of complexity that he believes developers could include last-minute in Electra if they wanted. However, for now, he is mainly sourcing feedback and review of the proposal. The author of the EIP Dapplion added that the EIP is not “trivial” but is the simplest code change in his mind to address the problem of front running attacks against staking pools. That said, Dapplion encouraged developers to see if an even simpler solution could be found.


Developers have been making progress on enabling data availability sampling (DAS) on Ethereum. The initiative to greatly enhance Ethereum’s capacity to support blob transactions is called PeerDAS. Stokes said that an initial alpha release for the specifications of PeerDAS has been created. “It's really exciting to see the progress there,” said Stokes. Representatives from the Lighthouse, Prysm, and Teku team all shared updates on their progress with the alpha release specifications. Developers also discussed a few open questions about the specs, specifically assumptions about data synchrony. For initial testnets, developers agreed to use the strategy that works the best for them and come to a consensus about the standard for data synchrony later.

Closing remarks

Due to an Ethereum developer interop event in mid-May, the next ACDC call is cancelled. Developers will reconvene for these meetings on May 30, 2024. All Core Developers Execution (ACDE) #187 is still scheduled to occur next Friday, May 9.