Ethereum All Core Developers Execution Call #193 Writeup

On August 1, 2024, Ethereum protocol developers met virtually over Zoom for All Core Developers Execution (ACDE) Call #193. Chaired by Ethereum Foundation (EF) Protocol Support Lead 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 shared updates on testing progress for the Pectra upgrade. Developers are continuing to fix bugs on Pectra Devnet 2. They decided to postpone a decision on the inclusion of EIP 7212 in Pectra until existing code changes slated for the upgrade are further along in the implementation and testing process.

They also discussed how Ethereum should start preparing for the advent of quantum computers and a new Ethereum Improvement Proposal (EIP) for implementation alongside or after the Verkle transition which would activate state expiry.

Finally, EF Developers Operations Engineer Parithosh Jayanthi shared updates on his proposal to distribute Ethereum history through torrents under EIP 4444.

Pectra Devnet 2

On Tuesday, July 30, the EF DevOps team relaunched Pectra Devnet 2, which featured minimal spec changes from Pectra Devnet 1. Jayanthi noted that due to the issues created by the first version of Pectra Devnet 2, where EIP 7702 transactions resulted in a few chain splits on the network, the relaunched devnet will not test EIP 7702 transactions. Developers agreed later on the call to update EIP 7702 implementations for the next devnet, and start testing the code changes in earnest on Devnet 3.

Jayanthi said, at a high level, the Erigon client faced a block production issue on Devnet 2 that has since been fixed. Prysm and Reth clients also face a few issues that the client teams are looking into it. Grandine stopped finalizing for a period on Devnet 2 for unknown reasons which developers are investigating.

On the topic of including EOF code changes in the next devnet launch, independent Ethereum protocol developer Danno Ferrin shared that he'd like to see EOF testing on Kurtosis first before adding the EIPs to Pectra devnets. Mario Vega, who is on the EF testing team, added that test cases for EIP 7702 and EOF still need to be written and that he is worried about the interactions between these code changes and the rest of the Pectra EIPs.

EIP 7702

For months, developers have debated the design of EIP 7702, which is a code change to enable greater programmability for user-controlled accounts, also called externally owned accounts (EOA). Based on discussions from a recent EIP 7702 breakout meeting, developers agreed to keep the design of EIP 7702 unchanged. Nethermind developer Ahmad Mazen Bitar noted that there may be minor changes to the EIP proposed once EOF code changes are further along in the implementation and testing process. However, Bitar emphasized that these changes are not critical to EIP 7702 now and developers should first continue with implementations of EIP 7702 and EOF on devnets before moving forward with any material changes to specifications. Beiko said that EIP 7702 based on its latest specifications should be added to the next Pectra devnet, Devnet 3.

EIP 6110

Then, a developer on the Geth team by the screen name "Felix" raised a proposal to serialize validator deposit requests on the EL in Simple Serialize (SSZ) format instead of relying on recursive-length prefix (RLP) serialization as the additional work to decode deposit requests on the EL in RLP creates unnecessary protocol complexity. He explained, "It's a bit silly to have all this complexity on the API layer when these objects ultimately have to be handled as SSZ on the [consensus layer]. So, we thought that maybe it would be wise to just handle them as SSZ all the way. So, basically make the execution layer in charge of encoding them as SSZ. ... The downside to this proposal is just that the execution layer will now have to perform the SSZ encoding, which they haven't really had to do before. However, we will have to start using SSZ at some point. So, we feel like this is very minimal entry into the world of SSZ for the EL."

Teku developer Mikhail Kalinin said that he would rather continue to rely on JSON encoding on the EL until developers are ready to make a full transition to SSZ libraries for all requests. Beiko also recommended keeping the JSON encoding for deposit requests since all EL client teams have already implemented EIP 6110 in this way on Pectra devnets. Once Pectra EIPs are in a more finalized state for implementation, Beiko said developers can revisit putting in the work to update the way the EL handles deposit requests. Eventually, Felix noted developers should put in the work to convert all aspects of the Engine API to SSZ.

Engine API Specification for "engine_getBlobsV1"

The Engine API, which dictates communication with the Ethereum EL and CL, has a new method called "getBlobsV1". The purpose of this method is to enable CL clients to fetch blobs from the EL blob transaction mempool. As an optional optimization for CL clients, Kalinin noted that it is now up to client teams to start utilizing and incorporating into their implementations. Teku developer Enrico del Fante mentioned that there are ways CL clients may abuse this method. Prysm developer "Potuz" recommended specifying certain behaviors when calling this method for CL clients. Beiko suggested opening a new pull request on GitHub to address concerns and update CL specifications. He said that the discussion should be raised again on next week's ACDC call and potentially incorporated into testing on Pectra Devnet 3.

EIP 7212

EIP 7212 is a precompiled contract that performs signature verification in the "secp256r1" elliptic curve. Without the precompile which creates a fixed gas cost of these types of operations on-chain, the operations would be prohibitively expensive for smart contract developers to use. The "secp256r1" elliptic curve is specifically used in modern devices such as Apple and Android devices, which is why it is an important piece of cryptography that Ethereum Layer-2 rollups have already widely implemented to improve the user experience on their protocols.

For months, developers have been weighing the potential inclusion of EIP 7212 on Ethereum mainnet. This would create greater compatibility between the wallets and services built atop Layer-2 protocols and Ethereum. Representatives from the Nethermind, Erigon, and Besu teams were in favor of including EIP 7212 in Pectra, as was EF Researcher Ansgar Dietrichs and Ulaş Erdoğan, co-founder of smart contract wallet Clave.

Geth developer "Lightclient" recommended refraining from including EIP 7212 in Pectra until other Pectra EIPs are further along in the testing process. "7212 is very easy to do, but we're not on top of Pectra right now, and it doesn't feel like the time right now is a good time to be adding additional stuff onto it, regardless of the simplicity," said Lightclient. Other developers on the call agreed with this approach, though Dietrichs asserted that in his view it was "unrealistic" that in three months any additional EIPs would be added to Pectra.

Vega recommended additional support from EIP 7212 champions in building out test coverage for the code changes. He said that this would help make the case for including EIP 7212 in Pectra. Erdoğan agreed to work on this. Beiko reiterated that developers will reconsider the inclusion of this EIP in Pectra after they are able to make more progress on the rest of the Pectra EIPs.

Quantum Resistance Attacks

Erigon developer Andrew Ashikhmin said that Vitalik Buterin's talk at the Ethereum conference EthCC raised several questions about how Ethereum may be forced to change in drastic ways in the event of quantum computers. Buterin apparently highlighted in his talk that quantum computing experts forecast the ability of quantum computers to break non-trivial cryptography in the 2030's. In this case, Ashikhmin said that developers should consider changes to the upcoming Verkle transition so that the cryptography introduced in this massive change to Ethereum's data structure will not be broken and require another update in five years. Dietrichs added in the Zoom chat that there has been a "shift" in thinking about Verkle in his view that is opening the door to conversations about alternative data structures.

Felix said that quantum computers pose a threat not only to Verkle data structures but also other important aspects of the Ethereum protocol that rely on elliptic curbe cryptography. Geth developer Guillaume Ballet said that he is skeptical about quantum computers being functional in the next decade and added that the Verkle transition should not be thought of as the last major change to Ethereum's data structure. "We will have to upgrade the tree no matter what. This is not the last time we upgrade the tree and the advantage of Verkle is that we are currently developing all the techniques to update the tree, which can be reused later on," said Ballet.

EF Researcher Joshua Rudolf recommended that developers discuss Ethereum's pathway for becoming quantum resistant and the optimal data structures for Ethereum over the long run as two separate conversations. Beiko agreed with this sentiment and recommended that developers continue the discussion on the quantum resistance of Ethereum in the cryptography channel of the Ethereum R&D Discord. For discussions on alternative data structure designs to Verkle, Ballet and Beiko recommended the Verkle Implementors breakout calls. The next one is scheduled to occur on August 12.

EIP 7736

Nethermind developer Wei Han Ng introduced a new EIP for implementing state expiry on Ethereum that could be coupled with the Verkle transition. The proposal introduces new constants or variables on Ethereum to keep track of what parts of Ethereum state is "active" or "expired". The proposal also introduces new transaction types to enable the recovery of expired parts of Ethereum state. The EIP can be read in more detail here.

Ng noted that the proposal does not bound the size of Ethereum state but ensures that state grows at a slower rate. He said that more analysis is needed to accurately assess state growth reduction under EIP 7736. He encouraged review and feedback on the proposal from developers.

EIP 4444

On the topic of history expiry, Jayanthi noted that he has updated his proposal on using torrents for the retrieval of expired or pruned history data. He asked developers to review the updates and chime in with feedback on this post.

Public link

Please use the above public link if you want to share this noodl on another website.