Summary of the latest meeting of Ethereum core developers: Activating PeerDAS, increasing blob gas limit

Original title: "Ethereum All Core Developers Consensus Call #135 Writeup"

Editor's note: Ethereum All The Core Developer Consensus Call (ACDC) is held every two weeks to discuss and coordinate changes to the Ethereum Consensus Layer (CL). This is the 135th ACDC conference call. This conference mainly focuses on preparing the test network of Pectra Devnet 1, PeerDAS Devnet 1 and Simple Serialize (SSZ) Ethereum Improvement Proposals (EIPs).

The developers had in-depth discussions on issues such as software package maintenance, EIP inclusion process and naming the new round of Ethereum consensus layer upgrade. Additionally, the session touched on implementation progress under the Electra specification, the impact of PeerDAS network changes on how Ethereum nodes process and validate data, and the complex engineering issues surrounding increasing blob gas limits.

Christine Kim, Vice President of Research at Galaxy Digital, recorded the key points of this meeting in detail, and BlockBeasts compiled the original text as follows:

On June 13, 2024, Ethereum developers gathered on Zoom to participate All Core Developers Consensus (ACDC)Call #135 meeting. The ACDC call is a biweekly series 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 Simple Serialize (SSZ) Ethereum Improvement Proposals (EIPs).

Announcements

The developers started the meeting with two announcements. Ethereum Foundation DevOps engineer Parithosh Jayanthi said 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 in the past to launch Ethereum test networks and related tools, such as the Grafana data dashboard for monitoring and testing various client implementations. The migration of this package from the Kurtosis technical team to the ethPandaOps team may impact users as some links will redirect to GitHub repositories managed by the ethPandaOps team and no longer the Kurtosis team. Jayanthi advises users to update their software links and keep an eye out for new releases from the ethPandaOps team.

The second announcement was made by Tim Beiko, Head of Protocol Support at the Ethereum Foundation. Beiko said he is working to introduce a new process to include EIPs in Ethereum upgrades in phases. 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. He hoped to have the document completed before the next ACD meeting.

Electra

The code specification for the next major version of Electra, v1.5.0-alpha.3, is almost complete. The developers agreed to merge 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" rather than in the middle of the data to avoid data serialization issues. In addition to PR #3768, Stokes asked if there are any other open issues that need 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 the integration of validators triggered through the execution layer (EL). Stokes made a note of following up on the status of EL-triggered validator integration after the meeting.

Regarding the implementation progress of the latest Electra specification, most of the consensus layer (CL) client teams at the meeting stated that they will be ready within one to two weeks after v1.5.0-alpha.3 is finalized New version for testing. 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 the progress of PeerDAS implementation. PeerDAS is a network improvement to Ethereum that will enhance nodes’ ability 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 developers would develop 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 at a recent breakout session about PeerDAS, developers will activate PeerDAS on top of 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 specifications already established in the previous Ethereum upgrade Deneb, rather than on the ever-changing Pectra code specifications. Jayanthi agreed that merging the PeerDAS implementation with other Pectra EIP implementations now could cause complications during testing, especially when trying to identify the source of errors. He suggested keeping the two workflows separate and then merging them once their implementations are more stable. Stokes agreed, saying developers could revisit merging PeerDAS and other Pectra EIP implementations in about a month.

On the topic of launching PeerDAS Devnet 1, the client team has no clear estimate on when the testnet will be ready for launch. Individual estimates at sessions ranged roughly from 2 weeks to 1 month. Stokes suggested revisiting the timeline for developing the network in a few weeks, when the client team has more time to work on the PeerDAS implementation.

Beiko then pointed out that while PeerDAS is a network improvement rather than 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 document that lists all core protocol changes included in the Ethereum upgrade. Beiko pointed out that PeerDAS is the “biggest feature” in Pectra, and although it does not require a hard fork activation, it should still be included in the documentation to show that developers are serious about having it ready in time for Pectra mainnet activation. No objection to this.

Raise blob gas limit

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

Stokes proposed decoupling the dependencies between the execution layer (EL) and the consensus layer (CL) when changing the blob gas limit. Currently, any changes to blob gas limits require changes to the EL and CL protocols. Stokes proposed ways to break these dependencies, allowing developers to safely remove hard-coded blob gas limits from EL and leave them entirely up to the CL. Ethereum Foundation (EF) researcher Dankrad Feist pointed out that in addition to the dependency issue between EL and CL, the knock-on effect of changing the blob gas limit on the gas calculation of the block is also important. Feist said: "The best way is to change the calculation. It may be a mistake that the gas price calculation happens in EL. That should be in CL, but it is harder to change now. ... It is not easy."

The developers agreed to continue investigating the best way to make changes to blob gas limits and in-block gas calculations. The developers also agreed to continue discussions on whether activating PeerDAS in Pectra would be accompanied by an increase in the blob gas limit. Developers are divided on whether the changes should be rolled out together or implemented in phases across multiple hard forks.

Jayanthi said that incorporating these changes was a "risky" decision because developers will not know how PeerDAS will perform until it is activated on the mainnet. Ethereum Foundation (EF) DevOps engineer Barnabas Busa added that the scope of the Pectra hard fork is already very large and does not require additional code changes. "The key is we already have a lot of EIPs and I feel like we keep adding more and it never ends," Busa said. "So, we have to draw a line somewhere and that's where we end. I think in It will be impossible to release PeerDAS and increase the number of blobs during the next year and a half of testing."

A developer whose screen name is "Francesco" suggested that if network changes will not be accompanied by an increase in the number of blobs. , PeerDAS can be removed to "reduce Pectra's risk." Francesco asked: "What is the benefit of Pectra's PeerDAS if it does not increase the number of blobs?"

To further illustrate the difficulty of testing PeerDAS, Jayanthi pointed out that testing EIP 4844 that introduced blobs to Ethereum did not fully simulate blobs Actual performance and impact on the Ethereum mainnet. Jayanthi said: “The problem is that it’s very difficult to test the network. We did have a lot of great tests related to 4844, but the blobs didn’t perform exactly the same on mainnet as they did in the tests. We did see weaker nodes emerge. Question. We do see timing challenges and things like that, which is why even though we can simulate a perfect situation in the development network where PeerDAS and increasing the number of blobs work, it doesn't have any practical implications for the mainnet Meaning, this is the main reason why I think we should do it step by step instead of doing it all at once.”

EF researcher Ansgar Dietrichs commented that it is a mistake to associate increasing the number of blobs with PeerDAS, since PeerDAS alone already requires developers to choose a value for the number of blobs. While developers can choose the same number as on Ethereum mainnet, a decision must be made about what number PeerDAS should use. The only reason for choosing the same number is that the developers increased the complexity of PeerDAS to enable it to fall back to the blob propagation mechanism in the current Deneb specification in the event of an error. 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 blob count changes.

SSZ UPDATE

Kissling shared a progress update on three SSZ-related EIPs. He noted that implementation of these EIPs is already underway on multiple clients, including Teku, Grandine, and Lighthouse. Developers can 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, he said.

F-Star Naming

There is a post on Ethereum Magicians discussing the name of the next Ethereum consensus layer (CL) upgrade after Electra. The developers have decided on a name for the executive layer (EL) upgrade after Prague: Osaka. Candidate CL upgrade names are: Fulu, Felis, Formosa, and Funi. These names all follow the major star naming convention starting with "F" and are suitable for the sixth network-wide upgrade of Beacon Chain. Stokes asked the developers on the call to weigh in on the topic on the Magicians thread.

The above is the detailed content of Summary of the latest meeting of Ethereum core developers: Activating PeerDAS, increasing blob gas limit. For more information, please follow other related articles on the PHP Chinese website!