Summary of the latest Ethereum core developer meeting: Activating PeerDAS and increasing blob gas limits

Original title: 《 Ethereum All Core Developers Consensus Call #135 Writeup》
Original author: Christine Kim
Original translation: 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, and the meeting focused on preparing the test network for Pectra Devnet 1, PeerDAS Devnet 1, and Simple Serialize (SSZ) Ethereum Improvement Proposals (EIPs).

Developers had in-depth discussions on topics such as package maintenance, EIPs including processes and naming for the new round of Ethereum consensus layer upgrades. In addition, the meeting also involved progress in implementation under the Electra specification, the impact of PeerDAS network changes on Ethereum node processing and verification 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, and BlockBeasts compiled the original text as follows:

On June 13, 2024, Ethereum developers gathered on Zoom to attend the All Core Developers Consensus (ACDC) Call #135 meeting . The ACDC call is a biweekly 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 preparations for Pectra Devnet 1, PeerDAS Devnet 1, and a third dedicated test network for the Simple Serialize (SSZ) Ethereum Improvement Proposal (EIPs).

Announcements

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 within 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 to introduce 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. Developers agreed to merge the pull request (PR)#3768 in the consensus specification 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 the middle of the data to avoid data serialization issues. In addition to PR #3768, Stokes asked if there were other outstanding issues that needed to be resolved before the next major version of the Electra specification is released. Jayanthi mentioned in the Zoom chat that there are some outstanding issues with validator integration triggered via the Execution Layer (EL). Stokes made a note to follow up on the status of validator integration triggered by the EL after the meeting.

Regarding progress on the latest Electra spec implementation, most of the consensus layer (CL) client teams at the meeting said they would be able to have a new version ready for testing within one to two weeks of v1.5.0-alpha.3 being 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 at the last ACDC meeting that the developers would work on PeerDAS in parallel with other Pectra EIPs, through a separate activation cycle for PeerDAS on the development network.

Based on discussions at a recent breakout session on PeerDAS, the developers will activate PeerDAS on the development network separate from the other Pectra EIPs, according to Lodestar developer Gajinder Singh. Teku developer Enrico Del Fante said it would be easier for developers to build PeerDAS on the stable code spec that had 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 errors. He suggested separating the two workstreams and then merging them once both implementations are more stable. Stokes agreed, saying that developers could revisit the merging of PeerDAS and the other Pectra EIP implementations in about a month.

On the topic of launching PeerDAS Devnet 1, the client teams did not have a 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 timing of the devnet in a few weeks, when the client teams have more time to work on the PeerDAS implementations.

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 objections to that.

Raising the blob gas limit

PeerDAS changes the way nodes process and propagate data through Ethereum’s peer-to-peer networking 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 would 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 the value of a constant in the protocol stack.

Stokes proposes to decouple the dependencies between the execution layer (EL) and the consensus layer (CL) when changing the blob gas limit. Currently, any changes to the blob gas limit require 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, an Ethereum Foundation (EF) researcher, noted that in addition to the dependency issues between EL and CL, the knock-on effects of changing the blob gas limit on the gas calculation of blocks are also important. Feist said: "The best way is to change the calculation. It's probably a mistake that the gas price calculation happens in EL. That should be in CL, but it's harder to change now. ... It's not easy."

The developers agreed to continue investigating the best path to make changes to the blob gas limit and gas calculation in blocks. The developers also agreed to continue discussing whether the activation of PeerDAS in Pectra will be accompanied by an increase in the blob gas limit. The 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 were not needed. “The point is that 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 “de-risk Pectra” if the network changes were not accompanied by an increase in the number of blobs. “What exactly 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 the actual performance and impact of blobs on the Ethereum mainnet. "The problem is that testnet is very difficult," Jayanthi said. "We did a lot of great testing with 4844, but blobs don't behave exactly the same on mainnet as they do in testing. We do see issues with weaker nodes. We do see timing challenges and things like that, which is why even if we could simulate a perfect situation in devnet where PeerDAS and increasing the number of blobs both worked, it wouldn't really make sense for mainnet, and that's the main reason I think we should do it in steps rather than all at once."

EF researcher Ansgar Dietrichs commented that it is wrong to link increasing 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 case of errors. Dietrichs added that concerns about testing complexity further reinforce his view that Pectra should be activated via two hard forks, rather than one, but that doesn’t mean he thinks PeerDAS should be decoupled from the blob number change.

SSZ Update

Kissling shared an update on the progress of three SSZ-related EIPs . He noted that implementation work on these EIPs is already underway on multiple clients, including Teku, Grandine, and Lighthouse. He said developers could start discussing a devnet timeline for these SSZ EIPs and potentially 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", which is suitable for the sixth full network upgrade of the Beacon Chain. Stokes asked developers on the call to comment on this topic on the Magicians thread.

「 Original link 」

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群： https://t.me/theblockbeats

Telegram 交流群： https://t.me/BlockBeats_App

Twitter 官方账号： https://twitter.com/BlockBeatsAsia