Ethereum All Core Developers Consensus Call #126 Writeup
On January 23, 2024, Ethereum developers gathered over Zoom for All Core Developers Consensus (ACDC) call #126. Chaired by Ethereum Foundation 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 which code changes to prioritize for the Electra upgrade.
The following Ethereum Improvement Proposals (EIPs) were confirmed for inclusion in Electra:
EIP 6110, Supply validator deposits on chain
EIP 7002, Execution layer triggerable exits
EIP 7549, Move committee index outside attestation
Due to limited time, developers agreed to continue discussions on EIP 7251 (Increase the MAX_EFFECTIVE_BALANCE), EIP 7594 (Peer Data Availability Sampling) and SSZ-related EIPs in the next ACDC meeting. They also agreed not to prioritize EIP 6914 (Reuse validator indices) and EIP 7547 (Inclusion lists) in Electra due to the desire to keep the upgrade narrow in scope and ideally implemented on mainnet by the end of this year.
Deneb Updates
Danny Ryan shared a brief update on the Deneb upgrade. On Wednesday, January 24, the Ethereum Foundation released a blog post containing all the latest client releases for the Deneb upgrade on Sepolia and Holesky. These two test networks will be the last testnets where the Deneb upgrade is activated before Ethereum mainnet. Sepolia is scheduled for Deneb activation on January 30 and Holesky one week thereafter on February 7.
Electra Discussions
The remainder of the call was spent discussing candidate EIPs for the next upgrade after Deneb dubbed Prague/Electra. Prague is the name for the upgrade on the execution layer (EL) of Ethereum, while Electra is the name for the upgrade on the CL. Last week, developers reviewed proposals for Prague, primarily impacting the EL protocol. This week, developers reviewed proposals for Electra, primarily impacting the CL protocol.
EIP 6110: Supply validator deposits on chain
Teku developer Mikhail Kalinin presented EIP 6110 which appends validator deposits to EL blocks. The motivation for this code change is to reduce the complexity of client software design and improve validator UX. Danny Ryan called the EIP “a major security improvement” for Ethereum. Tim Beiko, Protocol Support Lead at the Ethereum Foundation and Chair of the ACDE calls, added that the EIP was one of two CL-focused EIPs that EL client teams have already signaled support for in the Prague/Electra upgrade. EIP 6110, like a few other CL-focused EIPs proposed for Electra, requires protocol-level changes to the EL. Given the support for EIP 6110 from both CL and EL client teams, developers agreed to move forward with inclusion of the code change in Prague/Electra.
EIP 6914: Reuse validator indices
EIP 6914 would enable the index number of fully exited validators to be reassigned to new entering validators. The motivation for this would be to prevent the unbounded growth of the validator index over time. Lighthouse developer “Dapplion” presented the EIP but noted that while this code change is important for the long-term health of Ethereum, it does not need to be prioritized in Electra. Developers agreed not to prioritize EIP 6914 in Electra.
EIP 7002: Execution layer triggerable exits
Danny Ryan shared background on EIP 7002. “There are two [validator] keys. There's the active key and the withdrawal credentials. Active key manages the stake. The withdrawal credentials ultimately own the funds. Since Phase Zero, there's arguably kind of a bug in this relationship in that only the active credentials can trigger exits. So, if the active key is lost, or if there's some sort of more dynamic relationship between who owns the active key and who owns withdrawal credentials, you're going to have pretty degenerate cases and degenerate outcomes.” Ryan elaborated that one of the primary benefits for this EIP is to enable more trustless staking pool designs on Ethereum. As the other CL-focused EIP that EL client teams have expressed support for, CL client teams were keen on including EIP 7002 in Electra. Like EIP 6110, 7002 will require minor changes to be implemented on the EL. Ryan noted that the implementation of this EIP is in the process of being changed from a stateful precompile to EVM bytecode. He made a call for EVM bytecode experts to keep an eye out for the implementation and help review it once drafted by Geth developer “Lightclient”.
EIP 7251: Increase the MAX_EFFECTIVE_BALANCE
Next, Ethereum Foundation Researcher Mike Neuder presented EIP 7251, which increases the maximum effective balance of validators from 32 ETH to 2048 ETH. For background on why this code change is needed, read this Galaxy Research Report on the issue of validator set size growth. Neuder noted that this code change is “more controversial” than others due to its complexity and dependency on other code changes such as EIP 7002. Lighthouse developer “Sean” expressed his support for the EIP but given its complexity recommended looking into ways to implement the changes over multiple hard forks, instead of all-in-one upgrade. Neuder was supportive of the idea. Lodestar developer Gajinder Singh was not in favor of breaking up the implementation of EIP 7251 across more than one fork, due to concerns that this would create more of a headache for developers in the long-term.
One of the largest sources of complexity in EIP 7002 is the in-protocol stake consolidation feature, which would enable existing validator node operators to consolidate their stake from multiple validators with minimal loss in rewards. Based on the design presented by Neuder and his colleagues, validator node operators would only lose rewards for a period of 256 epochs (roughly 27 hours). Neuder said he and his colleagues have already consulted with major staking providers like Lido, Coinbase, and Figment over the design for EIP 7002 and gotten their support for the code change.
Expressing the views of the Prysm team, developer Terence Tsao said they were not in favor of including EIP 7002 in Electra given the desire from EL client teams to execute the Prague/Electra upgrade before the end of the year. “We just think this EIP has too much complexity to fit in a small fork assuming it’s coming October or November,” said Tsao. The full views of the Prysm team on what EIPs should be included in Electra can be read in this blog post. Prysm developer “Potuz” added that in his view there is no “mini version” of EIP 7002 that would significantly reduce its complexity enough to still include it in Electra. “I don’t see how this can be scoped in any form for 2024,” said Potuz about EIP 7002.
However, Potuz also added that if developers were open to scoping out Electra for implementation in 2025, then the Prysm team would offer different priorities for the upgrade and push for inclusion for many other code changes including EIP 7002, but also EIPs related to enshrined proposer builder separation and data availability sampling. “We’re very, very conservative because we know that we haven’t forked ever twice in a year, not in the CL, and I think it’s not realistic to try to put this many EIPs if we’re scoping for this year,” he said. Given the pushback on the inclusion of this code change in Electra, Ryan recommended moving on to the other proposed EIPs for Electra and circling back to EIP 7002 on another call.
EIP 7547: Inclusion lists
EIP 7547 creates a mechanism through which validators can forcibly include certain transactions in a block. The main motivation for this is to improve the censorship resistance of Ethereum. Neuder, who authored the proposal along with several other developers, explained that 67% of block builders are already censoring transactions on Ethereum and over 90% of validators receive blocks from third-party builders. There is a clear need for stronger censorship resistance on Ethereum. However, Neuder noted that there are open design questions on the implementation of forced transaction inclusion lists, primarily regarding the precise conditions that need to be met to enforce the list.
Tsao chimed in saying that the Prysm team has been working on implementing EIP 7547 with enshrined proposer builder separation for the past few months. However, due to the complexity of EIP 7547, he does not view the code change as a good candidate for Electra. Both Sean and Potuz shared concerns over the complexity of the EIP. Singh recommended that client teams work instead on fully implementing the builder override flag functionality, which is a mechanism that will cause validators to revert to local block production if censoring activity is detected on the EL.
Due to the pushback from developers about this code change, Ryan recommended not prioritizing it for the Electra upgrade. Potuz re-emphasized that the Prysm team would be in favor of including EIP 7547 in Electra if developers were to change their expectations on the scope of the fork and its timing for activation on mainnet from 2024 to 2025.
EIP 7549: Move committee index outside attestation
Then, Dapplion shared EIP 7549, which is a code change impacting only the CL. The code change would make the aggregation of consensus votes more efficient and can be implemented in a variety of ways, ranging for low to high complexity. Ethereum Foundation Researcher Dankrad Feist was in favor of choosing the simplest way to implement EIP 7549, which is simply to set the value of a particular data field in CL clients, the “index” field in “AttestationData”, to zero. Danny Ryan was also in favor of this strategy. Developers agreed to move forward with the inclusion of EIP 7549 in its simplest form in Electra.
EIP 7594: Peer Data Availability Sampling (PeerDAS)
Ryan presented EIP 7549, which is a proposal to extend the scale of EIP 4844 beyond a target blob count of 3 blobs per block. The way that developers can scale the data availability of Ethereum is by enabling nodes to sample blob data, as opposed to downloading the full blob. Though the design of EIP 7594 is not complex, its implementation on the networking layer is where the most amount of effort and testing will be needed from client teams. Tsao asked whether the EIP would be coupled with an increase to the target blob count and if not, whether the EIP would require a consensus-level change to implement at all. Ryan confirmed that in its current form, EIP 7594 does not require any consensus changes and could be implemented independent of a hard fork upgrade. However, he said it was an open question over whether EIP 7594 should be paired with an increase to the blob count, which would require a consensus change to update.
Feist chimed in to comment on the demand for blobs from Layer 2 protocols once Deneb is activated. “[The demand] right now is on the order of one blob per block but that has grown by a factor of 10 over the last year,” said Feist, adding, “This will very quickly become an urgent thing because we will run quickly into the regime where rollups will also question why are we using 4844 at all if it’s not cheaper than call data. I think the demand [for blobs] is the smallest worry I have about this. I think that will be very obvious very quickly after 4844.” For background on EIP 4844 and the Deneb upgrade, read this Galaxy Research report.
Dapplion was in favor of prioritizing EIP 7594 in Electra, saying, “I think every EIP has merit, but scaling remains the best investment in terms of time and output. There is a very clear return on investment. So, it seems very unwise to not have this as the top priority.” Lighthouse developer Pawan Dhananjay asked for more information on the efficiency of PeerDAS on the verification of large amounts of blob data and the state of the cryptography libraries for its implementation. Feist said that he would circle back with more information on these topics. Potuz shared concerns again about the scope of the Electra upgrade and the dangers of the upgrade becoming too large for a target activation on mainnet before the end of the year if EIP 7594 is included. “We were under the impression…that we were going to prioritize Verkle in 2025 by scoping [Electra] in 2024. I don’t see how we can do this and Verkle in parallel and ship something like this by this year. That’s the reason why we were not supporting this for this small fork if we scope it for this year,” said Potuz.
Ethereum Foundation DevOps Engineer Parithosh Jayanthi responded to concerns about testing for PeerDAS in parallel with Verkle. Jayanthi said that his team is working on a way to test Verkle reliably through isolated shadow forks that EL clients can launch independently without support from the DevOps team. If this feature can be shipped, then while EL teams are working on the Verkle upgrade, the DevOps team will have more bandwidth to help prioritize testing for PeerDAS in the meantime. Ryan recommended including PeerDAS as a conditional EIP in Electra that CL client teams work on alongside other Electra EIPs and have the freedom to exclude from the upgrade if it delays testing. Developers agreed to table the discussion on PeerDAS until the next ACDC meeting in the interest of time.
SSZ-Related EIPs
Finally, Nimbus developer Etan Kissling presented five EIPs related to SSZ formatting. As background, Kissling is spearheading efforts to update the serialization scheme of Ethereum from RLP to SSZ. These SSZ-related EIPs would help reduce the size of transaction inclusion proofs, reduce protocol complexity stemming from differences in serialization formats between the EL and CL, and introduce greater accuracy to data fields used in EL block headers. The EIPs proposed by Kissling are:
1. EIP-6404: SSZ Transactions Root
2. EIP-6465: SSZ Withdrawals Root
3. EIP-6466: SSZ Receipts Root
4. EIP-6493: SSZ Transaction Signature Scheme
5. EIP-7495: SSZ StableContainer
Each of these EIPs require subsequent changes to the EL. Because of this, Ryan recommended sourcing feedback from EL client teams about their appetite to include these changes in the Prague/Electra upgrade. Due to limited time on the call, Ryan also recommended discussing these EIPs in more detail during the next ACDC call.
Changes to Staking Rewards
Ethereum Foundation Research Ansgar Dietrichs raised a research post by his colleague at the Ethereum Foundation Anders Elowsson on changes to the staking reward curve. Based on Elowsson’s research, a reduction in rewards may be feasible to reduce inflation on Ethereum and reduce the rate of validator set size growth. Ryan encouraged developers to review Elowsson’s research and consider any potential action items or EIPs in light of it for inclusion in Electra or a different hard fork upgrade thereafter.
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.