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.