Ethereum All Core Developers Consensus Call #108 Writeup
On May 4, 2023, Ethereum core developers gathered over Zoom for their 108th All Core Developers Consensus (ACDC) call. 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.
Executive Summary
This week, they discussed progress on the following Ethereum Improvement Proposals (EIPs):
EIP 4788, Exposing Beacon Chain Roots in the EVM: Developers agreed to consider EIP 4788 for inclusion in the Deneb upgrade. Ryan said that CL client teams would start to build the code changes for EIP 4788 into Deneb for formal testing.
EIP 6987, Forbid Slashed Validators from Being Elected as Block Proposers: Like EIP 4788, Ryan said that EIP 6987 was also a likely candidate for inclusion in Deneb and code changes associated with EIP 6987 would soon be added to Deneb specifications for testing.
EIP 6475, New SSZ Type to Represent Optional Values: Tim Beiko, Chair of the All Core Developers Execution (ACDE) call, reminded CL client teams of continued uncertainty around the extent to which new SSZ types introduced through EIP 4844 should be forward compatible with forthcoming SSZ upgrades or optimized for current RLP standards.
Developers also discussed progress on the following GitHub pull requests (PRs):
Consensus specifications, PR #3338: Gajinder Singh, a developer for the Lodestar (CL) client, gave color around a PR for introducing more flexibility to the execution layer (EL) to independently increase the maximum numbers of blobs per block independently from the CL. Blobs are the new transaction type that will be introduced through EIP 4844 and used by Layer-2 rollups for cost-savings.
Consensus specifications, PR #3312: Ryan reminded CL client teams that the attnet revamp discussed during last week’s ACDC call would be merged into consensus specifications today, May 4. The changes are backwards-compatible so CL clients can merge the code changes on a rolling basis over time.
Consensus specifications, PR #3105: Mikhail Kalinin, a developer for the Teku (CL) client, has created a PR to affirm logic around how CL nodes obtain a finalized block hash. CL client teams are already following this logic but specifying the logic explicitly in consensus specifications would be useful for posterity. Kalinin said he would like to move forward with introducing the code changes into existing testing frameworks for CL specifications in the coming weeks.
Beacon APIs, PR #317: Michael Sproul, a developer for the Lighthouse (CL) client, has proposed a standard query parameter for MEV relays to control when a block is broadcast. This feature currently is only enabled in a forked version of the Lighthouse and Prysm clients. To encourage client diversity and reduced dependencies on specific versions of strictly the Lighthouse and Prysm, this PR creates a standardized way for all clients to support broadcasting blocks after verification, instead of before. A representative from the Lodestar team has already affirmed that they will support this feature.
Finally, Ryan mentioned a modification that was needed to the process of collecting validator attestations for security reasons. He said he would create a PR on GitHub for this change with further details after the call.
EIP 4788 and 6987
During last week’s ACDE call, developers agreed to consider EIP 4788 for inclusion in the Deneb upgrade. EIP 4788 would enable proofs of CL state on the EL for trustless verification by smart contracts, especially smart contracts underpinning staking pools, restaking protocols, and bridging applications. In addition, CL client teams had discussed two weeks ago including PR #3175 on the consensus specifications GitHub repository to the Deneb upgrade. PR #3175 is in the process of being formatted as an EIP. The EIP number for this code change is 6987 and namely prevents slashed validators from being selected by the Ethereum consensus protocol as block proposers for security reasons. Since the previous ACDC call, the amount of code changes needed to implement EIP 6987 has been greatly reduced. Ryan said that developers would start working on including and testing these two EIPs for the Deneb upgrade.
Deneb Blob Discussion
Then, developers discussed introducing an additional variable and constant to Deneb specifications for allowing greater elasticity on the EL to adjust the maximum number of blob transactions per block independently from the CL. Ryan encouraged CL client teams to review the open PR on GitHub and be ready to decide whether to merge the changes by the next ACDC call.
Separately, Barnabas Busa, a DevOps Engineer at the Ethereum Foundation, mentioned that recent testing efforts on Deneb Devnet #5 has resulted in several errors and bugs in clients. Erigon (EL) is crashing and Nethermind (EL) is unable to propose blocks, said Busa. The issues were sparked after Geth (EL) developer Marius van der Wijden ran a transaction fuzzer on the network. Van der Wijden said that when he started the fuzzer, he was not using his own node, and therefore, could not do a proper assessment of the issues that resulted. He said he would spin up his own node to do more investigations on the issues.
Deneb Future Compatibility Considerations
Tim Beiko raised ongoing questions around the SSZ changes that would be included in Deneb, more specifically through EIP 4844. “There’s been questions around is the amount of SSZ we’re introducing with 4844 actually helpful to getting us towards full SSZ on the EL and if it isn’t, then does introducing the partial SSZ now and not being able to fully leverage it actually make things worse than simply sticking with RLP to encode the 4844 type transactions,” said Beiko. Ryan added that the “flat hash” SSZ type which is currently being used in EIP 4844 is the “worst of both worlds” as it is not formatted for RLP but also not taking advantage of full SSZ serialization.
To Ryan’s point, a pseudonymous developer for the Geth (EL) client that goes by the screen name of “lightclient” said that in lieu of an “extremely clear idea” of what SSZ serialization would look like on Ethereum in the future, it would be difficult to introduce SSZ into EIP 4844 specifications in a forward-compatible way. “It’s really hard for us to actually put SSZ here and in a way that we know is going to be forward compatible. I think the reality is that it’s almost certain that we’ll either constrain the design space in the future or we just have to straight up change what we choose today,” said lightclient. Hsiao-Wei Wang, a researcher for the Ethereum Foundation, said that certain logic would have to be changed in EIP 4844 to move from the current flat hash design to something more RLP comptaible. Lightclient responded saying there was a slightly more complicated way to preserve the flat hash SSZ structure in the CL and have it represented in RLP on the EL.
Van der Wijden said he would prefer to change transaction types in one big overhaul rather than in a piecemeal fashion. However, keeping the RLP transaction type for blob transaction in EIP 4844 would require a deprecation notice at their creation to inform users that the transaction type is temporary and will be changed in the future. “If we were to go this route of having the blob transactions in RLP, one thing that I would really like us to do is to create this conception that this transaction type will not be there forever. We are going to drop it at some point in favor of the full SSZ blob transaction type once we have the transaction route. Because we suspect only rollups are going to use this transaction type, it will mostly likely see very little usage,” said van der Wijden.
Ryan asked developers whether the full transition to SSZ would result in the deprecation of existing Ethereum types or create modifications to migrate existing ones that are formatted in RLP to SSZ. Van der Wijden responded saying that developers did not want to “fully deprecate” RLP transaction types. A full deprecation would prevent validation of signed transactions in Ethereum’s prior chain history but as a workaround to this issue, developers could introduce a dedicated precompile to allow nodes to execute RLP transaction types and verify them. Ryan suggested that developers continue this discussion on next Thursday’s ACDE call.
Diversifying MEV-Boost Relay Client Dependencies
Then, Ryan reminded developers that the revamping of Beacon Chain attestation subnets (attnets) would be rolled out today on May 4. The upgrade is backwards compatible so the improvements to bandwidth use for validator node operators when connecting to attnets can be rolled out by client teams at their leisure. During a future hard fork upgrade, developers may consider introducing a “downscoring” feature to discourage nodes that have not upgraded their attnet capabilities from connecting to nodes that have.
Developers also discussed PR #317 on the Beacon Chain API GitHub repository. Considering recent MEV-Boost exploits, relays are now verifying the contents of blocks before broadcasting them on gossip. This functionality requires custom forks of the Lighthouse and Prysm clients. Michael Sproul, a developer for the Lighthouse (CL) client, has proposed a standard query parameter for enabling the same functionality across all CL clients. Terence Tsao, a developer of the Prysm (CL) client, said that in some ways introducing this functionality creates greater dependence on MEV-Boost, which is a temporary software for earning MEV on Ethereum that should be deprecated in favor of enshrined proposer-builder separation (PBS) at some point in the future. “The downside with this is that we’re working on the relayer versus working on enshrined PBS because now it becomes this board game where we’re just keep adding features to support MEV-Boost and PBS that’s out of band. That’s probably the biggest concern,” said Tsao.
Ryan said that he also recognizes the tension between adding support for MEV-Boost and trying to concurrently work on replacing MEV-Boost with an in-protocol solution. Ryan asked CL client teams to review the PR and leave comments on GitHub.
Miscellaneous
There were two other PRs that were briefly mentioned at the end of the call. The first was PR #3105 on the consensus specifications GitHub repository. This is a PR proposed by Mikhail Kalinin, a developer for the Teku (CL) client, that affirms the appropriate logic for CL nodes to store and obtain the finalized block hash that is sent to the EL. Kalinin said that we would start working on tests for this PR once client teams have had a chance to review the specifications.
The second PR was mentioned by Danny Ryan. This PR which will be created in the coming weeks introduces a modification to the process for validator attestations for security reasons. Jacek Sieka, a developer for the Nimbus (CL) client, asked whether the forthcoming PR would impact gossip protocols. A representative from the Teku (CL) client team also questioned whether this would impact the degradation of attestation value over a period. Both appeared likely. Ryan said that he would post formal specifications for this PR in the coming weeks and address these concerns.
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 2023. All rights reserved.