Summary of the latest meeting of Ethereum core developers: Activate PeerDAS, increase blob gas limit

Original Title: “Ethereum All Core Developers Consensus Call #135 Writeup”

Author: Christine Kim

Compiled by: Luccy, BlockBeats

Editor’s Note: The Ethereum All Core Developers Consensus Call (ACDC) is held biweekly, primarily to discuss and coordinate changes to the Ethereum consensus layer (CL). This is the 135th ACDC call, focusing on preparations for Pectra Devnet 1, PeerDAS Devnet 1, and the testing networks for the Simple Serialize (SSZ) Ethereum Improvement Proposals (EIPs).

The developers engaged in in-depth discussions on topics such as package maintenance, the EIP inclusion process, and naming the new round of Ethereum consensus layer upgrades. Additionally, the meeting addressed the implementation progress under the Electra specification, the impact of PeerDAS network changes on Ethereum nodes' data handling and validation, and complex engineering issues regarding increasing blob gas limits.

Christine Kim, Vice President of Research at Galaxy Digital, recorded the key points of the meeting in detail, and BlockBeats 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 series of meetings held every two weeks, 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, the developers discussed preparations for Pectra Devnet 1, PeerDAS Devnet 1, and a third dedicated testing network for the Simple Serialize (SSZ) Ethereum Improvement Proposals (EIPs).

Announcements

The developers began the meeting with two announcements. Parithosh Jayanthi, a DevOps engineer at the Ethereum Foundation, stated that the ethPandaOps team, a group of engineers working in Ethereum Foundation DevOps (EF DevOps), will take over the maintenance and development of the ethereum-package Kurtosis module. This package has been used by developers to launch Ethereum test networks and related tools, such as Grafana dashboards for monitoring and testing various client implementations. During the migration of this package from the Kurtosis tech team to the ethPandaOps team, users may be affected as some links will redirect to GitHub repositories managed by the ethPandaOps team instead of the Kurtosis team. Jayanthi advised users to update their software links and pay attention to new releases from the ethPandaOps team.

The second announcement was made by Tim Beiko, Director of Protocol Support at the Ethereum Foundation. Beiko stated that he is working to introduce new processes to phase in EIPs into Ethereum upgrades. He has created a draft EIP that defines the labels "Proposed for Inclusion," "Considered for Inclusion," and "Scheduled for Inclusion." He hopes developers will review the document and provide feedback, aiming to finalize it before the next ACD meeting.

Electra

The code specification for the upcoming Electra major release v1.5.0-alpha.3 is nearing completion. The developers agreed to merge pull request (PR) #3768 in the consensus specification GitHub repository into the next version. This pull request was created by Nimbus developer Etan Kissling, who noted that the "committee_bits" field should be appended to the end of "Attestation" rather than in the middle of the data to avoid data serialization issues. Besides PR #3768, Stokes asked if there were any other pending issues that needed to be resolved before the next major release of the Electra specification. Jayanthi mentioned in the Zoom chat that there are some pending issues related to validator integration triggered by the execution layer (EL). Stokes noted to follow up on the status of EL-triggered validator integration after the meeting.

Regarding the implementation progress of the latest Electra specification, most consensus layer (CL) client teams at the meeting indicated that they would be ready to test the new version within one to two weeks after finalizing v1.5.0-alpha.3. The developers agreed to revisit the scheduling for the next Pectra development network, Pectra Devnet 1, in a few weeks.

PeerDAS

Next, the developers discussed the implementation progress of PeerDAS. PeerDAS is a network improvement for Ethereum that will enhance nodes' ability to process and validate large amounts of arbitrary data submitted by users via blob transactions. Stokes reviewed the decision made at the last ACDC meeting that developers would parallel-develop PeerDAS alongside other Pectra EIPs by activating PeerDAS through a separate activation cycle on the development network.

Lodestar developer Gajinder Singh stated that based on recent discussions in a breakout session about PeerDAS, developers will activate PeerDAS on a separate development network based on the Deneb upgrade, apart from other Pectra EIPs. Teku developer Enrico Del Fante mentioned that it is easier for developers to build PeerDAS on the stable code specifications established in the previous Ethereum upgrade Deneb rather than on the constantly changing Pectra code specifications. Jayanthi agreed that merging PeerDAS implementation with other Pectra EIP implementations now could introduce complexities during testing, especially when trying to identify the source of errors. He suggested keeping the two workflows separate and merging them once both implementations are more stable. Stokes concurred and said that developers could revisit the merging of PeerDAS and other Pectra EIP implementations in about a month.

Regarding the launch of PeerDAS Devnet 1, the client teams did not provide a clear estimate on when they would be ready to launch the testnet. Individual estimates at the meeting ranged from approximately 2 weeks to 1 month. Stokes suggested that in a few weeks, when the client teams have more time to work on PeerDAS implementation, they should revisit the scheduling for the development network.

Beiko then pointed out that while PeerDAS is a network improvement rather than a change to the Ethereum core protocol, he still hopes to include the code changes in the meta EIP for the Pectra upgrade. The meta EIP document is a public file listing all core protocol changes included in the Ethereum upgrade. Beiko noted that PeerDAS is the "largest feature" in Pectra, and although it does not require hard fork activation, it should still be documented to indicate that developers are seriously preparing for its timely readiness for activation on the Pectra mainnet. There was no dissent on this.

Increasing Blob Gas Limits

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

Stokes proposed decoupling the dependencies between the execution layer (EL) and the consensus layer (CL) when changing the blob gas limits. Currently, any changes to the blob gas limits require modifications to both the EL and CL protocols. Stokes suggested several ways to break these dependencies, allowing developers to safely remove hardcoded blob gas limits from the EL and leave them entirely to the CL. Ethereum Foundation (EF) researcher Dankrad Feist pointed out that, in addition to the dependency issue between EL and CL, the chain reaction of changing blob gas limits on gas calculations for blocks is also significant. Feist stated, "The best way is to change the way we calculate. It might be a mistake to calculate gas prices in the EL. That should be in the CL, but changing it now is harder… It’s not easy."

The developers agreed to continue investigating the best ways to change blob gas limits and gas calculations in blocks. They also agreed to continue discussing whether the activation of PeerDAS in Pectra would be accompanied by an increase in blob gas limits. There was a divergence of opinion among developers on whether these changes should be combined or implemented in phases through multiple hard forks.

Jayanthi expressed that combining these changes is a "risky" decision because developers will not know the specific performance of PeerDAS until it is activated on the mainnet. EF DevOps engineer Barnabas Busa added that the scope of the Pectra hard fork is already quite large, and there is no need to add additional code changes. Busa stated, "The key is that we already have a lot of EIPs, and I feel like we keep adding more, and it will never end. So we have to draw a line somewhere, and that’s our endpoint. I think it’s impossible to release PeerDAS and increase the number of blobs in the testing time over the next year and a half."

A developer with the screen name "Francesco" suggested that if network changes do not accompany an increase in the number of blobs, PeerDAS could be removed to "reduce the risk of Pectra." Francesco asked, "What is the benefit of PeerDAS in Pectra if there is no increase in the number of blobs?"

To further illustrate the difficulties of testing PeerDAS, Jayanthi pointed out that testing the introduction of blobs to Ethereum through EIP 4844 did not fully simulate the actual performance and impact of blobs on the Ethereum mainnet. Jayanthi said, "The problem is that testing networks are very difficult. We have indeed done a lot of excellent testing related to 4844, but the performance of blobs on the mainnet is not entirely consistent with their performance in testing. We have seen weaker nodes encountering issues. We have seen timing challenges and similar situations, which is why even if we can simulate a perfect scenario where PeerDAS and increasing the number of blobs work well in the development network, it has no practical significance for the mainnet. That’s also the main reason I think we should take it step by step rather than trying to do it all at once."

EF researcher Ansgar Dietrichs commented that linking the increase in the number of blobs with PeerDAS is a mistake because PeerDAS alone already requires developers to choose a value for the number of blobs. While developers can choose the same number as on the Ethereum mainnet, a decision must be made about what number PeerDAS should use. The only reason to choose the same number is that developers have increased the complexity of PeerDAS, allowing it to fall back to the current blob propagation mechanism in the Deneb specification in case of errors. Dietrichs added that concerns about testing complexity further reinforced his view that Pectra should be activated through two hard forks rather than one, but that does not mean he believes PeerDAS should be separated from changes in the number of blobs.

SSZ Updates

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

F-Star Naming

There is a post on Ethereum Magicians discussing the name for the next Ethereum consensus layer (CL) upgrade after Electra. Developers have identified the name for the execution layer (EL) upgrade after Prague: Osaka. The candidate names for the CL upgrade are: Fulu, Felis, Formosa, and Funi. These names follow the convention of starting with "F" for the sixth full network upgrade of the Beacon Chain. Stokes asked developers on the call to share their thoughts on this topic in the Magicians post.