Original Title: "Ethereum All Core Developers Consensus Call #138 Writeup"
Author: Christine Kim
Translation: Ladyfinger, BlockBeats

Editor's Note:
The Ethereum All Core Developers Consensus Call (ACDC) is held every two weeks to mainly discuss and coordinate changes to the Ethereum consensus layer (CL). This 138th ACDC call covered the launch of Pectra Devnet 1, changes to the beacon block body and engine API structure, inclusion of stable container Ethereum Improvement Proposals (EIPs) in Pectra, namely EIP 7688 and EIP 7495, and updates on PeerDAS, among other topics. During the meeting, developers reviewed the preparation for the Pectra upgrade and discussed unresolved issues and proposals regarding the implementation of PeerDAS. In addition, Etan Kissling, a developer from Nimbus, shared the progress of implementing EIP 7688 and EIP 7495, emphasizing the importance of these proposals for upgrading Ethereum's data serialization method. Christine Kim, Vice President of Research at Galaxy Digital, detailed the key points of this meeting, which BlockBeats has translated as follows:

On July 25, 2024, Ethereum developers held the 138th All Core Developers Consensus (ACDC) call via Zoom. The ACDC meeting is a bi-weekly series 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
• Inclusion of stable container Ethereum Improvement Proposals (EIPs) in 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 was unstable. Parithosh Jayanthi, a development operations engineer at the Ethereum Foundation, stated that the Erigon client encountered issues shortly after the devnet launch. Subsequently, a transaction of EIP 7702 broadcasted on the devnet led to the network splitting into three states. Developers are debugging the client and resolving the chain split issue.

Introducing "ExecutionPayloadEnvelope"

Prysm developer Potuz proposed a significant improvement to the structure of the beacon chain block execution payload and corresponding adjustments to the engine API. This proposal aims to simplify the process of CL client storage and processing of state transition data. With the implementation of the Pectra upgrade, CL clients need to access specific parts of the execution payload to correctly execute state transitions. However, the existing design causes these clients to overlook some unnecessary 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. To enhance the efficiency of CL clients after the Pectra upgrade, Potuz suggested introducing a new structure called "bindedexecutionpayload_envelope" to centrally store the key information required for executing state transitions. Such improvements will significantly enhance the speed and efficiency of CL clients in computing state transitions. He also emphasized that these adjustments will ensure compatibility with future network upgrades, such as the Simple Serialization (SSZ) format.

Mark Mackey, a developer of the Lighthouse project, raised a warning that if these changes are not implemented, the performance of CL clients on the Pectra testnet may be affected. Mikhail Kalinin, a developer of the Teku project, expressed caution, questioning the necessity of changing the protocol to address the complexity of EIPs implementation in Pectra. Potuz insisted that the existing protocol design has fundamental flaws that need to be corrected. He pointed out, "The current design is fundamentally flawed in concept, mixing data critical to CL state transitions with completely irrelevant data at the same level, in the same message. Therefore, I believe the current design is wrong, and we are working to correct this mistake."

Stokes encouraged developers to continue discussing this proposal on GitHub.

Engine API Updates for Devnet 2

In connection with 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 the block version by interpreting empty fields and empty fields in the block. However, due to Prague's EIP 7685, without a fork schedule, EL clients will be unable to distinguish block versions based on these fields. To avoid the overhead of referencing past upgrade schedules, Lightclient proposed unifying all requests into a single type in the engine API, which EL can pass to CL for interpretation.

Lightclient pointed out that block interpretation differs between EL and CL, and in this case, CL is better suited to represent request data. "When we're dealing with the block itself, the block doesn't have a concept, 'This is a Bellatrix block,' just like on CL. I think you've done a great job in distinguishing different types of fork blocks. But on EL, I think this is almost the way all client implementations work, we have one block representing all block types, and we use the existing, like a value's null value, to determine whether that [fork] is active."

Nimbus developer "Dustin" opposed this proposal, stating that Lightclient's proposal did not adequately address the complexity of block interpretation on EL and CL. "This just moves 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 request interpretation and suggested that developers carefully review 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 the update of Ethereum's serialization method to SSZ. For the purpose of Pectra, he has identified two intermediate EIPs, 7688 and 7495, to introduce data structures that smart contract developers can rely on and to be compatible with future SSZ-related changes. Kissling noted that he has received support from liquidity staking pools like Rocketpool, as well as other client teams such as Teku and Lodestar.

Stokes warned the CL client teams not to add new EIPs in Pectra. "Pectra is already very large, especially if we end up with PeerDAS in the fork. At some point, we need to be very realistic about the size of the fork and the risks it brings. Again, I agree with the value proposition of this feature in a vacuum as Etan has given, but I think this is one of the largest hard forks we've done, or the largest, and it should not be taken lightly," he said.

Developers expressed concerns about when these EIPs can actually be added to the Pectra devnet, as many EIPs such as PeerDAS and EOF have not yet been included in the Pectra devnets. 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 CL and EL EIPs together on a devnet. He wrote in the Zoom chat, "Shipping 10 direct EIPs together makes testing in combination in the fork very complex. And we don't just have direct EIPs."

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

Stokes suggested revisiting this discussion later to allow developers to focus on addressing the issues with Pectra Devnet 1.

PeerDAS Update

Developers had an in-depth discussion on the latest progress of PeerDAS. Anderson reported that the consensus layer (CL) client teams are actively fixing issues found in the previous round of PeerDAS on the devnet and ensuring the stability of the implementation before launching a new devnet. Gajinder Singh, a developer from Lodestar and EthereumJS, stated that based on feedback from the recent PeerDAS implementers' meeting, the community intends to integrate PeerDAS in 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 activating PeerDAS on the mainnet to reduce the complexity of the implementation. He explained that the complete implementation of PeerDAS involves three key functions: distribution, sampling, and rebuilding. "Currently, the specification of PeerDAS in Pectra covers these three tasks. My intuition tells me that the sampling feature may be the biggest complexity in the implementation process. If sampling does indeed pose insurmountable challenges, we can consider increasing the number of blobs in Pectra while reducing or adjusting the scope of PeerDAS," Stokes explained.

Stokes pledged to formalize this idea into a proposal and further discuss it with the developer community. Singh expressed support for this. Stokes also suggested formally including PeerDAS in the Pectra upgrade. In response, Jayanthi inquired whether this means redefining the PeerDAS specification based on the Pectra specification and pointed out that merging PeerDAS and Pectra devnets may complicate debugging due to the instability of both. He suggested maintaining the independence of the two workflows until the specifications are stable. Enrico Del Fante, a developer from Teku, also agreed with Jayanthi's view.

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

Adding BeaconBlocksByRange V3

"Dapplion," a developer from the Lighthouse project, proposed an improvement to help clients synchronize to the main chain more effectively in the event of long chain splits. He pointed out limitations in the existing BeaconBlocksByRange V2 RPC protocol: "When you need to sync a block from a long fork and are unsure which branch is the main chain, according to the current protocol, you just submit a slot range, and the node will return the block it believes is correct. Although you can query this information through state messages, this process is asynchronous and may cause some issues. While there have not been serious fork situations on the mainnet yet, 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 may even be included in the upcoming Pectra upgrade. Although these improvements are not urgent, Stokes encouraged attending developers to carefully review this proposal and share their opinions and suggestions on GitHub.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。