skip to content

Ethereum All Core Developers Execution Call #156 Writeup

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.

  1. 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.

  2. 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.

  3. 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.