Ethereum All Core Developers Execution Call #161 Writeup
On May 11, Ethereum developers gathered over Zoom for their 161st All Core Developers Execution (ACDE) call. 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 the implementation details of Ethereum Improvement Proposal (EIP) 4844. EIP 4844 is the main code change going into Ethereum’s next upgrade dubbed Cancun on the EL and Deneb on the Consensus Layer (CL). EIP 4844, also called proto-danksharding, introduces a new transaction type, blobs, that are designed for use by Layer-2 rollups. For more information about EIP 4844, refer to the official proto-danksharding website here.
Scope of Cancun Remains Unchanged
To kick off the discussion, Chair of the ACDE calls Tim Beiko summarized the decisions made during prior developer calls about the scope of Cancun. So far, developers have agreed to include the following EIPs alongside EIP 4844:
EIP 6780: Changes the functionality of the SELFDESTRUCT opcode so that the operation sends all ETH in an account to the caller, except when the opcode is called in the same transaction a contract was created.
EIP 6475: A new Simple Serialize (SSZ) type to represent optional values. This makes the implementation of EIP 4844 more future-compatible with a larger forthcoming SSZ update to the EL of Ethereum.
EIP 1153: Adds new opcodes for manipulating state that behaves identically to storage opcodes but is discarded after every transaction.
Beiko asked developers if there were any other EIPs on the consideration list for Cancun that should be added to the above list. There were no suggestions from developers to update the scope of Cancun. Beiko said that changes can still be made to Cancun in the weeks upcoming but without explicit suggestions from developers, the scope of Cancun would remain as is “by default.”
Ironing Out EIP 4844 Implementation Details
Then, developers discussed four outstanding issues regarding EIP 4844 and its implementation across EL/CL clients.
1. EIP 4844 precompile input and output mismatch: Andrew Ashikhmin, developer for the Erigon (EL) client, mentioned that the input format for the EIP 4844 precompile differs from its output. The input uses little-endian, meaning the least significant bytes are stored before the more significant bytes, while the output uses big-endian, where the most significant bytes are stored first. Developers discussed harmonizing the output and input to both rely on big-endian, which is the default method for storage of multibyte data types on the EL. Gajinder Singh, developer for the Lodestar (CL) client, said that he would work on creating this pull request (PR) to resolve the EIP 4844 precompile input and output mismatch.
2. EIP 4844 SSZ serialization format: For weeks, developers have been discussing the most optimal way to serialize the new blob transaction types. Initially, developers had leaned toward introducing an early iteration of the SSZ format to the EL through blob transactions. Eventually, developers plan on upgrading all transaction types from RLP to SSZ but given that the path to upgrading from RLP to SSZ remains unclear and certainly not ready for implementation by Cancun, developers have been weighing the removal of SSZ from EIP 4844, at least from the EL side.
In favor of this proposal, “lightclient,” a pseudonymous developer for the Geth (EL) client, said, “I also just want to be very wary of introducing changes that we think are intermediary. We don’t really know when we’ll be able to make the full change. We don’t know what the full changes might end up looking like and we’ve seen in past forks where we tried to do something that’s more compatible, it ends up not being as forward compatible as we wanted it to be. So that’s why I feel like if we’re not going to go full SSZ and find the right solutions now, it’s probably best to just stick with what we know, which is the RLP type transactions and continue thinking about how to do SSZ later.”
After much discussion, developers agreed to move forward with Lightclient’s proposal to remove SSZ from EL implementation of EIP 4844. Chair of the ACDC calls Danny Ryan emphasized that SSZ encoding, which is the default serialization format on the CL, would be kept in the CL implementation of EIP 4844 regardless. According to Ryan, supporting RLP encoding for EIP 4844 on the EL but not the CL does not require heavy engineering work such as modifying CL data structures. The building blocks for removing SSZ from the EL merely require additional data to be piped through the Engine API, which is the communication standard between EL and CL clients.
3. Explicit clarification on block validity with blob transactions: Mario Vega who is on the testing team at the Ethereum Foundation explained that the current definition of the blob transaction type does not clearly state that blocks should be considered invalid if all hashes in “blob_versioned hashes” do not start with the byte “blob_commitment_version_kzg.” According to Vega, client implementations have already been implicitly following this logic through creating an extra block validity check to review all hashes in “blob_versioned hashes.” However, this block validity condition should be made clear in EIP 4844 specifications. Developers agreed and Vega has since created a dedicated PR for this change on GitHub.
4. EIP 4844 KZG libraries: Fourthly, developers discussed ongoing challenges using KZG libraries for blob commitments. Blobs are transactions that are tied to larger pieces of data, such as batched transactions from Layer-2 rollups. Blob data will not be accessible from Ethereum directly. However, a commitment to the data attached to a blob transaction will be accessible from Ethereum for on-chain verification purposes. There are a variety of ways to generate commitments for blob data. However, one of the most forward-compatible for future scalability upgrades such as data availability sampling (DAS) is the polynomial commitment scheme known as the Kate Zaverucha Goldberg (KZG) commitment scheme.
Despite the powerful capabilities of KZG commitments, there are difficulties using the cryptographic library dedicated to KZG. “Potuz,” a pseudonymous developer for the Prysm (CL) client, said, “This is something that really annoys me because it’s something the Ethereum Foundation paid for and every single client complained [about it] before the launch of the Beacon Chain. … The other comment I want to make which is something that makes me uncomfortable with the status of the cryptography is that it is still changing quite a bit. Things that are non-trivial.” After more discussion on KZG libraries, Beiko recommended that client teams move the conversation offline to the Ethereum R&D Discord channel.
Other EIPs for Cancun Consideration
Then, developers briefly discussed two EIPs for consideration in Cancun.
EIP 6969: A modified version of EIP 1559 that maintains the benefits of transient network congestion management whilst also allowing contract or protocol creators to receive a portion of gas fees consumed by the contract or protocol within a given block. EIP 6969 is authored by Zak Cole, a core contributor to a Layer-1 blockchain focused on supporting decentralized finance applications called Canto. EIP 6969 is primarily targeted at implementation by Layer-2 rollups but can be applied to any network which applies EIP 1559 fee logic.
EIP 5656: An efficient EVM instruction for copying memory areas. EIP 5656 is co-authored by Charles Cooper, a core contributor to a decentralized asset exchange protocol known as Beacon. The EIP is targeted at creating more efficient means of building data structures by improving the functionality of memory copying.
About EIP 6969, developers discussed whether code changes to Layer-2 rollups should be discussed on ACD calls at all. About EIP 5656, Beiko said that developers should think about what other small EIPs like the one presented by Cooper could potentially be included in Cancun. Beiko said developers would revisit discussions around these two EIPs during a future call.
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.