Summary of the latest Ethereum core developer meeting: Pectra upgrade launched, PeerDAS implementation progress discussed

Original title: 《 Ethereum All Core Developers Consensus Call #138 Writeup》
Original author: Christine Kim
Original translation: Ladyfinger, 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 138th ACDC call, which covered the launch of Pectra Devnet 1, changes to the beacon block body and engine API structure, the inclusion of stable container Ethereum Improvement Proposals (EIPs) into Pectra, namely EIP 7688 and EIP 7495, and updates to PeerDAS. During the meeting, developers reviewed the readiness of Pectra upgrades and explored some unresolved issues and proposals on the PeerDAS implementation. In addition, Nimbus developer Etan Kissling also shared the progress of the implementation of EIP 7688 and EIP 7495, emphasizing the importance of these proposals to upgrade Ethereum's data serialization method. Christine Kim, vice president of research at Galaxy Digital, took detailed notes on the key points of this meeting, and BlockBeats compiled the original text as follows:

On July 25, 2024, Ethereum developers held the 138th All Core Developer Consensus (ACDC) meeting via Zoom. The ACDC meeting is a series of meetings held every two weeks where developers discuss and coordinate changes to the Ethereum Consensus Layer (CL), also known as the beacon chain. This week's meeting was hosted by Alex Stokes, a researcher at the Ethereum Foundation (EF). Developers discussed the following:

· Launch of Pectra Devnet 1

· Changes to the beacon block body and engine API structure

· Incorporation of stable container Ethereum Improvement Proposals (EIPs) into Pectra, namely EIP 7688 and EIP 7495

· Updates to PeerDAS and its timeline for implementation on mainnet

Pectra Devnet 1 Pectra

Devnet 1 went live on Tuesday, July 23. However, the network was not stable. Parithosh Jayanthi, a development operations engineer at the Ethereum Foundation, said that the Erigon client encountered problems shortly after the devnet was launched. Then, an EIP 7702 transaction broadcast on the devnet caused the network to split into three states. Developers are debugging the client and resolving the chain split issue.

Introducing "ExecutionPayloadEnvelope"

Prysm developer Potuz proposed a major improvement to the structure of the execution payload of the beacon chain block, as well as corresponding adjustments to the engine API. This proposal aims to simplify the process of storing and processing state transition data by consensus layer (CL) clients. With the implementation of the Pectra upgrade, CL clients need to access specific parts of the execution payload to correctly perform state transitions. However, the existing design causes these clients to ignore some non-essential information in the execution payload.

The Pectra upgrade will require CL clients to either request necessary state transition data from the execution layer (EL) or store key parts of the block locally. In order to improve the efficiency of CL clients after the Pectra upgrade, Potuz proposed introducing a new structure called "binded_execution_payload_envelope" to centrally store key information required to execute state transitions. Such improvements will significantly improve the speed and efficiency of CL clients when calculating state transitions. He also stressed that these adjustments will ensure compatibility with future network upgrades such as the Simple Serialization (SSZ) format.

Lighthouse developer Mark Mackey warned that if these changes are not implemented, the performance of CL clients on the Pectra testnet may be affected. Teku developer Mikhail Kalinin expressed caution, questioning whether it is really necessary to change the protocol to solve the complexity of EIPs implementation in Pectra. Potuz insisted that there are fundamental problems with the existing protocol design that need to be corrected. He pointed out: "The current design is flawed in concept, mixing data that is critical to CL state transitions with completely unrelated data at the same level and in the same message. Therefore, I think the current design is wrong and we are working hard to correct this mistake."

Stokes encouraged developers to continue discussing this proposal on GitHub .

Engine API Updates for Devnet 2

Related to the above discussion, Geth developer "Lightclient" proposed another change to the engine API. This change is intended to make block transitions easier for EL clients. EL clients determine block versions by interpreting empty and null fields in blocks. However, due to Prague's EIP 7685, EL clients will not be able to distinguish block versions based on these fields without a fork schedule. In order to avoid the overhead of referencing schedules for past upgrades, Lightclient proposes to unify all requests into a single type in the engine API, which EL can pass to CL for interpretation.

Lightclient noted that the interpretation of blocks differs between EL and CL, and that CL is better suited to represent the request data in this case. "When we're dealing with blocks themselves, blocks don't have the concept of, 'This is a Bellatrix block.', like on CL. I think you guys did a good job of distinguishing between different types of forked blocks. But on EL, and I think that's how almost all clients are implemented, we have one block representing all block types, and we use the presence of, like, a null value for a value, to determine if that [fork] is active or not."

Nimbus developer "Dustin" objected to the proposal, saying that Lightclient's proposal doesn't adequately address the complexity of block interpretation on EL and CL. "It just moves complexity and confusion from EL to CL, and both places are viable. Moving it to CL doesn't solve the problem. ... It just moves the problem," Dustin said.

Stokes asserted that CL is better suited to handling requested interpretations, and suggested that developers take a closer look at the engine API changes proposed by Potuz and Lightclient on GitHub.

EIPs 7688 and 7495 in Pectra

Nimbus developer Etan Kissling has been pushing for an update to the Ethereum serialization method to SSZ. For the purposes of Pectra, he identified two intermediate EIPs, 7688 and 7495, to introduce data structures that smart contract developers can rely on to be compatible with future SSZ-related changes. Kissling noted that he has received support from liquid staking pools like Rocketpool, as well as other client teams like Teku and Lodestar.

Stokes warned the CL client team against adding new EIPs to Pectra. "Pectra is already very large, especially if we end up having PeerDAS in the fork. At some point, we need to be very realistic about the size of the fork and the risks it poses. Again, I agree with the reasons Etan gave for this feature being valuable in a vacuum, but I think this is one of the largest hard forks we've ever done, or the largest, and that shouldn't be taken lightly," he said.

Developers have raised some concerns about when these EIPs can actually be added to the Pectra devnet, as Pectra devnets have yet to incorporate many EIPs, such as PeerDAS and EOF. In response, Jayanthi suggested first making a clear decision on whether developers should include these EIPs in the upgrade. Jayanthi also warned of bottlenecks when testing the CL and EL EIPs together on a devnet. “10 direct EIPs shipping together makes it very complicated to test the forks in combination,” he wrote in the Zoom chat. “And we don’t just have direct EIPs.”

Mackey shared that application developers like the EigenLayer team are trying to figure out what is scheduled for activation in Pectra, and the continued lack of clarity on these two EIPs is a hindrance to their work. Lighthouse developer Sean Anderson suggested getting more input from application developers on Ethereum on these EIPs to determine how critical they are to the application.

Stokes suggested revisiting this discussion later so that developers can focus on resolving issues with Pectra Devnet 1.

PeerDAS Updates

Developers had an in-depth discussion on the latest progress of PeerDAS. Anderson reported that the consensus layer (CL) client team is actively fixing issues found in the previous round of PeerDAS devnets and ensuring the stability of the implementation before launching a new devnet. Gajinder Singh, developer of Lodestar and EthereumJS, said that based on feedback from a recent PeerDAS implementer meeting, the community is interested in integrating PeerDAS in the next Pectra devnet.

Stokes suggested that based on discussions with the Ethereum Foundation (EF) research team and other developers, the sampling function may need to be omitted when initially activating PeerDAS on the mainnet to reduce the complexity of the implementation. He explained that a full implementation of PeerDAS involves three key functions: distribution, sampling, and reconstruction. "Currently, the PeerDAS specification in Pectra covers all three of these tasks. My gut feeling is that the sampling functionality may be the biggest complexity point in the implementation. If sampling does present an insurmountable challenge, we could consider increasing the number of blobs in Pectra while reducing or adjusting the scope of PeerDAS," Stokes explained.

Stokes promised that he would develop a formal proposal for this idea and discuss it further with the developer community. Singh supported this. Stokes also suggested that PeerDAS be formally included in the Pectra upgrade. Jayanthi asked if this meant redefining the PeerDAS specification on top of the Pectra specification, noting that merging the PeerDAS and Pectra devnets could complicate debugging efforts as neither was stable. He suggested that the two workstreams should remain independent until the specifications are stable. Enrico Del Fante, a developer at Teku, agreed with Jayanthi.

Stokes noted that many developers working on PeerDAS implementations were unable to attend the meeting. He proposed that the discussion of future steps for PeerDAS continue at the next PeerDAS implementers meeting.

Add BeaconBlocksByRange V3

Lighthouse developer “Dapplion” proposed an improvement to help clients more efficiently sync to the main chain in the event of a long chain split. He pointed out that the existing [BeaconBlocksByRange V2] RPC protocol has certain limitations: “When you need to sync a long forked block and you are not sure which branch is the main chain, according to the current protocol, you only need to submit a slot range and the node will return the block it thinks is correct. Although you can query this information through status messages, this process is asynchronous and may cause some problems. Although there are no serious forks on the mainnet yet, if similar events occur in the future, this will be a problem that needs to be solved.”

Dapplion further explained that his proposed solution is relatively simple and may even be included in the upcoming Pectra upgrade. Although these improvements are not imminent, Stokes encouraged developers attending the meeting to carefully review the proposal and share their thoughts and suggestions on GitHub .

「 original link 」

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

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

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

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