Ethereum All Core Developers Consensus Call #130 Writeup
On March 21, 2024, Ethereum developers gathered over Zoom for All Core Developers Consensus (ACDC) call #130. Chaired by Ethereum Foundation (EF) Researcher Danny Ryan, the ACDC calls are a bi-weekly meeting series where developers discuss and coordinate changes to the consensus layer (CL) of Ethereum. This week, developers discussed outstanding action items related to the Dencun upgrade, proposals for the Pectra upgrade, and improvements to Ethereum’s networking layer. Developers agreed to include EIP 7251, Increase the MAX_EFFECTIVE_Balance, in Pectra and continue scoping out EIP 7547, Inclusion lists, for potential inclusion in the upgrade as well.
Dencun Action Items
Trenton Van Epps, a community coordinator employed by the Ethereum Foundation, shared that a compilation of sentiments from Ethereum protocol developers about the years of development leading up to Dencun upgrade has been published on Mirror. Called the “Dencun Diary”, the compilation features the voices of over 45 Ethereum developers and their perspectives on both the successes and challenges preparing Dencun.
“I think it's a really useful resource. If you people have been around, you'll know that I've done this for the Merge [upgrade] and also for the Beacon Chain launch. So, just adding to that collection of historic records. Hopefully, we're starting to build institutional memory of how [Ethereum core developers] and how the community around it works. So, thanks everybody who submitted. I think it's a really nice snapshot of sentiment and hopefully, we're learning as we go,” said Van Epps about the project.
He also said that it is not too late for Ethereum developers who had contributed to the Dencun upgrade to get their submissions added to the Dencun Diary and to reach out to him directly if they wanted to add their thoughts to the compilation.
Then, Ethereum Foundation Protocol Support Lead Tim Beiko gave a call-out to all Dencun EIP authors, asking that they update their proposals on GitHub with a status of “Final” to indicate that their code changes are now live on Ethereum mainnet. The full list of EIPs needing this status update can be found here.
About the impact of the upgrade on Ethereum, Prysm developer Terence Tsao mentioned that he is noticing an uptick in the number of reorged blocks, meaning blocks that are proposed on the network but not included in the canonical chain of Ethereum blocks. Tsao said that he is doing further investigation into the reason for this behavior and that he presumes the reason has something to do with MEV builder specifications.
Ethereum Foundation Developer Operations Engineer Parithosh Jayanthi said that from his team’s analysis of Dencun, they are noticing that a small number of blobs are arriving on the network delayed, four seconds into a slot. Slots are 12 second intervals in which validators are selected to propose blocks on Ethereum. While the number of slow-arriving blobs is not high, Jayanthi said it is important to keep an eye on this behavior. Prysm developer “Potuz” mentioned that one of the changes to attestation inclusion timeline in the upgrade may be exacerbating metrics tracking resource usage by nodes. Teku developer Enrico Del Fante said that his team is aware of these issues regarding higher-than-normal CPU and bandwidth usage and will have a fix for this included in the next release of the Teku client.
Finally, Lodestar developer Gajinder Singh surfaced a minor renaming change for the opcode “BLOBBASEFEE” to “BLOBBASEFEEPERGAS.” Singh said, “[This is] basically to make sure that the unit is more aligned with what it conveys.” Ryan encouraged developers on the call, especially EIP 4844 authors, the authors of the proposal introducing blobs, to review Singh’s change.
Censorship Resistance Code Changes
Ethereum Foundation Security Researcher Fredrik Svantes shared a proposal to boost the value of locally built blocks by 10% in client implementations of the “get_Payload” request. As background, developers added calculations for the block value in the Engine API through the “get_Payload” request in late 2022. This was so that validators could easily compare the value of a locally built block with the value of a block built by a third-party block builder. According to Svantes, 64% of builders are actively censoring transactions from blocks. To encourage validators to propose locally built blocks, Svantes proposed boosting the value of local blocks by 10%. He added that he is working with the testing team at the Ethereum Foundation to ensure that these changes do not trigger any false alarms when testing client software or break existing testing infrastructure.
Potuz pushed back on Svantes’ suggestion, saying that the block value should be up to clients to configure. “We should stop specifying these kinds of things. We should stop doing this in a coordinated fashion,” said Potuz, adding, “I think clients should be free of setting these kinds of things however they want. They’re configurable by the users, and we should be less afraid of actually acting on this in our beliefs.” Other developers on the call including Lodestar developer Phil Ngo and Lighthouse developer “Sean” agreed with Potuz.
“A reason not to set it to 10% for example would be that it would be kind of an unexpected deal and it’s kind of like taking advantage of the fact that the user might not be aware of this feature, whereas like a better approach, something maybe in Lighthouse would be this, would be to like require a user to set that value if they’re using a builder. So, it raises awareness of the flag without giving an opinion towards where it should be,” said Sean.
Developers then discussed what margin would encourage validators to choose a local block as opposed to a block built by a builder. Due to limited time on the call, Ryan recommended moving on to the other meeting agenda items.
Pectra Code Changes
Ryan kicked off the discussion on major code changes to include in Electra, highlighting the two foremost proposals, EIP 7251 and EIP 7547, in the running for inclusion. “We've gone back and forth. We've thought one or the other was buried, and they've resurfaced at various times, but we're definitely at the point where if we're not making decision, we really need to be making a decision soon. There is the intention to have functional prototypes and devnets of Electra at some point in May and we're closing at the end of March. So, I just want to contextualize that these are medium, if not large items, that we can continue to discuss [but] we can't continue to kick the can down the curve for too much longer. Otherwise, I think the default just becomes ‘no’. I guess indecision is a decision,” said Ryan.
Inclusion Lists
With that, Ryan gave the floor to Ethereum Foundation Research Mike Neuder, who is leading the efforts on preparing EIP 7547, inclusion lists (ILs), for Pectra. Neuder shared updates from the most recent breakout meeting on ILs. A summary of that meeting can be here. Singh, Sean, and others on the call shared their support for including both ILs and EIP 7251, also known as MaxEB, in Pectra. One of the outstanding concerns about IL specifications as shared by Potuz was its impact on enshrined account abstraction (AA). In the future, Ethereum developers plan on introducing enhanced flexibility to user controlled Ethereum accounts, also called externally owned accounts (EOAs), and the current design of ILs may complicate this process. Developers discussed ways to update the IL specifications such that it can be more compatible with future AA code changes. Developers also discussed their initial work to try and implement ILs in their clients and the tradeoffs between certain uses of the Engine API over others. Rather than discuss the technical details of ILs on the call, Neuder and Terence recommended addressing issues related to IL specifications at the next IL breakout meeting.
MaxEB
Developers also discussed the readiness of MaxEB for implementation in Pectra. Ngo shared updates from the latest MaxEB breakout meeting, which was hosted on Wednesday, March 20. A summary of this meeting can be found here. Lighthouse developer “ethDreamer” said that his team would prefer to prioritize MaxEB over inclusion lists but are also open to including both in Pectra. Based on his colleague’s evaluation of MaxEB, Potuz said that the Prysm team is confident that MaxEB can be implemented by the end of the year, which is the timeframe under which developers are trying to deliver the Pectra upgrade.
Ryan reminded developers on the call that in parallel to the Pectra upgrade, they have already committed to working on peerDAS, which is a code change focused on safely increasing the data availability capacity of Ethereum by introducing data availability sampling and raising the number of blobs per block. “My intuition is that one of MaxEB or IL going into Electra probably does not greatly detract from the parallelization of being able to do peerDAS R&D, but that in the event there are both, that we're now beginning to trade off and probably not really being able to tackle all those three things in parallel once,” said Ryan.
Nonetheless, developers on the call such as Sean, Singh, Ngo, Lighthouse developer Age Manning and others expressed their support for including both maxEB and ILs in Pectra. Potuz was strongly opposed to including both if developers were still aiming to deliver Pectra on mainnet before the end of the year. On the topic of ILs, Ryan asked whether its implementation also posed a heavy workload on EL client teams. Geth developer “Lightclient” said that from his view the workload to implement ILs was an 80/20 split between CL/EL client teams. After more discussion between developers on these two code changes, Beiko recommended moving forward with including maxEB in Pectra, whilst continuing to scope out ILs for potential inclusion in the upgrade after further discussion among both EL and CL client teams. This would mean that developers prioritize maxEB over ILs. Ultimately, developers agreed to move forward with Beiko’s strategy to include maxEB in Pectra and re-discuss ILs in one to four weeks.
“I personally believe that these two things together, we've entered into a much more complex space than we have been discussing [for the upgrade] over the past couple months. So just do so knowingly. I’ll also say at this point in the process, we're also always very confident and excited to take on complexity and that there's a lot of work to do,” said Ryan as a final word of warning regarding the scope of Pectra. As mentioned in ACDC #129, Ryan will be going on a hiatus for three months after this week’s meeting. Ethereum Foundation Researcher Alex Stokes will be chairing the ACDC calls in his place while Ryan is out.
Blob Gas Increase
After the discussion on maxEB and ILs, developers discussed a draft proposal by Ethereum Foundation Researcher Ansgar Dietrichs to increase incrementally the blob count to a maximum of 16 blobs per block from 6 over a four-month period after the Pectra upgrade. The increase would further reduce the cost of data availability and the costs of Layer-2 rollups built on Ethereum. Ryan expressed his support for the proposal assuming three key conditions:
Robust data on the performance of blobs.
Activation of EIP 7623, which limits the maximum block size, in Pectra.
Further discussion on the exact mechanisms for a time-based increase to blob count.
Ryan encouraged developers to chime in with their thoughts on this proposal over the coming weeks.
Light Client Development
Nimbus developer Etan Kissling shared two draft proposals related to light client development impacting CL specifications. Sync committee slashing and light client data backfill are two components to the light client roadmap that developers are working on in parallel to the Pectra upgrade. Kissling asked for input from CL client teams on these components, in particular the impact that maxEB would have on slashing conditions for large validators participating in sync committees. For background on sync committees, read this post by the Ethereum Foundation.
Networking Updates
On the topic of ongoing research items, Manning shared a new approach to attestation subnets (attnets), which is the networking layer enabling validators to send and receive attestations. While not urgent for implementation now, the backwards-compatible proposal appears to offer optimizations for networking once peerDAS takes effect.
Manning also raised the implementation of a new control message to networking peers that would “significantly reduce” node bandwidth. Manning said his team is starting to test the “IDONTWANT” control message already and can release it independently but would need the coordination of the entire network to start seeing the benefits of this change. He requested developers on the call to review the proposal and see if they would consider releasing the change together.
Finally, Manning surfaced the deprecation of mplex in the libp2p library. Mplex is a stream multiplexer, which is a tool to send multiple streams of data over one communication link. Because of the deprecation of mplex, Manning said his team and others client teams are upgrading to a different stream multiplexer called yamux. Manning asked client teams on the status of their migration and whether any are still using mplex. Representatives from the Teku and Lodestar teams said that they were working on their yamux implementations but not ready yet to switch over from mplex.
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.