Summary of the latest meeting of Ethereum core developers: Discussion on the launch of the Pectra upgrade and progress on the PeerDAS implementation

Original Title: 《Ethereum All Core Developers Consensus Call #138 Writeup》
Author: Christine Kim
Compiled by: Ladyfinger, BlockBeats

Editor’s Note:
The Ethereum All Core Developers Consensus Call (ACDC) is held bi-weekly to discuss and coordinate changes to the Ethereum Consensus Layer (CL). This is the 138th ACDC call, covering multiple topics including the launch of Pectra Devnet 1, changes to the beacon block body and engine API structure, the incorporation of stable container Ethereum Improvement Proposals (EIPs) into Pectra, namely EIP 7688 and EIP 7495, as well as updates on PeerDAS. During the meeting, developers reviewed the readiness for the Pectra upgrade and discussed some unresolved issues and proposals regarding the implementation of PeerDAS. Additionally, Nimbus developer Etan Kissling shared progress on the implementation of EIP 7688 and EIP 7495, highlighting the importance of these proposals for upgrading Ethereum's data serialization methods. Christine Kim, Vice President of Research at Galaxy Digital, took detailed notes on the key points of the meeting, which BlockBeats has compiled as follows:

On July 25, 2024, Ethereum developers held the 138th All Core Developers Consensus (ACDC) meeting via Zoom. ACDC meetings are a series 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 Ethereum Foundation (EF) researcher Alex Stokes. Developers discussed the following topics:

• 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 on PeerDAS and its implementation timeline on the mainnet

Pectra Devnet 1

Pectra Devnet 1 went live on Tuesday, July 23. However, the network is unstable. Ethereum Foundation DevOps engineer Parithosh Jayanthi reported that the Erigon client encountered issues shortly after the devnet launch. Subsequently, an EIP 7702 transaction broadcasted on the devnet caused the network to split into three states. Developers are debugging the client and addressing the chain split issue.

Introduction of ExecutionPayloadEnvelope

Prysm developer Potuz proposed significant improvements to the execution payload structure of beacon chain blocks, along with corresponding adjustments to the engine API. This proposal aims to simplify the process for CL clients to store and process state transition data. With the implementation of the Pectra upgrade, CL clients will need to access specific parts of the execution payload to correctly execute state transitions. However, the existing design causes these clients to overlook some non-essential information in the execution payload.

The Pectra upgrade will require CL clients to either request the necessary state transition data from the execution layer (EL) or locally store key parts of the block. To enhance the efficiency of CL clients post-Pectra upgrade, Potuz suggested introducing a new structure called "bindedexecutionpayload_envelope" to centrally store the key information required for executing state transitions. Such improvements would significantly enhance the speed and efficiency of CL clients when computing state transitions. He also emphasized that these adjustments would ensure compatibility with future network upgrades, such as the Simple Serialization (SSZ) format.

Lighthouse project developer Mark Mackey warned that without implementing these changes, the performance of CL clients on the Pectra testnet may be affected. Teku project developer Mikhail Kalinin expressed caution, questioning whether it is truly necessary to address the complexity of EIPs implementation in Pectra by changing the protocol. Potuz insisted that there are fundamental issues with the existing protocol design that need correction. He stated, "The current design is fundamentally flawed in that it mixes data critical to CL state transitions with completely unrelated data at the same level and in the same message. Therefore, I believe the current design is wrong, and we are working to correct this error."

Stokes encouraged developers to continue discussing this proposal on GitHub.

Engine API Updates for Devnet 2

In relation to the above discussion, Geth developer "Lightclient" proposed another change to the engine API. This change aims to make it easier for EL clients to perform block transitions. EL clients determine block versions by interpreting empty fields within blocks. However, due to EIP 7685 from Prague, EL clients cannot distinguish block versions based on these fields without a fork schedule. To avoid the overhead of referencing past upgrade schedules, Lightclient proposed unifying all requests into a single type within the engine API, which EL can pass to CL for interpretation.

Lightclient noted that the interpretation of blocks differs between EL and CL, and in this case, CL is better suited to represent requested data. "When we are dealing with the block itself, the block has no concept of 'this is a Bellatrix block,' as it does on CL. I think you all do a great job distinguishing different types of forked blocks. But on EL, I think that's how almost all client implementations work; we have a block that represents all block types, and we use existing values, like a null value, to determine whether that [fork] is active."

Nimbus developer "Dustin" opposed this proposal, stating that Lightclient's suggestion does not adequately address the complexity of block interpretation on EL and CL. "This just shifts complexity and confusion from EL to CL, and both places are feasible. Moving it to CL does not solve the problem… it just moves the problem," Dustin said.

Stokes asserted that CL is better suited to handle the interpretation of requests and suggested that developers take a closer look at the engine API changes proposed by Potuz and Lightclient on GitHub.

EIP 7688 and 7495 in Pectra

Nimbus developer Etan Kissling has been advocating for an update to Ethereum's serialization methods 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, compatible with future changes related to SSZ. Kissling noted that he has received support from liquid staking pools like Rocketpool, as well as from other client teams such as Teku and Lodestar.

Stokes warned CL client teams against adding new EIPs to Pectra. "Pectra is already quite large, especially if we ultimately have PeerDAS in the fork. At some point, we need to realistically assess the size of the fork and the risks it brings. Again, I agree with the value of the functionality Etan presents in a vacuum, but I think this is one of the largest hard forks we've done, if not the largest, and it should not be taken lightly," he said.

Developers expressed concerns about when these EIPs could actually be added to Pectra devnet, as many EIPs, such as PeerDAS and EOF, have not yet been incorporated into Pectra devnets. In response, Jayanthi suggested first clarifying whether developers should include these EIPs in the upgrade. Jayanthi also warned of bottlenecks when testing CL and EL EIPs together on a single devnet. He wrote in the Zoom chat, "Shipping 10 direct EIPs together will make testing the fork in combination very complex. And we not only have direct EIPs."

Mackey shared that application developers like the EigenLayer team are trying to figure out what is planned for activation in Pectra, and the ongoing lack of clarity around these two EIPs is a barrier to their work. Lighthouse developer Sean Anderson suggested gathering more feedback from application developers on Ethereum regarding how critical these EIPs are to their applications.

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

PeerDAS Updates

Developers engaged in an in-depth discussion about the latest progress on PeerDAS. Anderson reported that the CL client teams are actively fixing issues discovered in the previous round of PeerDAS devnet and ensuring the stability of the implementation before launching a new devnet. Developers from Lodestar and EthereumJS, Gajinder Singh, indicated that based on feedback from the recent PeerDAS implementers meeting, the community is interested in integrating PeerDAS into the next Pectra devnet.

Stokes proposed that, based on discussions with the Ethereum Foundation (EF) research team and other developers, it may be necessary to omit the sampling feature when initially activating PeerDAS on the mainnet to reduce implementation complexity. He explained that the full implementation of PeerDAS involves three key functions: distribution, sampling, and reconstruction. "Currently, the specifications for PeerDAS in Pectra cover all three tasks. My intuition tells me that the sampling function may be the biggest complexity point in the implementation process. If sampling indeed poses insurmountable challenges, we could consider increasing the number of blobs in Pectra while reducing or adjusting the scope of PeerDAS," Stokes explained.

Stokes committed to drafting a formal proposal on this idea and further discussing it with the developer community. Singh expressed support for this. Stokes also suggested formally incorporating PeerDAS into the Pectra upgrade. In response, Jayanthi asked whether this meant redefining the PeerDAS specification based on the Pectra specification, noting that merging PeerDAS and Pectra devnets could complicate debugging work due to both being unstable. He suggested maintaining the independence of the two workflows until the specifications stabilize. Teku developer Enrico Del Fante also agreed with Jayanthi's view.

Stokes noted that many developers focused on PeerDAS implementation were unable to attend this meeting. He proposed continuing to explore the future steps for PeerDAS at the next PeerDAS implementers meeting.

Adding BeaconBlocksByRange V3

Lighthouse project developer "Dapplion" proposed an improvement aimed at helping clients synchronize more effectively to the main chain in the event of prolonged chain splits. He pointed out that the existing [BeaconBlocksByRange V2] RPC protocol has certain limitations: "When you need to synchronize a long fork's blocks and are unsure which branch is the main chain, according to the current protocol, you simply submit a slot range, and the node will return what it believes to be the correct block. Although you can query this information through state messages, this process has asynchronicity and may lead to some issues. While there have not yet been serious fork situations on the mainnet, if similar events occur in the future, this will be a problem that needs to be addressed."

Dapplion further explained that his proposed solution is relatively simple and could even be incorporated into the upcoming Pectra upgrade. Although these improvements are not urgent, Stokes encouraged the attending developers to carefully review this proposal and share their thoughts and suggestions on GitHub.