Ethereum All Core Developers Execution Call #171 Writeup
On September 28, Ethereum developers gathered over Zoom for All Core Developers Execution Call #171. Chaired by the Ethereum Foundation’s Tim Beiko, the ACDE calls are a bi-weekly meeting series where developers discuss and coordinate changes to the execution layer (EL) of Ethereum. This week, developers discussed:
Progress on testing for the Cancun/Deneb (Dencun) upgrade
Early audit results for EIP 4788, beacon block root in the EVM
Holesky testnet launch
Initial feedback for EIP 7503, zero-knowledge wormholes
Changes to specifications for EIP 6780, SELFDESTRUCT only in the same transaction
Dencun Testing
The launch of Devnet-9 has been delayed again. Devnet-9 is a dedicated testnet that will feature the activation of all nine code changes going into the Dencun upgrade. Last Thursday, developers were aiming to launch the testnet Wednesday September 27. Now, developers are aiming to launch Devnet-9 tomorrow, Friday, September 29, or early next week. Barnabas Busa, a DevOps Engineer for the Ethereum Foundation, said that he would like to see client teams passing more hive tests. Hive is a system for running integration tests against Ethereum clients. The full list of hive tests for the Dencun upgrade can be found here. The following are a few client updates that were shared on this week’s call:
Marek Moraczyński from the Nethermind team said that his team is working on resolving a few hive test failures.
Gajinder Singh from the Lodestar and EthereumJS team said that his team would be ready with a release for Devnet-9.
Fabio Di Fabio from the Besu team said his team is working on setting limits to the number of blob transactions their client can receive to prevent nodes from crashing.
For Devnet-9, Parithosh Jayanthi, a DevOps Engineer at the Ethereum Foundation, said that developers would be testing the full deployment and activation of the beacon roots smart contract for EIP 4788. Developers have finalized the address at which the smart contract will be deployed on mainnet and will be using the same address for Devnet-9. Regarding the implementation of the trusted setup for EIP 4844, shard blob transactions, developers are still waiting on the conversion of contributions to the trusted setup before testing and implementing the results on a devnet. For more information about the trusted setup needed for EIP 4844, read this Galaxy Research report.
After the launch of Devnet-9, Busa mentioned that developers will need to spin-up a 10th devnet for the Dencun upgrade that will test EIP 7514, add max epoch churn limit. While all client implementations will include the specifications for EIP 7514 in Devnet-9, the network conditions that would trigger a maximum epoch churn limit of 8 will not be part of testnet parameters. However, Devnet-10 will intentionally feature a higher number of total active validators to ensure that the logic of EIP 7514 is working in all clients. Busa noted that Devnet-10 will be a shorter-lived testnet than prior devnets.
Developers will also test the workflow for validators to earn maximal extractable value (MEV) using MEV-Boost software on Devnet-9 and 10. Jayanthi encouraged individuals and companies operating relays or third-party block builders to reach out and take part in both testnets. Busa also mentioned that moving forward, Ethereum testnets will feature genesis from the Shanghai/Capella upgrade, rather than the prior Paris/Bellatrix upgrade.
EIP 4788 Audit Results
Three audits have been completed for EIP 4788. These audits were conducted by Chainsecurity, Trail of Bits, and Dedaub. Representatives from Chainsecurity and Dedaub shared findings from their audit on this week’s call.
Hubert Ritzdorf, a blockchain security engineer for Chainsecurity, said that one of the most important findings from the audit was that users could query the smart contract address with a zero-timestamp, even though no value has been set for the zero-timestamp. According to the audit report, this violates an important property that all returned values must have previously been set. “With 0 as an argument for ‘get ()’, the returned beacon root would be zero. This leads to integrators being tricked into accepting the zero-hash as a valid beacon root which might allow exploits depending on the protocol,” the audit report adds.
The second finding from the audit is that the behavior of the ring buffer applied by the smart contract to limit the amount of data that can be queried would drastically change based on the “SECONDS_PER_SLOT” parameter. This parameter dictates the interval between slots, which is currently set to 12 seconds. The audit suggests increasing the ring buffer to account for potential changes in the SECONDS_PER_SLOT parameter in the future.
Next, a representative from Dedaub shared their findings from their analysis of EIP 4788. The representative said that their team came to similar conclusions as Chainsecurity. As a final recommendation, Ritzdorf encouraged protocol developers on the call to explicitly specify for smart contract developers on Ethereum that querying the EIP 4788 smart contract for a specific timestamp will not return the beacon root at that timestamp. Rather, smart contract developers who query the account for a specific timestamp will receive the beacon root that was inserted to the contract at the specified timestamp, not necessarily the timestamp at which the beacon root was created on the Beacon Chain. “When you’re querying for timestamp X, you’re not getting the beacon root from time X. You’re getting the beacon root that was inserted at time X but originates from an earlier time,” Ritzdorf said.
For a deeper look at the audits completed for EIP 4788 by the above blockchain security companies, refer to this week’s call notes on GitHub.
Holesky Testnet Launch
The Holesky testnet has been relaunched by developers after a previously unsuccessful attempt at spinning up Ethereum’s largest public proof-of-stake testnet supporting 1.4mn validators. The testnet was launched on Thursday, September 29, a few hours before this week’s ACD call. Busa said that the network struggled to finalize during its first initial epochs. However, the network is now progressing with close to 80% participation from validators. Busa’s goal is to boost the network participation rate to 90% by the end of the day. For a live view of the Holesky testnet, check out this blockchain explorer created by the Beaconcha.in data team.
Introducing EIP 7503
Next, developers discussed EIP 7503, which proposes a new privacy solution on Ethereum based on zero-knowledge cryptography that would offer users stronger privacy guarantees for their transactions than cryptocurrency mixers like Tornado Cash. It would also offer users a way to prove the funds in their account have not been obfuscated by the privacy protocol supported by EIP 7503, effectively allowing users to submit a “proof-of-innocence” for their accounts for regulatory and compliance purposes.
A developer on the call with the screen name “David” noted that the application of zero knowledge cryptography for privacy on blockchains and other consumer-focused services is extremely nascent. He noted that almost all major cryptocurrency mixers that use zero-knowledge hashing functions have suffered failures and exploits due to inflation bugs and double-spend behavior. “We’ve seen inflation and double spend bugs in some version of almost every single major mixing technology. I would argue that long-term maybe this is something where we do want to go for various reasons …. But short-term I would advise against using these hash functions that are not relatively tested. Other hash functions have 20 years of testing. We’re starting to sequence them, and we have a better understanding of where we’re at there,” said David.
David encouraged the privacy solution proposed by EIP 7503 and others like it to experiment on Layer-2s and Ethereum’s application layer but advised against enshrining any of these solutions directly on the Ethereum protocol at least in the short-term. Other developers on the call such as Tim Beiko agreed with David’s sentiment. Lukasz Rozmej of the Nethermind client team questioned whether enshrining privacy solutions like EIP 7503 would risk provoking government authorities to sanction or outright ban Ethereum for users. Beiko encouraged further discussion about the EIP on Ethereum Magicians.
Post-Verkle SELFDESTRUCT Behavior
Guillaume Ballet from the Geth client team raised a minor issue in the specification for EIP 6780. Ballet noted that the EIP specifies the behavior of SELFDESTRUCT in a post-Verkle environment. As background, developers are working towards upgrading the data structure of Ethereum such that state is no longer structured through Merkle Patricia Trees (MPT) but rather Verkle Tries, which are comparatively more efficient for nodes to prove. The path forward for the Verkle upgrade has yet to be finalized by developers and will not be included in the forthcoming Dencun upgrade. However, it may be featured in the upgrade after Dencun, Prague/Electra. The specified behavior in EIP 6780 for SELFDESTRUCT after the Verkle upgrade poses issues, Ballet said. He recommended removing the language all together from the EIP and simply noting that the behavior of SELFDESTRUCT will have to be changed again in the future. Developers agreed to make this change in the EIP document and moving forward to try and be more conscientious about the forward-looking statements that are included in an EIP.
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.