Ethereum All Core Developers Execution Call #156 Writeup
On March 2, Ethereum developers gathered for All Core Developers Execution (ACDE) call #156. Chaired by the Ethereum Foundation’s Tim Beiko, the ACDE calls are a bi-weekly meeting series where Ethereum developers discuss and coordinate changes to the execution layer (EL) of Ethereum. This week, developers discussed timing for the next test network activation of Shanghai. They agreed to activate the upgrade on the Goerli testnet on March 14, 2023 at epoch 162304. Goerli is the final public testnet where the Shanghai upgrade will be tested. Should the Goerli testnet activation go smoothly, developers anticipate activating Shanghai on mainnet Ethereum sometime during the 2nd week April.
Sepolia Upgrade Recap
On Tuesday, February 28, developers activated the Shanghai upgrade on the Sepolia testnet. According to Parithosh Jayanthi, a DevOps Engineer for the Ethereum Foundation, the activation went smoothly. “We had a couple of BLS [withdrawal credential] changes lined up just before the fork and they were executed as expected after the [Shanghai]/Capella fork … We did have one full withdrawal as well. Mainly, the reason for such a low number of changes on Sepolia is that the validator set is really small, but everything seems to be functioning well right now,” Jayanthi said.
Jayanthi highlighted a few minor issues on the network at the time of the upgrade. Validator participation dropped on Sepolia immediately after the upgrade because certain node operators were running an older version of their EL software client. Updating the client software fixed the low participation rate of the network, he said. Marek Moraczyński from the Nethermind (EL) client team said that the Nethermind client was producing “bad blocks” on the Sepolia testnet. His team is still investigating the root cause of the issue, but he stressed that the issue is not related to Shanghai code specifications but rather the way the Nethermind client produces blocks on the network.
Finally, Chair of the ACDE calls Tim Beiko mentioned that Ethereum wallet provider Metamask was having issues updating their user balances as withdrawals were occurring on the testnet. Jayanthi chimed in saying that the issues Metamask were having have since been resolved. Geth (EL) developer Marius van der Wijden encouraged all client teams to double check their “getbalance” API endpoint and their documentation around it so that wallet developers know to avoid relying on user transactions for updating user balances. “Basically, the withdrawals are not a user transaction. So if you’re scanning user transaction to get the balance, withdrawals would not be counted as part of that. The getbalance [endpoint] should work but the withdrawals are not specific transactions in a block you can fetch,” said Beiko.
Updates on Block Serialization Formatting
Etan Kissling, a developer of the Ethereum Nimbus (CL) client team, shared updates on developers’ efforts to transition from a RLP block serialization format to SSZ. As background, serialization refer to the process of representing a data structure in a form that can be stored in or communicated between computers. According to Teku (CL) developer Ben Edgington, serialization is used for three main purposes on the Beacon Chain. Serialization ensures that nodes on Ethereum can reach consensus about the state of the blockchain, exchange information about attestations and block proposals, and finally, create API access for users. The serialization scheme that is used by the Beacon Chain, Ethereum’s consensus layer, is called Simple Serialize (SSZ). It differs from the serialization scheme used by Ethereum’s execution layer known as Recursive Length Prefix (RLP). There are a variety of reasons an SSZ serialization scheme was chosen for the Beacon Chain including reduced code complexity and greater efficiency.
However, the fact that Ethereum relies on two different serialization schemes between the consensus and execution layer creates overhead for building light client functionality and wallet infrastructure, which is why Ethereum core developers like Kissling have been focusing on upgrading Ethereum’s RLP serialization scheme to SSZ for the past few months. The stated goal for Ethereum developers when transitioning from an RLP to SSZ scheme is to preserve backwards compatibility for users and applications, as well as try to make these code changes in one go rather than multiple, phased steps. To this end, Kissling highlighted two main approaches to updating the representation of transactions on Ethereum, union and normalized. The union-based approach converts RLP encoded transactions to SSZ objects, while the normalized approach creates an SSZ container to replace the existing “ExecutionPayload” container representing transactions.
Kissling has performed several benchmarking experiments testing the performance of proof creation and verification under a union vs normalized approach. From his experiments, Kissling wrote that the union-based approach requires less computational resources than the normalized approach. However, he mentioned that “the SSZ union has some noteworthy flaws when representing non-SSZ transactions” and “the SSZ union also is less friendly for consumption by light clients.” Because of these tradeoffs, Kissling encouraged client developers to chime in with their thoughts on which approach to pursue. The meta thread linking to all relevant documents and communication channels about this initiative can be found here.
Cancun Planning
Then, developers moved on to discussing planning for the next upgrade on Ethereum after Shanghai, dubbed Cancun. Already, developers have agreed to include EIP 4844, proto-danksharding, and EIPs related to EOF implementation during prior calls. Beiko encouraged client teams and Ethereum stakeholders to use this Ethereum Magicians thread to chime in about other EIP candidates for inclusion in Cancun. A few candidate EIP briefly mentioned by developers on the call included:
EIP 4788: Exposing the Beacon Chain state root for proofs about the consensus layer state to be verified inside the EVM. This functionality supports a wide variety of use cases in smart contracts involving validator status and finality produced by the consensus layer.
EIP 2537: This EIP introduces new precompiles for efficiently performing operations such as BLS signature verification and SNARKs verifications.
EIP-5920: This EIP introduces a new opcode, PAY, taking two stack parameters, addr and val, that transfers val wei to the address addr without calling any of its functions.
EIP-6190: Changes SELFDESTRUCT function to only cause a finite number of state changes. Requires EIP 6189 to function correctly.
EIP 6189: This EIP allows contracts to be turned into “alias contracts” using a magic nonce. Alias contracts automatically forward calls to other contracts. In conjunction with EIP 6190, this EIP can be used to make SELFDESTRUCT compatible with Verkle trees.
Client Software Housekeeping Items
Finally, Geth developer Péter Szilágyi raised three housekeeping items about client software maintenance.
The first item was about deprecating version 66 of the Ethereum Wire Protocol. As background, the Ethereum Wire Protocol defines how nodes send and receive information to each other about the blockchain, latest blocks, and transactions. Szilágyi highlighted that developers have already implemented version 68 and therefore, should start to consider deprecating support for the older versions. However, due to certain client dependencies on the older versions, developers agreed to maintain support for older versions of the protocol and move off them at a later date.
The second item was about removing support for “pending block” or “pending transactions” in the execution API specifications. According to Szilágyi, there is no longer any utility that users or developers can gain from this endpoint. “Historically, it served as a glimpse into what the next block might be. However, even way back this [endpoint] became mostly moot when there are 4K txs in the pool and only a few fit into the block, but with MEV and the likes, it's even moot-er since we have no idea what sandwiches and other food types end up included,” Szilágyi wrote in a comment on this week’s call agenda. Therefore, Szilágyi recommended deprecating the endpoint. However, there was some concern from developers about the unknown impacts removing support of these endpoints would create especially on end-users. Beiko recommended that Szilágyi create a formal proposal for this deprecation that can be presented to the Ethereum community for direct feedback.
The final item raised by Szilágyi was about deprecating client support for syncing to test networks that have not been updated from the Merge upgrade. At present, all Ethereum (EL) clients maintain the capability to sync to non-merged test networks and transition them through the upgrade. According to Szilágyi, there is “a lot of code and logic around this old mode of operation” that would be nice to remove. Of course, this type of support could be left up to the client teams to decide on their own but as Szilágyi mentioned on the call differences in syncing capabilities may make it difficult to spin up test networks in the future that all client teams can support together. Beiko encouraged more conversation on this topic moving forward.
In general, there were no strong commitments to deprecate any of items raised by Szilágyi on the call. Szilágyi highlighted that these three items were raised to encourage developers to think about the ways in which they can remove and reduce complexity from Ethereum clients. “It’s always a bit annoying to remove something. There’s always somebody relying on it. And I definitely think we should somehow figure out how to proceed for those [people] … We don’t want to leave people hanging in the air but we [can’t accommodate] complexity forever,” said Szilágyi.
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.