Ethereum All Core Developers Consensus Call #107 Writeup
On April 20, 2023, Ethereum developers gathered for their 107th All Core Developers Consensus (ACDC) call. Chaired by Ethereum Foundation Researcher Danny Ryan, the ACDC calls are a bi-weekly meeting series where Ethereum developers discuss and coordinate changes to the consensus layer (CL) of Ethereum. This week, developers gave updates on their progress around Deneb and discussed what other code changes in addition to Ethereum Improvement Proposal (EIP) 4844 should be included in Ethereum’s next upgrade.
Deneb Devnet #5
Since the successful activation of Shanghai last Wednesday, on April 12, Ethereum developers have wasted no time switching their focus on preparations for Cancun. As background, Cancun is the name for the next upgrade on the execution layer (EL) of Ethereum while Deneb is the corresponding upgrade name for the CL. Last week, during ACDE call 159, developers began discussing the final scope of the Cancun/Deneb upgrade which will be centered around EIP 4844, the implementation of blob transaction types. This week, after a brief acknowledgement around the success of Shanghai, developers promptly moved on to discussing preparations for Deneb, starting with the launch of devnet #5.
Since as early as October, developers have launched multi-client test networks, also called devnets, for EIP 4844. Tim Beiko, chair of the ACDE calls, said that the fifth devnet for EIP 4844 will be launched sometime next week. Paritosh Jayanthi, a DevOps Engineer for the Ethereum Foundation, said that he is in the process of doing trial runs for clients like Ethereum JS (EL) and Lodestar (CL) to prepare them for the devnet launch next week.
There is a minor change to the Engine API that merges the “getPayloadV3” and “getBlobsBundleV1” calls into one. Beiko emphasized that this change has not yet been merged into specifications for EIP 4844 on GitHub but will be in the next few days so that the change can be live for testing on devnet #5. Beiko urged client teams to review the change as soon as possible.
Developers then discussed concerns around how blob transactions should be reinserted into blocks in the event of a chain reorganization. This issue was raised by Geth (EL) developer Péter Szilágyi during a presentation he gave at ETHTokyo. Slides from Szilágyi’s presentation can be found here. Ryan said that due to the decoupled nature of blob transactions from regular transactions, reconstructions of blobs after a chain reorg may only be available from transactions seen in the public mempool. Given that there are plenty of transactions that bypass the mempool, that is MEV transactions and bundles, one way to guarantee all blobs can be reconstructed even the ones that bypass the mempool is to have the CL pass along blob data for every block to the EL, which the EL can then cache until block finalization. Alternatively, the network could simply require users that have submitted transactions bypassing the mempool to resubmit their transactions in the event of a chain reorg.
Szilágyi said that his preference was for the former, to have the blob data communicated to the EL so that in the event of a reorg transactions can be reinserted, even the transactions that bypass the mempool. In Szilágyi’s view, the additional load on the EL is not large and if the process becomes rather excessive for nodes to support, developers can tweak the message between the EL and CL to lighten the load. “The simplest solution would be for consensus clients to give the blobs to execution clients essentially when they send a new payload,” said Szilágyi. Ryan responded saying that while the proposed solution was simple it would further break down the abstraction between the EL and CL layers. In addition, the solution would reinforce the assumption that nodes will store full copies of blob data, which may be an assumption that is broken in a future upgrade implementing data availability sampling (DAS).
About the implementation of DAS, Szilágyi said that there would be other expectations around data availability that would have to change anyways for this upgrade and recommended that developers “try to cross that bridge once we get there.” Ryan agreed and asked what other developers thought around the edge case of chain reorgs and blob transaction reinsertions. Gajinder Singh, a developer for the Lodestar (CL) client, said that since MEV transactions are the most common type that bypass the public mempool and the execution of MEV transactions are highly dependent on a specific chain state, dropping then after a chain reorg would not matter since the chain state will have changed and MEV transactions will likely need to be re-executed anyways.
Due to the lack of EL client team representation on the call, Ryan recommended surfacing this issue again during next week’s ACDE call. Szilágyi agreed to continue thinking on this topic in light of MEV activity and future upgrades like DAS.
Deneb Add-Ons
In addition to EIP 4844, there are a handful of other code changes under consideration for the Deneb upgrade.
The first is EIP 4788, which exposes the CL Beacon Chain state in the EL. This will allow for trust-minimized access to the CL by smart contracts executed on the EL, which is relevant for staking pools, restaking protocols, MEV mitigations, and more. Ethereum Foundation researcher Alex Stokes who is one of the authors of the EIP said that the feature is a “lightweight” change to the CL. No one on the call was opposed to including EIP 4788 in Deneb. Ryan said that he would get a temperature check on support for the EIP from EL client teams on the next ACDE call.
The next EIP developers discussed for Deneb was EIP 6914, which would reuse the validator index numbers of validators that have fully exited the network and have not been active for some time. This EIP would help reduce the unbounded growth of the validator list, as validators exit and new validators join the network. Stokes said that the complexity of EIP 6914 is enough to make him think the code change should be pushed to the next hard fork after Deneb. A developer from the Lighthouse (CL) client team who goes by the pseudonym “realbigsean” agreed that the EIP was useful but not urgent for the next upgrade. After some more discussion around the complexities of EIP 6914, developers agreed to continue hammering out the details of the code change but leave its implementation for a hard fork after Deneb.
Ryan then raised a potential code change around backfilling data from Beacon Chain genesis and creating new “historic summaries.” The details around this code change have yet to be specified in a pull request or EIP. Ryan agreed to link up with the proposer of this change, Jacek Sieka, Head of Research Development at Status who is building the Nimbus (CL) client, for more details.
Then developers discussed PR 3175, which would prevent slashed validators from proposing blocks while in the exit queue. In the event where more than 50% of validators are slashed for malicious behavior, these validators would still be able to proposer blocks while being forcefully ejected from the network. Changing this logic is a relatively minor change from the CL layer that provider protection against “a high failure mode,” said Ryan. Realbigsean was in favor of including it in Deneb. Enrico Del Fante from the Teku (CL) client team was also in favor.
Finally, Etan Kissling, a developer of the Ethereum Nimbus (CL) client team, urged developers to consider EIP 6493 which would address how nodes should handle blob transaction types formatted in SSZ on the CL but encoded differently on the EL. This EIP is part of a larger push to update Ethereum’s serialization formats for consistency across layers. Kissling did mention that EIP 6493 primarily impacts the EL and so Ryan suggested they raise the topic again on next week’s ACDE call. For more context around Ethereum serialization formats, read prior developer call notes here.
From this discussion on Deneb scope, developers were most keen on including EIP 4788 and 3175 alongside EIP 4844.
Miscellaneous
Moving on from discussions around Deneb, Ryan raised a pending change in the Engine API that was proposed last week by Mikhail Kalinin from the Teku (CL) client team. The change was prompted by a bug initially discovered in the Nimbus/Besu (CL/EL) client combination but also impacting other clients such as the Nethermind (EL) client. The proposed change clarifies logic around stating block payload IDs as unique values for each instance of the “payloadattributes” field. For more information on this change, read the GitHub pull request here. Developers plan on merging the change to Engine API specifications on GitHub over the next few days.
During the last ACDC call, developers discussed creating a standardized RPC endpoint for nodes to validate blinded blocks. Blinded blocks refer to blocks where the transaction contents cannot be seen. Realbigsean said that he was still in support of the standardization of this endpoint across clients and would work on creating formal specifications for its implementation.
Then, developers discussed revamping Beacon Chain attestation subnets (attnets). Attnets help connect validators to the Beacon Chain so that they can quickly publish and propagate their attestation messages. There is a concern that validators are oversubscribed to attnets, which is resulting in significant bandwidth use. To reduce the density of attnets and help prevent unnecessary information leaks about validating nodes, Adrian Manning from the Lighthouse (CL) client team has proposed a solution for subscribing validator nodes to long-lives attnets. The full details of Manning’s proposal can be read here. Manning explained that the change does not have to be executed through a hard fork. CL client teams can implement the change ad hoc over time. Ryan and Manning called for more eyes reviewing the changes proposed to Beacon Chain attnets.
Guillaume Ballet, a Geth developer for the Ethereum Foundation, who is working on research around migrating Ethereum data structures away from Merkle Patrica trees to Verkle trees, raised a cosmetic change to create a number field in the JSON of the execution payload. Ballet said that his main motivation for creating this field would be to avoid using hex strings for numbers, which is “wasteful,” and instead use regular JSON numbers. Developers did not have a strong opinion around this change. Ryan encouraged Ballet to create a pull request on GitHub to get more feedback on his proposal.
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.