Ethereum All Core Developers Consensus Call #138 Writeup
On July 25, 2024, Ethereum developers gathered over Zoom for All Core Developers Consensus (ACDC) call #138. The ACDC calls are a bi-weekly meeting series where developers discuss and coordinate changes to the consensus layer (CL) of Ethereum, also called the Beacon Chain. This week the call was chaired by Ethereum Foundation (EF) Researcher Alex Stokes. Developers discussed:
the launch of Pectra Devnet 1
changes to the structure of the Beacon block body and the Engine API
the inclusion of stable container Ethereum Improvement Proposals (EIPs) in Pectra, namely EIP 7688 and EIP 7495
updates to PeerDAS and its implementation timeline on mainnet.
Pectra Devnet 1
Pectra Devnet 1 went live on Tuesday, July 23. However, the network is not stable. Parithosh Jayanthi, EF Developer Operations Engineer, said the Erigon client ran into issues early after the devnet launch. Then, an EIP 7702 transaction broadcasted on the devnet caused the network to split into three states. Developers are in the process of debugging clients and resolving the chain split.
Introducing an “ExecutionPayloadEnvelope”
Then, Prysm developer “Potuz” proposed a change to the structure of the execution payload contained within the Beacon block body and a corresponding change to the Engine API. The rationale for these changes is to make it easier for CL clients to store data needed for processing state transitions. With the activation of Pectra, CL clients will need parts of the execution payload to correctly perform the state transition function. However, the way CL clients are designed today, they do not store the execution payload as it contains unnecessary information to progress the Beacon Chain.
The Pectra upgrade will force CL clients to request the payload from the execution layer (EL) for a state transition or save down parts of the block locally. To make state transitions easier for CL clients post-Pectra, Potuz proposed a new structure for Beacon blocks such that the necessary information for a state transition is organized into a “binded_execution_payload_envelope.” This would make computing state transitions for CL clients faster and more efficient. He added that the changes would be forward-compatible with future upgrades such the Simple Serialize (SSZ) conversion. The proposed changes to the Beacon block body also necessitate changes to the Engine API to ensure that the EL can access the information in the envelope to reconstruct the full execution payload and compute block hashes.
Lighthouse developer Mark Mackey noted that the performance degradation in CL clients without these changes would be a problem on future Pectra devnets. Teku developer Mikhail Kalinin was hesitant about the changes, saying that he wasn’t sure if changes to the protocol were necessary to solve the implementation complexity of the EIPs in Pectra. Pushing back on this, Potuz said that the protocol design itself needs fixing. He said, “The current design is just philosophically wrong. The current design mixes in the same level, in the same message, data that is needed on the CL for the state transition that is purely on the CL side with data that is not needed CL at all. So, I would say that the current design is just wrong, and we're trying to fix that mistake.”
Stokes encouraged developers to continue discussing the proposal on GitHub.
Engine API Update for Devnet 2
Related to the discussion above, Geth developer “Lightclient” proposed another change to the Engine API. This one is aimed at making block conversion easier for EL clients. EL clients interpret null and empty fields in a block to determine the block version. However, due to EIP 7685 in Prague, EL clients will not be able to differentiate block versions based on these fields without a fork schedule. To avoid the overhead of referencing a schedule of past upgrades, Lightclient has proposed unifying all requests into a single type in the Engine API that the EL can pass along to the CL for interpretation.
Lightclient noted that the way blocks are interpreted differs between the EL and CL, and that in this case, the CL is better equipped to represent request data. “When we're dealing with the block itself, the block doesn't have the concept of, ‘This is a Bellatrix block.’, like on the CL. I think you guys are very good about separating the different types of fork blocks from each other. But on the EL, I think this is how pretty much all clients have implemented it, we have one block that represents all of the block types, and we use the presence, like the nullness of a value, to determine if that [fork] is active.”
Nimbus developer “Dustin” pushed back on the proposal saying that the complexities of block interpretation on both the EL and CL are not adequately addressed by Lightclient’s proposal. “This is just a move of complexity and messiness from the El to the CL, and it's feasible either place. Moving it into the CL does not solve the problem. … It just moves it,” said Dustin.
Stokes asserted that the CL is better equipped to handle the interpretation of requests and recommended that developers take a closer look at both Potuz’s and Lightclient’s proposed changes to the Engine API on GitHub.
EIP 7688 & 7495 in Pectra
Nimbus developer Etan Kissling has been championing efforts to update the serialization method of Ethereum to SSZ. For the purposes of Pectra, he has scoped out two intermediary EIPs, 7688 and 7495, to introduce data structures that smart contract developers can rely on to be forward-compatible with future SSZ-related changes. Kissling noted that he has gotten the support of liquid staking pools like Rocketpool for these EIPs, as well as support for other client teams like Teku and Lodestar.
Stokes cautioned CL client teams from adding in new EIPs to Pectra. “Pectra is incredibly large already, especially if we end up with PeerDAS in the fork. At a certain point, we do need to be very realistic about how big the fork it and the risk that entails for actually shipping this thing. Again, I agree with the justifications that Etan gave around this feature being valuable in a vacuum but that being said, I think this is the biggest hard fork or one of the biggest that we’ve ever done and that should not be taken lightly,” he said.
There were some concerns raised by developers about when these EIPs could feasibly be added to a Pectra devnet given that Pectra devnets have yet to incorporate many EIPs like PeerDAS and EOF. To this, Jayanthi recommended first clearly deciding on if developers should aim to include these EIPs in the upgrade at all. Jayanthi also warned that there is a bottleneck when it comes to testing CL and EL EIPs together on one devnet. He wrote in the Zoom chat, “10 straightforward EIPs shipped together make for a really complicated fork to test in combination. And we don’t just have straightforward EIPs.”
Mackey shared that app developers like the EigenLayer team are trying to figure out what is scheduled for activation in Pectra and the continued lack of clarity on the inclusion of these two EIPs is a blocker to their work. Lighthouse developer Sean Anderson suggested sourcing more input from app developers on Ethereum about their views on these EIPs to determine how critical they are to apps.
Stokes recommended revisiting this discussion later to allow developers to focus on Pectra Devnet 1.
PeerDAS Updates
Then, developers discussed updates on PeerDAS. Anderson shared that CL client teams are fixing existing bugs identified from the last PeerDAS devnet and stabilizing implementations before attempting another devnet launch. Lodestar and EthereumJS developer Gajinder Singh added that from the last PeerDAS Implementors Call, there is appetite to try including PeerDAS in the next Pectra devnet.
Stokes also shared that based on discussions with his colleagues on the EF research team and others, developers should consider removing sampling from PeerDAS in its initial activation on mainnet due to complexity. He explained that the full implementation of PeerDAS requires three main functions: distribution, sampling, and reconstruction. “So, right now, the way Peerdas is specified in Petra is that it's essentially doing all three of these tasks, distribution, sampling and reconstruction. My intuition is that this middle part sampling is going to be where most of the complexity is … and the idea here is that if sampling does become this hairy implementation concern then we can get to a place where we could very realistically consider increasing blob count with this reduced or modified Peerdas scope in Pectra,” said Stokes.
Stokes said that he would create a formal proposal for this idea and circulate it with developers for further discussion. Singh said that he was in favor of the idea. Stokes also recommended formally including PeerDAS in the Pectra upgrade. Jayanthi asked if this meant rebasing PeerDAS specifications on top of Pectra specifications. Jayanthi noted that merging PeerDAS and Pectra devnets would making debugging efforts hard given that neither of the devnets are in a stable state. Jayanthi recommended keeping the two workflows separate for now until specifications stabilize. Teku developer Enrico Del Fante agreed with Jayanthi’s sentiments.
Stokes noted that many developers focused on implementing PeerDAS were not present on the call. He recommended discussing next steps for PeerDAS on the next PeerDAS Implementors Call.
Add BeaconBlocksByRange V3
Finally, Lighthouse developer “Dapplion” shared a proposal to help clients sync to the canonical chain in the event of an extended chain split. He explained, “There is an issue with the current [BeaconBlocksByRange V2] RPC. If you want to sync in a situation where you want to pull a long fork of blocks from which you don't know which view is considered canonical or not, the current blocks by range route is spec’d in a way that you just submit a range of slots and the node will provide whatever the node considers canonical. You can query that information with a status message, but there is some asynchrony on getting those status messages. … This has not been an issue because we haven't had like crazy forking on mainnet, but if shit hits the fan, this could be an issue.”
Dapplion said that his proposed changes were relatively simple and could even be included in Pectra. However, the changes are not urgent. Stokes encouraged developers on the call to review the proposal and chime in with thoughts on GitHub.
Legal Disclosure:
This document, and the information contained herein, has been provided to you by Galaxy Digital Holdings LP and its affiliates (“Galaxy Digital”) solely for informational purposes. This document may not be reproduced or redistributed in whole or in part, in any format, without the express written approval of Galaxy Digital. Neither the information, nor any opinion contained in this document, constitutes an offer to buy or sell, or a solicitation of an offer to buy or sell, any advisory services, securities, futures, options or other financial instruments or to participate in any advisory services or trading strategy. Nothing contained in this document constitutes investment, legal or tax advice or is an endorsementof any of the digital assets or companies mentioned herein. You should make your own investigations and evaluations of the information herein. Any decisions based on information contained in this document are the sole responsibility of the reader. Certain statements in this document reflect Galaxy Digital’s views, estimates, opinions or predictions (which may be based on proprietary models and assumptions, including, in particular, Galaxy Digital’s views on the current and future market for certain digital assets), and there is no guarantee that these views, estimates, opinions or predictions are currently accurate or that they will be ultimately realized. To the extent these assumptions or models are not correct or circumstances change, the actual performance may vary substantially from, and be less than, the estimates included herein. None of Galaxy Digital nor any of its affiliates, shareholders, partners, members, directors, officers, management, employees or representatives makes any representation or warranty, express or implied, as to the accuracy or completeness of any of the information or any other information (whether communicated in written or oral form) transmitted or made available to you. Each of the aforementioned parties expressly disclaims any and all liability relating to or resulting from the use of this information. Certain information contained herein (including financial information) has been obtained from published and non-published sources. Such information has not been independently verified by Galaxy Digital and, Galaxy Digital, does not assume responsibility for the accuracy of such information. Affiliates of Galaxy Digital may have owned or may own investments in some of the digital assets and protocols discussed in this document. Except where otherwise indicated, the information in this document is based on matters as they exist as of the date of preparation and not as of any future date, and will not be updated or otherwise revised to reflect information that subsequently becomes available, or circumstances existing or changes occurring after the date hereof. This document provides links to other Websites that we think might be of interest to you. Please note that when you click on one of these links, you may be moving to a provider’s website that is not associated with Galaxy Digital. These linked sites and their providers are not controlled by us, and we are not responsible for the contents or the proper operation of any linked site. The inclusion of any link does not imply our endorsement or our adoption of the statements therein. We encourage you to read the terms of use and privacy statements of these linked sites as their policies may differ from ours. The foregoing does not constitute a “research report” as defined by FINRA Rule 2241 or a “debt research report” as defined by FINRA Rule 2242 and was not prepared by Galaxy Digital Partners LLC. For all inquiries, please email [email protected]. ©Copyright Galaxy Digital Holdings LP 2024. All rights reserved.