Ethereum All Core Developers Consensus Call#135Writeup

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 135th ACDC call, which focused on preparing the testnets for Pectra Devnet 1, PeerDAS Devnet 1, and Simple Serialize (SSZ) Ethereum Improvement Proposals (EIPs).

Developers discussed in depth topics such as package maintenance, EIP including process and naming for the next round of Ethereum consensus layer upgrades. In addition, the meeting also touched on the progress of implementation under the Electra specification, the impact of PeerDAS network changes on Ethereum node processing and verification of data, and complex engineering issues regarding increasing blob gas limits.

Christine Kim, vice president of research at Galaxy Digital, took detailed notes on the key points of the meeting. BlockBeasts compiled the original text as follows:

On June 13, 2024, Ethereum developers gathered on Zoom for the All Core Developers Consensus (ACDC) Call #135. 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, also known as the beacon chain). This week, developers discussed the preparations for Pectra Devnet 1, PeerDAS Devnet 1, and a third dedicated testnet for the Simple Serialize (SSZ) Ethereum Improvement Proposal (EIPs).

announcement

Developers kicked off the meeting with two announcements. Parithosh Jayanthi, DevOps engineer at the Ethereum Foundation, said the ethPandaOps team, a group of engineers working at the Ethereum Foundation DevOps (EF DevOps), will take over the maintenance and development of the ethereum-package Kurtosis module. This package was used by developers to launch Ethereum test networks and related tools, such as the Grafana data dashboard for monitoring and testing various client implementations. The migration of the package from the Kurtosis technical team to the ethPandaOps team may affect users, as some links will redirect to GitHub repositories managed by the ethPandaOps team instead of the Kurtosis team. Jayanthi recommended that users update their software links and keep an eye on new versions released by the ethPandaOps team.

The second announcement was made by Tim Beiko, the head of protocol support at the Ethereum Foundation. Beiko said that he is working on introducing a new process for incorporating EIPs into Ethereum upgrades in a phased manner. He has created a draft EIP that defines the labels "Proposed for Inclusion", "Considered for Inclusion", and "Scheduled for Inclusion". He hopes that developers will review the document and provide feedback. He hopes to complete the document before the next ACD meeting.

Electra

The code specifications for the next major Electra version, v1.5.0-alpha.3, are nearing completion. The developers agreed to merge pull request (PR)#3768from the consensus spec GitHub repository into the next version. The pull request was created by Nimbus developer Etan Kissling, who pointed out that the "committee_bits" field should be appended to the end of the "Attestation" instead of in the middle of the data to avoid data serialization issues. In addition to PR #3768, Stokes asked if there were any other outstanding issues that needed to be resolved before the next major release of the Electra spec. Jayanthi mentioned in the Zoom chat that there are some outstanding issues with the validator integration triggered through the execution layer (EL). Stokes made a note to follow up on the status of the validator integration triggered by the EL after the meeting.

Regarding the progress of the latest Electra specification implementation, most consensus layer (CL) client teams at the meeting said they would be able to have new versions ready for testing within one to two weeks after v1.5.0-alpha.3 is finalized. The developers agreed to revisit the timing of the next Pectra development network, Pectra Devnet 1, in a few weeks.

PeerDAS

Next, the developers discussed progress on the implementation of PeerDAS, a network improvement to Ethereum that will enhance the ability of nodes to process and verify large amounts of arbitrary data submitted by users via blob transactions. Stokes recalled the decision made at the last ACDC meeting that the developers would work on PeerDAS in parallel with other Pectra EIPs, by activating a separate activation cycle for PeerDAS on the development network.

Lodestar developer Gajinder Singh said that based on discussions in a recent breakout session on PeerDAS, developers will activate PeerDAS on the Deneb upgrade and on a development network separate from other Pectra EIPs. Teku developer Enrico Del Fante said it would be easier for developers to build PeerDAS on the stable code spec that has been settled in the previous ethereum upgrade Deneb, rather than on the ever-changing Pectra code spec. Jayanthi agreed that merging the PeerDAS implementation with the other Pectra EIP implementations now could cause complications during testing, especially when trying to identify the source of bugs. He suggested keeping the two workstreams separate and then merging them once both implementations are more stable. Stokes agreed, saying that developers could revisit the matter of merging PeerDAS and other Pectra EIP implementations in about a month.

On the topic of launching PeerDAS Devnet 1, the client teams had no clear estimate for when the testnet would be ready for launch. Individual estimates in the meeting ranged from 2 weeks to 1 month. Stokes suggested revisiting the timeline for the devnet in a few weeks, when the client teams have more time to work on the PeerDAS implementation.

Beiko then noted that while PeerDAS is a network improvement and not a change to the Ethereum core protocol, he still wants the code changes to be included in the meta EIP for the Pectra upgrade. The meta EIP document is a public file that lists all the core protocol changes included in an Ethereum upgrade. Beiko noted that PeerDAS is the "biggest feature" in Pectra and that, while it doesn't require a hard fork to activate, it should still be included in the documentation to show that the developers are serious about having it ready in time for Pectra mainnet activation. No objection to this.

Increase blob gas limit

PeerDAS changes the way nodes process and propagate data through Ethereum’s peer-to-peer network layer. In order for users, especially Layer-2 rollups, to benefit from these changes, developers must raise the current limit of six blobs per block to a higher threshold that will allow for higher throughput of blobs (arbitrary data). Changing the blob limit requires changes to the Ethereum core protocol, which, as developers discussed in a meeting this week, may involve more complex engineering work than simply adjusting a constant value in the protocol’s technology stack.

Stokes proposed decoupling the dependencies between the execution layer (EL) and the consensus layer (CL) when changing the blob gas limit. Currently, any change to the blob gas limit requires changes to both the EL and CL protocols. Stokes proposed ways to break these dependencies, allowing developers to safely remove the hard-coded blob gas limit from EL and leave it entirely up to CL. Dankrad Feist, a researcher at the Ethereum Foundation (EF), pointed out that in addition to the dependency issue between EL and CL, the ripple effect of changing the blob gas limit on the gas calculation of blocks is also important. "The best way is to change the calculation," Feist said. "It was probably a mistake that the gas price calculation happened in EL. That should have been in CL, but it's harder to change now. ... It's not easy."

Developers agreed to continue investigating the best way to make changes to the blob gas limit and gas calculations in blocks. Developers also agreed to continue discussing whether activation of PeerDAS in Pectra will be accompanied by an increase in the blob gas limit. Developers disagreed on whether these changes should be combined together or phased in over multiple hard forks.

Jayanthi said incorporating the changes was a “risky” decision because developers won’t know exactly how PeerDAS will function until it’s activated on mainnet. Barnabas Busa, DevOps engineer at the Ethereum Foundation (EF), added that the scope of the Pectra hard fork was already large enough that additional code changes weren’t necessary. “The point is we already have a lot of EIPs, and I feel like we’re constantly adding more and more and it’s never going to end,” Busa said. “So, we have to draw a line somewhere, and that’s where we end. I don’t think it’s possible to release PeerDAS and increase the number of blobs in the next year and a half of testing.”

A developer with the screen name “Francesco” suggested that PeerDAS could be removed to “reduce the risk for Pectra” if the network changes were not accompanied by an increase in the number of blobs. “What is the benefit of PeerDAS for Pectra if there is no increase in the number of blobs?” Francesco asked.

To further illustrate the difficulty of testing PeerDAS, Jayanthi pointed out that testing EIP 4844, which introduced blobs to Ethereum, did not fully simulate how blobs actually behave and affect Ethereum mainnet. "The problem is that testnets are very difficult," Jayanthi said. "We did a lot of great testing with 4844, but blobs didn't behave exactly the same on mainnet as they did in testing. We did see issues with weaker nodes. We did see timing challenges and things like that, which is why even if we could simulate a perfect situation in a devnet where PeerDAS and increasing the number of blobs all worked, it wouldn't really make sense for mainnet, and that's the main reason why I think we should do it in steps rather than all at once."

EF researcher Ansgar Dietrichs commented that it is wrong to link the increase in the number of blobs to PeerDAS, because PeerDAS alone already requires developers to choose a blob number value. While developers can choose the same number as on Ethereum mainnet, the decision about what number PeerDAS should use must be made. The only reason to choose the same number is that developers have added complexity to PeerDAS to allow it to fall back to the blob propagation mechanism in the current Deneb specification in the event of errors. Dietrichs added that concerns about testing complexity further reinforce his view that Pectra should be activated via two hard forks, not one, but that this does not mean that he thinks PeerDAS should be decoupled from the change in the number of blobs.

SSZ Update

Kissling shared an update on the progress of three SSZ-related EIPs. He noted that implementation work on these EIPs has already begun on multiple clients, including Teku, Grandine, and Lighthouse. He said that developers can start discussing the development network timeline for these SSZ EIPs and may include them in the scope of the Pectra upgrade at the next ACDC meeting.

F-Star Naming

There is a thread on Ethereum Magicians discussing the name of the next Ethereum consensus layer (CL) upgrade after Electra. Developers have settled on a name for the execution layer (EL) upgrade after Prague: Osaka. Candidate CL upgrade names are: Fulu, Felis, Formosa, and Funi. These names all follow the naming convention of major stars starting with "F" and are suitable for the sixth full network upgrade of the Beacon Chain. Stokes asked the developers on the call to express their views on this topic on the Magicians thread.