Column
Ethereum All Core Developers Execution Call #196 Writeup
Summary: On September 12, 2024, Ethereum protocol developers met virtually over Zoom for All Core Developers Execution (ACDE) Call #196. This week, the call was 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. On ...
On September 12, 2024, Ethereum protocol developers met virtually over Zoom for All Core Developers Execution (ACDE) Call #196. This week, the call was 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.
On ACDE #196, developers shared updates on the launch of Pectra Devnet 3 and discussed various Pectra code changes for implementation on future devnets. They seriously debated splitting the upgrade into two so that they can ship the code changes on Devnet 3 on a faster timeline, potentially by February next year. Developers agreed to reach a final decision about this on the next ACD call. Finally, an EF developer operations engineer by the screen name “pk910” shared updates on his work to clean up the Ethereum public testnet GitHub repositories and align their structures for easier usability.
Pectra Devnet 3
EF developer operations engineer Parithosh Jayanthi gave an update on the launch of Pectra Devnet 3. The devnet was launched on Wednesday, September 11. It includes fixes to validator consolidations in EIP 7251 and the updated specifications for EIP 7702. Based on testing so far on Devnet 3, both EIP 7251 and EIP 7702 appear to be working as expected. Jayanthi noted that there were issues discovered in the Nethermind and EthereumJS clients, which these respective client teams are working to resolve. Jayanthi added that since EIP 7702 is live on Devnet 3, it would be ideal to have wallet developers test out the implementation and provide their feedback on its use. All the information about Pectra Devnet 3, including the faucet to request testnet ETH, can be found on this website.
Pectra Specification Updates
Geth developer Felix Lange has proposed changes to the encoding of EL-triggered requests in Pectra. As background, Pectra will enable smart contracts on the EL to initiate validator withdrawals and consolidations on the CL. During the last ACD call, Lange shared a proposal to reduce the amount of work needed by EL clients to parse through these requests. Since last week’s call, Lange has formalized his proposal and the work that will be needed from EL client teams to update the encoding of the following four EIPs:
-
EIP 7685, General purpose execution layer requests
-
EIP 7002, EL triggerable withdrawals
-
EIP 6110, Supply validator deposits on chain
-
EIP 7251, Increase maximum effective balance
Developers were largely in agreement with Lange’s proposal. However, a Nimbus developer with the screen name “Dustin” argued that the proposal was “pointlessly flexible” and not forward compatible with future changes to the serialization format of the EL. He also stressed that additional specifications are needed that clearly formalize the ordering of requests by the EL clients and the behavior of CL clients if an invalid request is submitted by the EL to the CL. Lange agreed to add more text to the Engine API to specify the ordering of requests. He also agreed with Dustin that deeper thought should be given to the behavior of CL clients in the event an invalid request from the EL client is detected by the CL client.
Ethereum Foundation Researcher Peter Miller pointed out that according to the logical behavior of CL clients under current specifications, CL clients should reject blocks from the EL that are not ordered in the correct way. Further, if there is an invalid request in the list that is shared by the EL to the CL, the CL should simply process all valid requests in the list and ignore the ones that are invalid. Dustin agreed with Miller and recommended that developers specify this behavior in appropriate documentation. Beiko said that developers should aim to resolve issues with Lange’s proposal and finalize it by next ACD call.
Then, Erigon developer Andrew Ashikhmin proposed an update to EIP 7702, set EOA account code. He noted that the validity checks specified in the EIP are not consistent with the validity checks specified in older EIPs. Geth developer Matt Garnett, also known as “Lightclient”, said that he has an alternative proposal to address the consistency issue and simplify the validity checks on EIP 7702. Developers were largely in favor of finalizing Lightclient’s proposal and adding it into Pectra Devnet 4.
The next Pectra-related discussion was about the pricing for BLS precompiles under EIP 2537. Geth developer Jared Wasinger said that based on his benchmarking analysis, BLS precompiles should be twice as expensive as what is currently specified. Currently, the costs are based on multithreaded execution, which is not the standard for execution when pricing other precompiles. So, based on his analysis using single threaded execution, Wasinger has proposed changes to the discount table for the operations in EIP 2537. The Nethermind team reported that they are working on a tool so that other client teams can also easily perform their own benchmarking analysis on the EIP. Beiko recommended that teams perform their own benchmarking on BLS precompiles and chime in with their thoughts about repricing these operations over the next two weeks.
Pectra EIP Additions
Developers then moved on to the topic of adding new EIPs to the Pectra upgrade. When kicking off the discussion, Beiko warned, “We already have a ton of EIPs in Pectra. It is by far already the biggest fork by number of EIPs [included].” Based on sentiments shared by developers before the call, Beiko said it was clear that EIP 7742, the uncoupling of blob count between the EL and CL, was the least contentious on the list of EIPs still considered for inclusion in the upgrade.
EF Researcher Alex Stokes raised again the idea to split Pectra into two smaller hard forks. “I think everyone agrees that it's a really big fork. So, a natural thing to do is just to break it into two. Generally, smaller forks are less risky. In particular, with Pectra right now, there are a bunch of cross layer EIPs, which really raises the testing, security, and review load,” said Stokes. Jayanthi, who had also raised this idea on prior calls, said that he is still in favor of this idea. “I think the main reasoning is that currently, we have a lot of EIPs, and we're tending to touch many, many layers of the stack, and the more we add slash, even with the current load, it's hard for any one person to have a global view of all the changes,” said Jayanthi.
About the way current Pectra EIPs could be split across two forks, Stokes recommended shipping the first part of Pectra with all the EIPs currently live on devnets and then shipping the second part of Pectra with PeerDAS, EOF, and a few other additional EIPs. Developers felt confident that in doing so they would be able to ship the first part of Pectra by February next year. “I think a split where we still only ship the first half in say June would be a failure,” said EF Researcher Ansgar Dietrichs in the Zoom chat.
Beiko was in favor of the idea to split the fork but cautioned against removing any EIPs from devnets, as this could create more work for client teams and extend, rather than shorten, the timeline for preparing these code changes for mainnet activation. Independent Ethereum protocol developer Danno Ferrin recommended polishing the EIPs live on Devnet 3 for mainnet activation as soon as possible and then beginning work in parallel to rebase PeerDAS and EOF on Pectra EIPs starting from Devnet 4 or 5. In effect, Devnet 4 or 5 would become Devnet 0 for the upgrade after Pectra, which developers were not confident about how to name.
On a prior call, developers had agreed to name the upgrade after Pectra Fusaka but they had also agreed to reserve this upgrade for the Verkle transition. About this, Ferrin recommended that developers refrain from reserving upgrades in advance before they are confident about code change readiness for mainnet activation. This drew ire from Geth developer Guillaume Ballet who has been leading efforts on the Verkle transition and who maintained that the Verkle transition was ready “a long time ago.” To diffuse tensions, Beiko said that the point of splitting Pectra in two was ultimately to try and ship Pectra code changes on a faster timeline, which is beneficial for clearing the way for the Verkle transition thereafter.
However, there is the risk that the second part of the Pectra upgrade could become larger with the addition of more EIPs and thereby take more time to ship than if the current list of Pectra EIPs were all shipped in tandem. Nethermind developer Ben Adams questioned how the testing process for Pectra would proceed if the upgrade was split in two. Given that this is a decision that would drastically change the scope of the next immediate upgrade on Ethereum, Beiko recommended that developers take a week to think over the idea. He asked that developers be ready to make a final decision about this on next Thursday’s All Core Developers Consensus call.
Network Configuration Structure Alignment
Last but not least, EF developer operations engineer “pk910” shared updates on his work to clean up the Ethereum public testnet GitHub repositories and align their structures for easier usability. He asked client teams to review their node configurations for Ethereum mainnet and testnets and add any missing information to the respective repos.
Tags: Insights Research
Link: Ethereum All Core Developers Execution Call #196 Writeup [Copy]