Ethereum All Core Developers Consensus Call #146 Writeup
On November 28, 2024, Ethereum developers gathered over Zoom for All Core Developers Consensus (ACDC) call #146. This week, the call was chaired by Ethereum Foundation (EF) Researcher Alex Stokes. The ACDC calls are a biweekly meeting series where developers discuss and coordinate changes to the consensus layer (CL) of Ethereum, also known as the Beacon Chain.
On ACDC #146, developers agreed to include EIP 7691, an increase to blob throughput capacity from 3/6 to 6/9 target/max blobs per block, in Pectra.
Mekong Deposit Processing Bug
Validator deposits on the Mekong testnet triggered major network disruptions earlier in the week on Monday, November 25. The testnet has since recovered and is finalizing again. Several fixes have either been implemented in clients or are in the process of being implemented, said Stokes.
Prysm developer “Potuz” raised the need for more Pectra specification testing in light of the deposit processing bug on Mekong. Consensys Researcher Mikhail Kalinin pushed on this sentiment saying that there are already tests for deposits but client code in some cases is different from specifications and there is a need for more extensive testing that covers client dependencies. Stokes said all types of efforts to bulk up testing for Pectra would be useful.
Devnet-5 Specifications
Developers are preparing to launch the next Pectra devnet, Pectra Devnet 5. Stokes highlighted four outstanding issues related to Devnet 5 specifications.
Engine: Exclude empty requests in requests list (execution API)
Update EIP-7742: Update the required EL headers and the gas fee mechanism (EIPs)
EIP 7251: Do not change creds type on consolidation (consensus)
The first issue is related to EIP 7685, general purpose execution layer requests. It is a corresponding Engine API change to an earlier one already merged and finalized for Devnet 5. The original code change proposes excluding empty items from the “requests_hash” commitment to ensure easier testing and mirror the behavior of other types of EL commitments. Both were proposed by Geth developer Felix Lange. Developers agreed on the call to merge the corresponding Engine API change into Devnet 5 specifications.
The second is an update to EIP 7742, uncouple blob count between CL and EL, to ensure that the gas fee mechanism for blobs correctly scales when the target/max values are updated, even if the target value is not half of the max value like it is currently. EF Researcher Ansgar Dietrichs said that the EIP is “nice to have” but it can be included later in the Fusaka upgrade to avoid delays to Pectra activation. In its place, Dietrichs recommended a minimal “one-line” change to the update fraction in EIP 7742 such that a block without any blobs triggers a reduction in the base fee by less than 21%. In effect, the one-line change would reduce the volatility of negative base fee adjustments.
A developer by the screen name “Dustin” said there was a lack of incentive for validators to propagate blobs. “Right now, no one complains if they miss blobs,” said Dustin, recommending an increase to blob fees either in Pectra or another fork to better incentivize the inclusion of these transactions in blocks. Dietrichs noted that the minimum priority fee requirement for blob transactions is a “client-side default parameter” that can be adjusted without a hard fork. Stokes also noted that there is an EIP for raising the base fee, the floor price on blobs, in Pectra, though it has not yet been formally included in the upgrade.
EF Researcher Toni Wahrstätter agreed most of the improvements to the blob fee mechanism should be tabled for Fusaka, as suggested by Dietrichs. EF Researcher Dankrad Feist expressed his support for an increase to the minimum blob base fee to refute the narrative that rollups are not contributing to the value of Ethereum. “Everyone's complaining roll ups don't pay. They don't contribute. They’re parasitic, which is, of course, complete bullshit. I think having a small base fee would end this annoying charade,” said Feist. Prysm developer “Potuz” pointed out that while increases to the minimum blob base fee may be useful, changes to blob priority tips require further research to better understand the market dynamics of tips and block timing games.
There was a rough consensus among developers to include the update fraction change in Pectra and table the rest of the blob fee mechanism improvements to Fusaka. On the topic of an increase to the minimum blob base fee, Stokes said that including this change feels “late in the game”. Dietrichs noted that the increase would be a simple code change to implement in clients but it is not fully specced out yet. Developers agreed to table the discussion about an increase to the minimum blob base fee for now and move forward with strictly the update fraction change in EIP 7742.
EIP 7691
The Ethereum Foundation’s PandaOps team conducted a study on the performance of home stakers and solo stakers since the introduction of blobs in the Dencun upgrade. They found that stakers operating on the most resource-constrained devices relative to other types of stakers on the network are performing well and would not be negatively affected by a blob capacity increase to either 4/8 or 6/9 target/max blobs per block.
Prysm developer “Potuz” was not in favor of an increase to 6/9, while Reth developer “Oliver” was. Wahrstätter pointed out that increasing the target/max such that the target value is not 50% of the max would introduce strange dynamics to blob base fee adjustments, that is the blob base fee would decrease at a faster rate than blob base fee increases. However, developers could address this kink later in the Fusaka upgrade. Dietrichs stressed that rollups care more about increasing the blob capacity than a perfect UX when it comes to blob base fee adjustments. Potuz cautioned against a “radical” change to blob capacity in Pectra and recommended that developers go with 4/8 values.
In favor of doubling the blob target, Dietrichs wrote in the Zoom chat, “I don’t think anyone argues that a throughput increase is without cost but we have to be willing to make tradeoffs and it’s a very modest ask for very big payoff… We are at real risk of losing L2s to alt-DA providers. That is much more impactful to real-world Ethereum users than any mild extra load for stakers.”
Despite opposition from Potuz, Stokes recommended moving forward with 6/9 values. “It is easy to scale back down if we really feel like we need to,” said Stokes.
EIP 7623
Related to the discussion on EIP 7691, developers discussed the inclusion of EIP 7623 in Pectra. EIP 7623 proposed an increase to the cost of call data such that the maximum size of Ethereum blocks is reduced. The EIP, proposed by Wahrstätter, is especially important to address a “worst case scenario” in the size of EL payloads given the inclusion of EIP 7691 in Pectra and a potential gas limit increase organized independently by validators.
Geth developer “Lightclient” was strongly opposed to this code change in Pectra, stressing that even without its inclusion, developers are not ready to implement existing Pectra code changes on mainnet. “I feel like we just had a major testnet failure and should add as few additional things as possible,” wrote Lightclient in the Zoom chat. Stokes agreed that this was the main reason in his view against EIP 7623 inclusion in Pectra. Nethermind developer Ahmad Bitar wrote in the Zoom chat that in his view the EIP should be a “prerequisite” EIP 7691. Dietrichs added, “EIP 7623 is a fix of an active security vulnerability. … This should have been the first EIP in the fork.”
Others like Nethermind developer Marek Moraczyński and EthereumJS developer Gajinder Singh agreed with Dietrich's comments. Reth developer “Roman” chimed in reiterating that developers should not increase blob throughput without coupling it with a lowering of the maximum block size. Stokes recommended moving forward with EIP 7623 in Pectra. Lightclient opposed the decision again. Stokes recommended tabling the discussion for further input from EL client teams on the next ACD call.
EIP 7251
The final issue related to Devnet 5 specifications that developers discussed was related to EIP 7251, the increase to validators’ maximum effective balance. There is an edge-case scenario where a malicious actor can trigger validator-staked ETH balance consolidations on behalf of another validator. It would require the malicious actor to send the validator their staked ETH in exchange. Albeit expensive, Stokes said it was “a potential attack vector” that Consensys Researcher Mikhail Kalinin has proposed a fix for. Stokes said the fix is a relatively “simple change” and confirmed specs and relevant tests for it would be pushed out post haste for CL teams to start their work on it.
Stokes asked if there was any opposition to including the change in Pectra Devnet 5. There were no objections.
PeerDAS
EF DevOps Engineer Barnabas Busa shared an update on PeerDAS. He said that client teams are waiting on Pectra Devnet 5 specifications before rebasing PeerDAS on top of Pectra. Once the rebase is complete, client teams will move ahead with coordinating a new PeerDAS devnet launch. This is also the status of EOF implementation progress as well, Busa said.
EIP-7805
Thomas Thiery, an Ethereum Foundation Researcher, gave a presentation on EIP 7805, fork-choice enforced inclusion lists (FOCIL). FOCIL essentially enables validators to define a set of transactions that builders must include in their blocks. In doing so, validators can boost the censorship resistance of Ethereum by ensuring that builders do not have full control over transaction inclusion in a block.
Caption: State of PBS, Slide from Theiry’s presentation on FOCIL.
Source: Youtube (@EthereumProtocol)
Thiery highlighted a newly launched website to promote the benefits of FOCIL and provide further details about how it works. He said there are representatives from both the Geth and Prysm teams already working on an implementation for FOCIL and asked other client teams interested in joining to reach out to him.
Due to limited time on the call, Stokes said that the remaining agenda items related to ACD call process improvements will be tabled for discussion until the next ACD 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.