Ethereum All Core Developers Consensus Call #131 Writeup
On April 4, 2024, Ethereum developers gathered over Zoom for All Core Developers Consensus (ACDC) call #131. The ACDC calls are a bi-weekly meeting series where developers discuss and coordinate changes to the consensus layer (CL) of Ethereum. This week the call was chaired by Ethereum Foundation (EF) Researcher Alex Stokes. Client teams shared updates on the implementation status of the four code changes, or Ethereum Improvement Proposals (EIPs), that have been approved for inclusion in the next CL-focused hard fork, Electra. Stokes and EF Researcher Hsiao-Wei Wang aim to finalize specifications for the first Electra multi-client developer test network, or devnet, by the end of this month. In parallel to these efforts, Stokes encouraged client teams to start working on Electra EIP implementations and continue their work on data availability sampling for the Beacon Chain, also known as peerDAS.
Deneb
Developers discussed briefly two topics related to the Deneb upgrade. The first was a point of clarification on the “voluntary_exits” gossip topic, a field in the CL networking specifications that had been modified for EIP 7044. Stokes confirmed that the way all client teams have implemented EIP 7044 is by continuing to use the “old domain” for verifying signatures while using a new Deneb fork ID for the gossip topic.
The second point of discussion related to Deneb was about last week’s network outage causing an unusually high number of missing blocks on Ethereum. Prysm developer Terence Tsao flagged the issue last week on ACDE #184. Since then, the team behind the relay responsible for most of the missing blocks Bloxroute has issued a post-mortem about the issues their relay faced and the fixes they have implemented. “The gist of the issue is that there’s definitely some edge cases with how the Beacon API is interpreted and used,” said Tsao.
“Ideally, this wouldn’t happen,” responded Stokes, “We have a lot of testing in place that makes sure things like this don’t happen but this one kind of slipped through the cracks.” Stokes said developers should work more closely with the Bloxroute team in the future to prevent issues such as this from happening again.
Electra
Then, developers discussed the status of implementation for the four EIPs included so far in Electra:
EIP 6110 (Supply validator deposits on chain) – Teku developer Mikhail Kalinin said that he is investigating ways to reduce complexity between the implementation of this EIP, 7002, and 7251 in the same upgrade.
EIP 7002 (Execution layer triggerable exits) – Kalinin is also proposing minor changes to this EIP that will require corresponding changes to the Engine API. These changes are a work-in-progress.
EIP 7251 (Increase the MAX_EFFECTIVE_BALANCE) – Lighthouse developer “ethDreamer” said there are two outstanding questions about this EIP. The first is whether to include custom ceilings for partial withdrawals for validators with an effective balance greater than 32 ETH. The second is whether to enable consolidation of validators as a CL or EL initiated operation. Developers had initially leaned towards designing this feature as a CL or Beacon Chain operation because this would lower code complexity. However, feedback from the Lido team explaining that this strategy may break certain “accounting” operations in their smart contracts has created a stronger rationale for possibly re-designing stake consolidation to initiate in some way through the EL. Developers agreed to organize a breakout call on the design of this EIP to answer these open questions over the next few weeks.
EIP 7549 (Move committee index outside attestation) – Kalinin explained there is one downside to this EIP related to the fact that a higher number of attestations packed into a block will increase the density of blocks and possibility reduce flexibility in the attestation aggregation process. Kalinin is experimenting with different ways to streamline the attestation aggregation process under EIP 7549. Long-term, developers discussed making more invasive changes to Ethereum’s networking layer to improve the process such as the one mentioned in this Ethereum Research post.
Next, client teams shared updates on their progress for implementation on the above four EIPs. For Lighthouse, the team has made the most progress on EIP 7251. They have also started work on EIP 7549 but have yet to start work on EIP 7002. For the Teku team, they have implemented EIP 6110 and are in-progress for implementing 7549. They are looking into 7251. The Lodestar team has implemented 6110 and mostly implemented 7251. For Prysm, the team is in the process of working on EIP 7251 and assigning tasks for the other EIPs. There is a detailed tracker available on the status of client teams’ implementation of Electra EIPs.
EIP 7547 - Inclusion lists
An EIP that developers are still considering for potential inclusion in Electra is EIP 7547. As discussed on ACDE #184, there are outstanding questions about the design of this code change in light of future account abstraction EIPs such as EIP 3074. EF Research Mike Neuder said that there is a breakout room for inclusion lists tomorrow, April 5, to discuss paths forward for making EIP 7547 compatible with EIP 3074. The general sentiment, however, from developers is that the paths forward for inclusion lists require major changes to their design that are not as aesthetically pleasing as the original design. That said, Neuder pointed out that aesthetically pleasing or not, the issues on EIP 7547’s compatibility with account abstraction are unavoidable and therefore developers will have to resolve them somehow anyways, be it for Electra or a future hard fork.
Stokes recommended continuing to work on inclusion lists in parallel to Electra EIPs but refraining from committing to the code change in Electra for now. Stokes encouraged client teams to work on the four Electra EIPs as a priority. On the EL side, the EIPs client teams will be implementing for Prague are the same four EIPs mentioned above in addition to EIP 2537, Precompile for BLS12-381 curve operations.
Stokes asked when client teams should aim to spin up the first devnet for the Prague/Electra (Pectra) upgrade. Lighthouse developer “Sean” said that it is too early to estimate these dates. Further, he emphasized that rushing to launch a devnet before Pectra specifications are finalized is “counterintuitive” as it may end up causing developers to write lots of code that they don’t end up using anyway for the upgrade. Stokes agreed with Sean’s sentiment and said that his priority will be to create Electra specifications based on the above four EIPs by the end of the month, if not sooner.
peerDAS
In parallel to Electra, developers are continuing work on both inclusion lists and peerDAS. peerDas represents a new design for validators to verify blob data such that validators can process more blobs per block. Stokes recommended that client teams dedicate roughly 80% of their resources and time to implementing Electra EIPs and 20% to working on peerDAS.
Prysm developer “Potuz” pushed back on the sentiment that PeerDAS can be implemented without a hard fork. He said the networking layer of Ethereum would be brutally impacted if validator nodes do not coordinate to activate these code changes simultaneously during an upgrade. Therefore, Potuz recommended that developers decide now whether they want to prioritize peerDAS for inclusion in Electra. Developers had mixed opinions as to whether Electra EIPs should take priority over peerDAS. Stokes reiterated that developers could work on the two in parallel. ethDreamer said that an easier code change to commit to for Electra, instead of peerDAS, would be an increase to the blob count per block. EF Research Ansgar Dietrichs noted that he has drafted an EIP to gradually increase blob count on Ethereum but that this proposal would not be useful if developers do end up being ready to ship peerDAS for Electra.
Stokes said that based on the conversation it was early to commit to either an increase in blob count or peerDAS in the Electra upgrade. Stokes recommended continuing work on Electra and peerDAS in parallel and re-discussing a strategy for both in the coming weeks after client teams have had more time to work on Electra EIP implementations and peerDAS research.