Ethereum All Core Developers Execution Call #170 Writeup
On September 14, Ethereum developers gathered over Zoom for All Core Developers Execution (ACDE) call #170. Chaired by the Ethereum Foundation’s Tim Beiko, the ACDE calls are a bi-weekly meeting series where Ethereum client teams discuss and coordinate changes to the execution layer (EL) of Ethereum. This week, developers discussed:
two last-minute additions to the Cancun/Deneb (Dencun) upgrade,
updated timing for the launch of Devnet-9,
audit results for EIP 4788,
and the development of a new EL software client written in Rust called “Reth.”
Devnet-8
First, developers discussed the status of Devnet-8, the latest Dencun-focused test network. Parithosh Jayanthi, a DevOps Engineer at the Ethereum Foundation, said that the testnet is healthy and finalizing. He mentioned that a few client teams including Prysm (CL), Besu (EL), and Nethermind (EL) had been pushing new updates for experimentation purposes to their software on Devnet-8. Additionally, developers are testing MEV-Boost software and workflows between validators and block builders on Devnet-8. Jayanthi mentioned that there are a few nodes on the testnet that appear offline and the reason for this will need to be investigated after the call.
Terence Tsao, a developer for the Prysm client, said he has been noticing a 500-millisecond delay in the arrival of blobs on Devnet-8 that is causing delays to block processing. Tsao added that one of the reasons for the delay may be because the “get-payload” request takes longer to return if the payload, that is the block, also has blobs attached to it. Danny Ryan, a researcher for the Ethereum Foundation and Chair of the All Core Developers Consensus (ACDC) calls, said that the issue may be specific to client implementations and that he would be interested in closely following the investigation of this issue.
Marius van der Wijden, a developer for the Geth (EL) client, has reportedly started fuzz testing on Devnet-8. Marcin Sobczak, a developer for the Nethermind client, said that their client appears stable on Devnet-8. Andrew Ashikhmin from the Erigon (EL) client team said that his team was now working on improvements to the blob transaction pool that should be ready for testing on Devnet-9. From the Geth (EL) client team, developer Péter Szilágyi said his team was working on a specialized fetcher tool for blob transactions. “Currently, blob transactions are announced [on the network] the same way as other [regular] transactions and they are retrieved without throttling or without any other protective mechanism. So that’s the thing we still need to add,” said Szilágyi.
From the Besu (EL) team, developer Fabio Di Fabio said that his team is working on fine tuning a new implementation for a transaction pool that does not limit transactions by number but rather by size to help nodes better manage the additional computational resources that will be needed to store pending blob transactions that may be few but large in size. Then, developers discussed a minor change to hive tests to better accommodate EL clients’ transaction pool implementations.
EIP-7514: Add Max Epoch Churn Limit
As discussed on last week’s ACD call, there is a proposal by a Lodestar (CL) developer with the screen name “Dapplion” to cap the maximum churn limit and thereby, restrict the maximum growth rate of the Ethereum validator set. To learn more about why Ethereum developers are concerned about the growth of the validator set size, read the Galaxy Research report, Paths Toward Reducing Validator Set Size Growth. Since last week’s call, Dapplion’s proposal has been formalized into an Ethereum Improvement Proposal (EIP), EIP 7514, and further specified to cap only the maximum churn for validator activations, as opposed to validator exits. This means that the churn limit for validator exits would continue to grow as the Ethereum validator set size grows, while the churn limit for validator entries would be capped at a certain number.
Dapplion initially proposed a cap to the churn limit of 12 validator entries. However, several developers including Danny Ryan, Phil Ngo from Lodestar, Ethereum Foundation Researcher Ansgar Dietrichs, and Enrico Del Fante from Teku (CL), on this week’s call were in favor of setting the cap to 8 validator entries. Additionally, developers who had been hesitant about including this code change in Dencun during prior calls expressed that they had changed their minds and were now supportive of the EIP. A developer by the screenname “sean” from the Lighthouse (CL) team said he was in favor of EIP 7514 going into Dencun. Ethereum Foundation research Dankrad Feist said, “I am in favor of doing this. I think there is a chance that the [validator] queue will stop being full at some point end of this year, if not start of next year or something. But it’s a big gamble to bet on this. We’re not sure what’s going to happen, and I have a fear that we might get into a situation where we could have to make very drastic moves on staking. So, if we can agree to do this churn limit change instead then it would be much more comfortable for us to make more measured transitions during the course of the next year or the year after, rather than having to rush things.”
Based on the broad support for the EIP from CL client teams, developers agreed to include EIP 7514 into Dencun. Danny Ryan said he would work on finalizing this code change into a new CL specifications release for Dencun by next Monday, September 18. The proposed CL specifications for EIP 7514 can be viewed here.
EIP-7516: BLOBBASEFEE opcode
The second EIP that was discussed for inclusion in Dencun was EIP 7516. It was presented by Lee Bousfield, who is a tech lead at Offchain Labs. Offchain Labs is the development company behind Layer-2 rollup Arbitrum and the company that maintains the Prysm client. Bousfield explained EIP 7516 is similar in design and motivation to EIP 3198, BASEFEE opcode, which was activated during Ethereum’s London upgrade. As background, the London upgrade on August 5, 2021, introduced major changes to how transactions on Ethereum are priced. Namely, it introduced an algorithmically priced “base fee” for all transactions that dictates which transactions are eligible for inclusion in the next block and which are not. The upgrade also introduced a fee burning mechanism that has burned over 3.6mn ETH since activation. For more information on the Ethereum London upgrade and its impacts, read this Galaxy Research Report.
EIP 3198 is an opcode that returns the value of the base fee of a current block. It is used within smart contract applications to access real-time information about the cost of transactions on the network. EIP 7516 would perform a similar function by helping Layer-2 rollups access real-time information about the base fee or cost for blob transactions. Blobs are a new transaction type that will be introduced through the Dencun upgrade designed to reduce the cost of posting data from rollups to Ethereum. Blobs will be priced according to a separate fee market, which is why EIP 7516 calls for the creation of a new opcode that can accurately return the value of the blob base fee of the current block. To learn more about blobs, read this Galaxy Research report.
Exposing the value of the blob base fee on the smart-contract level would be useful for Layer-2 rollups when calculating how much to charge for user transactions. “L2s need to charge users for the price of posting the user transactions to L1,” said Bousfield. “How this generally works is there’s a sequencer which accepts user transactions or if there isn’t a sequencer, there’s some sort of aggregator model, some entity that accepts user transactions over the RPC, posts them to the Layer-1 and it has to charge the users a fee to pay for the cost of posting those transactions to Layer-1.”
A developer by the screen name “Protolambda” who works for OP Labs, the development company behind Layer-2 rollup Optimism, added that EIP 7516 was not “strictly necessary” for Layer-2 rollups but would be “a nice to have.” Andrew Ashikhmin expressed his support for the EIP, especially given that it is not a complex code change that is extremely similar to a pre-existing opcode, the BASEFEE opcode. A representative from the Geth team said that they had already included EIP 3198 in their Dencun implementation. Marek Moraczyński from the Nethermind team was in favor of the EIP and Mario Vega from the Ethereum Foundation testing team added that his team was already working on test coverage for the code change. Based on the support from client teams and developers, Beiko agreed to add EIP-7516 to the Deuncun upgrade.
Based on the decisions from this week's call, the scope of the Dencun upgrade now contains the following EIPs:
EL EIPs
EIP-1153: Transient storage opcodes
EIP-4788: Beacon block root in the EVM
EIP-5656: MCOPY - Memory copying instruction
EIP-6780: SELFDESTRUCT only in same transaction
EIP-7516: BLOBBASEFEE opcode*
CL EIPs
EIP-7044: Lock voluntary exit domain on Capella
EIP-7045: Increase max attestation inclusion slot
EIP-7514: Add Max Epoch Churn Limit*
EL/CL EIPs
EIP-4844: Shard blob transactions
*New EIP addition to Dencun as of ACDE #170.
Devnet-9
Based on the two new additions to the Dencun upgrade, developers agreed to push back the launch of the next Dencun testnet, Devnet-9, by one week to Tuesday, September 26. Developers will reconfirm the launch date of Devnet-9 and the status of new client implementations during next week’s ACDC call. Devnet-9 may be the last developer-focused testnet where the Dencun upgrade is launched before developers start to upgrade public Ethereum testnets such as Holesky, Goerli, and Sepolia.
Related to this discussion on the status of Devnet-9, developers discussed whether client implementations for the next testnet should include changes to EIP-4788 that were recommended by third-party auditors. As background, EIP-4788 is undergoing three independent audits from the following companies: Chain Security, Dedaub, and Trail of Bits. Early audit results from the first two auditors, Chain Security and Dedaub, have already presented a few tweaks to the EIP that could be made in time for Devnet-9. However, Beiko questioned whether developers wanted to wait for final audit results and implement all changes at once. Beiko said the final audits should be ready in two weeks’ time.
Marius van der Wijden from the Geth team expressed that he would prefer incorporating changes as soon as possible so that he can re-run his own tests on EIP-4788. A Geth developer by the screen name “lightclient” said that he is hopeful no more changes for EIP-4788 will be found from the third audit. Beiko suggested merging the changes from EIP-4788 audits so far. Developers also discussed the need to get on the same page about an edge case scenario under EIP-4788 related to empty accounts. Beiko recommended revisiting this topic in next Monday’s Dencun testing call.
Finally, for Devnet-9, Mario Vega asked whether the testnet would include “the mainnet trusted setup”, possibly referring to the trusted setup required for EIP 4844, though this was not clear from the call recording. Ethereum Foundation Researcher Carl Beekhuizen said that the trusted setup would not be ready for testing in time for Devnet-9. Beiko suggested the potential for a short-lived testnet after Devnet-9, possibly a Devnet-10, to assess the trusted setup once ready.
Reth Overview
For the past year, Georgios Konstantopoulos, the Chief Technology Officer at crypto investment firm Paradigm, has been leading efforts to build a new open-source Ethereum EL client written in the programming language Rust. The client is called Reth. There are 155 contributors to the client, 8 of which are funded by Paradigm. Konstantopoulos shared that Reth is close to being feature-complete for the Dencun upgrade and shared plans to have a version of the client ready to participate in the upcoming Devnet-9 launch. He shared details about the architecture and performance of Reth nodes, as well as plans to expand the Reth SDK. He also offered the Reth team’s help on review and feedback for future EIPs. The full slide deck from Konstantopoulos’ presentation of Reth on this ACD call can be found here. Beiko encouraged call participants to chime in with any questions about the Reth client in the Ethereum R&D Discord.
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.