Ethereum All Core Developers Execution Call #154 Writeup
On February 2, Ethereum developers gathered for All Core Developers Execution (ACDE) call #154. Chaired by the Ethereum Foundation’s Tim Beiko, the ACDE calls are one of two bi-weekly meeting series where Ethereum developers discuss and coordinate changes to the execution layer of Ethereum. The other meeting series, ACD Consensus (ACDC) calls, focus on planning related to the consensus layer of Ethereum. This week, developers discussed the timeline for public testnet launches of the Shanghai upgrade. They also shared updates on the progress being made to Cancun, the next upgrade after Shanghai, and specifically within the Cancun upgrade, progress on Ethereum Improvement Proposal (EIP) 4844.
Zhejiang Testnet Launch
The first public Shanghai testnet dubbed Zhejiang was launched on February 1, 2023. Unlike prior Shanghai testnets, Zhejiang is public, which means that anyone can request testnet ETH from a faucet and spin-up their own validators on the network. Zhejiang is currently supported by 61,000 active validators, the majority of which is operated by the Ethereum Foundation. Barnabas Busa, a DevOps Engineer at the Ethereum Foundation, mentioned on the call that the testnet was struggling to process new deposits of staked ETH due to what may be a configuration issue with the CL software clients. Assuming this issue is fixed over the next few days, developers plan on activating the Shanghai upgrade on Zhejiang next Tuesday, February 7.
The activation of Shanghai on Zhejiang and other public Ethereum testnets is the last major phase of testing before mainnet activation. Assuming Shanghai goes smoothly on Zhejiang next week, developers will decide on an activation date to release the upgrade on the Sepolia testnet during the next ACDC call on Thursday, February 9. Chair of the ACDE calls Tim Beiko stressed on this week’s call that Ethereum client teams should prepare to cut releases for the Sepolia Shanghai testnet launch shortly after next Thursday’s ACDC call. All client teams on this week’s call affirmed that they were ready to move forward with cutting new client releases for the Sepolia Shanghai upgrade after next week’s ACDC call. Once the Sepolia testnet is upgraded, sometime in mid-February, developers plan on releasing the upgrade on Ethereum’s Goerli testnet in late February or early March.
Speaking to the rationale for upgrading the Sepolia testnet before Goerli, Chair of the ACDC calls Danny Ryan said, “I think it makes sense to do Sepolia before Goerli given that Goerli is used by much more validators outside of a limited set and so that gives a bit more time for documentation and tooling to become more robust.” Public testnet activations of Shanghai are especially useful for Ethereum infrastructure providers such as exchanges and staking pools to test out their tooling for staked ETH withdrawals before mainnet activation of Shanghai. Assuming all the public testnet launches for Shanghai go smoothly, developers are on track for a mainnet activation of the upgrade in mid-March.
EIP 4844 Updates
Next, developers discussed a number of research items related to EIP 4844, which is a code change designed to reduce the cost of Layer-2 rollups on Ethereum. For more information about EIP 4844, refer to prior call notes here. Jacek Glen, a senior software engineer for blockchain consulting firm imapp, presented his findings from benchmarking the execution of new EIP-4844 related operations through different Ethereum software clients. His findings affirmed that the gas pricing of these operations were accurate and that there were some notable differences in the way these operations were handled between clients. In the benchmarking report, Glen writes, “Nethermind has a bit higher engine overhead, clearly visible for lower priced benchmarks like RipeMd or Sha256. The reason for this could be the benchmark method used, or some inefficiency in the way a call is handled. To be investigated.”
Given that the benchmarking analysis did not reveal major errors in the pricing of new operations, developers agreed to move forward with continuing to develop these operations and re-run benchmark tests at a future date. Developers also discussed how the network should handle new 4844 type transactions, called blobs, that do not contain any Layer-2 transaction data. “On the mempool side, it’s pretty hard to have logic for zero blob transactions because it comes with a couple of assumptions that otherwise you could make blob transactions basically no longer valid,” explained Ethereum Foundation researcher Ansgar Dietrichs, adding, “Would we simply want to exclude them from the mempool and still have them valid? In that case, they could still be included by a relayer, Flashbots-like system. … My personal preference would be to still allow them on the consensus rule side and only ban them from mempools.”
To this, Łukasz Rozmej, developer for the Ethereum Nethermind (EL) client, raised a potential problem with creating specialized logic for zero blob transactions. Specifically, Rozmej questioned how then the network should handle these transactions during a reorg where blocks in the Beacon Chain are removed and replaced by other blocks. “There is also the question mark on the general UX, user experience and usability, because if we mark these transactions as blob transactions, they have in my opinion a special domain, meaning they are easier to reason about in all of the cases … that they have blobs and they have special treatment because of this,” said Rozmej on the call. “If we allow zero blob transactions, this reasoning is broken and then you have to also inspect how many blobs they have in terms of the rules for this transaction.”
After more back and forth, developers agreed to revisit this topic of discussion later on the call after their conversation on how to update Ethereum’s EL serialization formats from RLP to SSZ. For background on the discussion around data serialization formats, refer to prior call notes here. Sticking to the broader agenda item of EIP 4844 related updates, Beiko asked the group about how best to move forward with testing EIP 4844 given the many different implementation styles of this code changes across clients. “This kind of thing is hard to test in a cross-client manner because it’s very non-deterministic and it’s very ‘stateful’ for each client and what they’re going to do,” said Danny Ryan on the call. Developers agreed to continue thinking about test suites specifically for EIP 4844 transaction pools and discuss the matter asynchronously on Discord.
Finally, Ansgar Dietrichs presented his proposal for decoupling block from blob production. There are several reasons for this. First, by using separate sub networks for propagating blob data and block data, these messages can be communicated more efficiently and in parallel. In addition, there is also a bandwidth reduction on Ethereum clients that come with decoupling blocks from blobs. Splitting blobs and blocks also leaves room in the future for implementing more advanced techniques such as erasure coding and data availability sampling for verifying blob data. To confirm assumptions about the efficiency gains from decoupling block and blob production, developers are currently working on a few EIP 4844 simulations. Developers agreed to revisit this conversation once the results of those simulations were ready to share.
JSON RPC API Endpoint Addition “eth_getAccount”
The Geth (EL) client team presented a proposal to add a new endpoint to the Ethereum JSON RPC. “The reason is we’ve had a few users requesting this type of functionality. Basically, what it does is it takes in some [Ethereum] address and it returns the tri-leaf definition of the accounts, which is the balance to store the nonce, the storage, and the code hash, if the account exists,” explained a Geth developer who goes by the pseudonym of “lightclient.” Developers on the call agreed to review the proposal on GitHub over the next few days. If there are no objections or new comments, developers agreed to merge the pull request on GitHub early next week.
RLP to SSZ
Moving on to discussions about Ethereum’s data serialization format, co-founder of Ethereum Vitalik Buterin presented his proposal for introducing five new SSZ transaction types. Two are new transaction types defined by EIP 4844, while the other three are SSZ representations of existing Ethereum transaction types. The benefit of wrapping legacy transaction types into a new SSZ format is to preserve backwards-compatibility for most users and applications. A representative from the Layer-2 rollup Optimism team highlighted that from their view they were not married to using a specific type of transaction and preferred SSZ routes for producing less error prone code.
Etan Kissling, a developer of the Ethereum Nimbus (CL) client team, also had ideas to present on this topic. Kissling had volunteered to draft the Ethereum Improvement Proposal (EIP) for making changes to harmonize data field formatting between EL and CL block headers in preparation for Cancun during last week’s ACDE call. On this week’s call, Kissling shared his ongoing work on the EIP which can be found on GitHub and asked questions related to how SSZ serialization format updates would be impacted by EIP 4844 code changes. To better discuss matters related to SSZ formatting changes, Beiko suggested scheduling a dedicated call some time next week. Kissling was in favor of the idea.
Benchmarking Ethereum EL Clients
Marius van der Wijden of the Geth (EL) team shared on the call that his team, in partnership with the Ethereum Foundations security and testing teams, were working on creating benchmarking infrastructure for Ethereum EL clients. This involves creating specialized blocks for benchmarking client performance and evaluating how long it take for that block to be executed. Van der Wijden said that over the next few weeks, EL client teams should expected to receive these specialized or in his words “funny” blocks.
Upcoming Meetings
Closing the meeting, Beiko gave a quick reminder to client teams about some of the upcoming meetings occurring next week:
EIP 4844 Implementers’ Call, Tuesday, February 7, 15:30 (UTC)
EOF Implementers’ Call, Wednesday, February 8, 15:00 (UTC)
ACDC Call, Thursday, February 9, 14:00 (UTC)
RLP to SSZ Serialization Format Meeting, TBD
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 2022. All rights reserved.