Ethereum All Core Developers Execution Call #163 Writeup
On June 8, Ethereum developers gathered over Zoom for All Core Developers Execution (ACDE) call #163. 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 a potential change to the maximum number of blobs per block under Ethereum Improvement Proposal (EIP) 4844. They agreed to include EIP 4788 and EIP 5656 to the Cancun/Deneb upgrade and with the addition of these two EIPs, finalized the scope of Cancun.
The next Ethereum upgrade will include five code changes:
EIP 4844: Shard blob transactions
EIP 6780: SELFDESTRUCT only in the same transaction
EIP 1153: Transient storage opcodes
EIP 4788: Beacon block root in the EVM
EIP 5656: Memory copying instruction
All other proposed EIPs from prior calls have been rejected for the Cancun upgrade but may be reconsidered for a different upgrade in the future.
EIP 4844 Blob Limit
During ACDC #110, Ethereum Foundation researcher Dankrad Feist proposed increasing the maximum number of blobs per block under EIP 4844 from 4 to 6, and subsequently, increasing the blob target from 2 to 3. As background, blobs are a new type of transaction on Ethereum that post Cancun will offer a transient storage space for Layer-2 rollup operators. Feist conducted a data experiment on Ethereum to see how the network would respond to processing large blocks, that is blocks with an additional data load of anywhere between 1kB to 1MB. Feist said that sustained loads of up to 10 large blocks in a row were “no problem” for the network. Therefore, the blog target could safely be adjusted and increased.
While some developers on the call like Alex Stokes and Ansgar Dietrichs were in support of the change, others were more wary, saying the change would make certain types of denial-of-service (DoS) attacks on Ethereum less costly. “I still think this attack is extremely costly and cannot be sustained for very long,” said Geth (EL) developer Marius van der Wijden about the potential for a DoS attack. “But we just have to be clear about this. We’re making this more possible than it is right now and with increased blob count, we make it even easier to do. So my suggestion would be to start with 2/4, which is already kind of high in most cases and then if we see that this works reliable or can maintain it for a long time, we can increase it.”
Feist pushed back on van der Wijden’s comments saying that the developers on the call were “always much more conservative” on new code changes than existing standards and practices that is in view are already “pretty DoS-able.” Feist added, “It seems not fair that suddenly all core developers override the Ethereum community on this in the case of blob [limit increase].” Given the disagreement, Beiko recommended continuing the discussion on the EIP 4844 Implementors’ Call on Monday, June 12. Developers also agreed to increase the blob limit from 2/4 to 3/6 as Feist suggested for the next dedicated test network for EIP 4844, Devnet 6. Client teams are working towards relaunching Devnet 6 with updated software versions next week.
Final Cancun Scope
Developers finalized the scope of Cancun on ACDE #163. They agreed to include EIP 4788, which will expose data about the Beacon Chain to the EL for permissionless access by smart contracts. Developers agreed to design the EIP in such a way that the code change has bounded storage growth at roughly 80MB per year. EIP 5920, which would introduce a new opcode, PAY, to send ether to an address without calling any of its functions, was rejected from Cancun due to a lack of consensus among developers for the urgency or need for the opcode. EIP 5656, which introduces an instruction for copying memory areas in the Ethereum Virtual Machine (EVM), was accepted due to its simplicity and ease of implementation. That said, Beiko emphasized that EIP 5656 may be dropped from the upgrade if client teams run into difficulties preparing the code change for Cancun alongside the other four comparatively more higher priority code changes.
Miscellaneous
Other topics discussed on ACDE #163 included:
Engine API versioning: As discussed on ACDC #110, developers will move towards a one method, one structure approach for Engine API V3 to reduce the complexity of maintaining multiple versions of the same API method. The developer championing this approach, Mikhail Kalinin, encouraged interested client teams to review his proposal.
Honest validator duties: Teku (CL) developer Enrico Del Fante raised questions about how nodes should process blobs under EIP 4844 and more specifically, whether blobs should be processed prior to sending attestations. Chair of the ACDC meetings Danny Ryan said that he would create a pull request (PR) on GitHub to clarify the behavior and discuss the matter further on the next ACDC meeting.
Holesky Testnet Launch Coordination Call #0: Finally, Barnabas Busa, a DevOps Engineer at the Ethereum Foundation, gave a reminder about an upcoming coordination call for the Holesky test network. The Holesky testnet is meant to replace the Goerli testnet by the end of 2023. The goal is to make it larger in size in terms of the number of validators than both Goerli and Ethereum mainnet. Developers are tentatively looking at launching Holesky no later than September around the time of the Cancun upgrade. To discuss all these details, Busa asked at least one person from every Ethereum client team to participate in the call on Thursday, June 15.
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.