Ethereum All Core Developers Consensus Call #134 Writeup
On May 30, 2024, Ethereum developers gathered over Zoom for All Core Developers Consensus (ACDC) call #134. 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 learnings and outstanding issues from the launch of Pectra Devnet 0. They also debated expanding the scope of the Pectra upgrade to include peerDAS and SSZ container code changes.
Devnet 0 Recap
Based on the launch of Pectra on Devnet 0, client teams have agreed to keep attestation behavior impacted by EIP 7549 unchanged during hard fork activation. On a prior ACD call, developers had weighed multiple options to ensure that the impact of EIP 7549 during the fork does not lead to a large number of invalid attestations. Rather than pursue any of these options and complicate the upgrade further, client teams have decided on activating EIP 7549 on the same epoch as the other Pectra EIPs without changing attestation behavior before or after the fork.
On the topic of EIP 7251, developers remain uncertain about whether staked ETH consolidations should be triggerable from the execution layer (EL). This would be an ideal feature for staking pools like Lido so that consolidations of stake do not have to depend on node operators but rather can be triggered through smart contracts. Stokes recommended checking in on the progress of client implementations for validator stake consolidation in a few weeks and then determining whether they should be EL or CL operations.
Then, developers discussed open questions about validator deposit finalization under EIP 6110. Teku developer Mikhail Kalinin summarized the path forward for these issues in a GitHub comment prior to the call. Lighthouse developer “sean” raised a question about version control for the “GetPayloadBodies” request in the Engine API. Stokes recommended that developers chime in with their thoughts in the pull request created for this issue on GitHub.
EIP 7549 Changes
Nimbus developer Etan Kissling recommended a slight change to the implementation of EIP 7549. “It's about stability for generalized indexes. So, when we add a new field in the middle of a container, it means that the subsequent fields get assigned a new index, which breaks proofs based on EIP 4788 in the EL and it's also a bit misleading. … That's why I suggested to move the new field to the end to avoid both of these problems,” explained Kissling. There was no opposition to the change. Stokes recommended developers review Kissling’s proposed pull request on GitHub.
Another change to EIP 7549 that was raised on the call was to design the request and other EL triggered requests as a sidecar to EL blocks. About the change, Kalinin said, “In my opinion, it's a really quite nice design solution, which simplifies the EL … and this is basically an alternative to generalizing requests in the execution layer block.” Stokes recommended revisiting this topic on the next CL call once developers have had more time to review the proposal on GitHub.
Pectra Scope Discussion
There are a few CL-focused EIPs that have not been formally included or excluded from the Pectra upgrade. Developers weighed the addition of EIP 7688 and PeerDAS in Pectra on this week’s call. EIP 7688 adopts part of the “StableContainer” SSZ data structure to ensure that there is forward compatibility for the changes introduced by EIP 7549 to attestations. As background, SSZ is a data structure used in the CL that developers want to utilize in the EL. For more information about the SSZ transformation, read prior call notes. PeerDAS is the implementation of data availability sampling on Ethereum that is expected to greatly enhance the network’s ability to support rollups and their data availability needs. Practically speaking, PeerDAS is expected to increase the number of blob transactions validators can attach to a block from 3 blobs per block to 64 or more.
EF Developer Operations Engineer Barnabas Busa said that developers have already launched an early iteration of PeerDAS on a devnet. “I think lots of clients have discovered lots of issues and we could potentially re-launch [a new devnet] anytime when we have something substantial,” said Busa. Stokes asked whether developers were comfortable adding PeerDAS to Pectra even if this would mean the upgrade becomes delayed.
A developer with the screen name “Nishant” resurfaced the proposal of potentially decoupling PeerDAS activation from the activation of the other EIPs already included in Pectra. While this is possible, another developer with the screen name “atd” emphasized that users would have to upgrade their software for both upgrades at the same time anyways if developers plan on activating one upgrade after another within a short period of time. “I would say that having one fork two months after the other is kind of insane. If we're going to coordinate everybody upgrading their clients, we don't want to coordinate everybody upgrading the clients, again, two months down the line. That's like, not enough time to even you know, go through a release cycle,” said atd.
Atd added that in his view PeerDAS is the most “interesting” code change among the EIPs included and being discussed for inclusion in Pectra. Stokes said that in his view, he would want PeerDAS included in Pectra, even if it delays the upgrade. Grandine client developer Saulius Grigaitis proposed removing EIP 7549 and EIP 7688 from Pectra in favor of PeerDAS. This sparked a discussion on the implementation details of EIP 7688. Developers did not reach an agreement about the code change and will re-discuss the proposal on the next ACDC call.
On the topic of PeerDAS, developers continued to weigh the idea of splitting Pectra into two hard forks. EF Developer Options Engineer Parithosh Jayanthi warned that if developers split Pectra into two upgrades, they have to be careful about not overloading the second part of Pectra with more EIPs down the road. “One thing I do want to mention is that if we are thinking about splitting into two forks, we have to be really careful that we don't then just overload the next fork with new EIPs. I have no idea if we're ever going to be able to do that. If we can actually commit to something a year, year and a half in advance, because we're always coming up with new ideas, priorities change, and so on,” said Jayanthi.
Continuing to run with the idea of two upgrades, Lighthouse developer “sean” said that he did not foresee many interdependencies between PeerDAS and the current list of Pectra EIPs. Thus, the two could be worked on separately and easily merged later once developers are more confident about their implementations for both. Atd agreed with this sentiment saying that he did not foresee much risk in combining Pectra EIPs, PeerDAS, and EIP 7688 after more time for developing and testing each of these separately first.
Busa recommended then moving forward with testing Pectra EIPs and PeerDAS together but designing the code changes such that PeerDAS is activated on a later epoch on devnets and testnets than Pectra EIPs. He noted that this is already how testing for Pectra EIPs and PeerDAS is being conducted on Devnet 0. “Nothing really has to change,” said Busa, adding that if PeerDAS is not ready along with other Pectra EIPs, developers can then drop the code change from the upgrade. This prompted several questions about how a different activation epoch for PeerDAS would impact client teams’ work. Ultimately, developers agreed to try moving forward with building out PeerDAS, along with Pectra EIPs, with the caveat that PeerDAS will activate on devnets and testnets on a different epoch than other EIPs.
As mentioned earlier in this writeup, developers agreed to table the discussion on EIP 7688 inclusion in Pectra for the next ACDC call.
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.