Author: Christine Kim, Galaxy; Translated by: Wuzhu, Golden Finance
On September 12, 2024, Ethereum protocol developers met virtually via Zoom for the 196th All Core Developers Executive (ACDE) call. This week, the call was hosted by Tim Beiko, Head of Protocol Support at the Ethereum Foundation (EF). The ACDE call is a bi-weekly meeting series where developers discuss and coordinate changes to the Ethereum Execution Layer (EL).
At ACDE #196, developers shared an update on the Pectra Devnet 3 release and discussed various Pectra code changes to be implemented on the future development network. There was serious discussion about splitting the upgrade into two parts so that they can release code changes on Devnet 3 on a faster timeline, possibly before February of next year. Developers agreed to make a final decision on this at the next ACD call. Finally, an EF Developer Operations Engineer who goes by the username “pk910” shared an update on his work to clean up the Ethereum public testnet GitHub repository and restructure it for easier use.
Pectra Devnet 3
Parithosh Jayanthi, EF DevOps Engineer, presented the release of Pectra Devnet 3. The development network was launched on Wednesday, September 11. It includes fixes for validator merges in EIP 7251 and an updated specification for EIP 7702. Based on testing on Devnet 3 to date, both EIP 7251 and EIP 7702 appear to be functioning as expected. Jayanthi noted that some issues were found in the Nethermind and EthereumJS clients, which both client teams are working to resolve. Jayanthi added that since EIP 7702 is live on Devnet 3, it would be best for wallet developers to test the implementation and provide feedback on their use of it. All information about Pectra Devnet 3, including a 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 trigger requests in Pectra. For background, Pectra will enable smart contracts on EL to initiate validator withdrawals and merges on CL. In the last ACD call, Lange shared a proposal to reduce the amount of work required for EL clients to parse these requests. Since last week's call, Lange has formalized his proposal and the work that EL client teams need to do to update the encoding of the following four EIPs:
EIP 7685, a general execution layer request;
EIP 7002, EL can trigger withdrawals;
EIP 6110, on-chain supply validator deposits;
EIP 7251, increases the maximum effective balance.
Developers generally agree with Lange's proposal. However, Nimbus developer who goes by the online name "Dustin" believes that the proposal is "meaninglessly flexible" and not forward-compatible with future changes to the EL serialization format. He also stressed that additional specifications are needed to explicitly regulate the order of requests from EL clients and the behavior of CL clients when EL submits invalid requests to CL. Lange agrees that more text should be added to the Engine API to specify the order of requests. He also agrees with Dustin that the behavior of CL clients when a CL client detects an invalid request from an EL client should be considered more deeply.
Ethereum Foundation researcher Peter Miller pointed out that according to the logical behavior of CL clients under the current specification, CL clients should reject blocks from EL that are not sorted in the correct way. In addition, if there are invalid requests in the list shared by EL to CL, CL should simply process all valid requests in the list and ignore the invalid requests. Dustin agreed with Miller and suggested that developers specify this behavior in appropriate documents. Beiko said that developers should work on solving the problems in Lange's proposal and complete it before the next ACD call.
Subsequently, Erigon developer Andrew Ashikhmin proposed an update to EIP 7702, setting the EOA account code. He pointed out that the validity check specified in the EIP was inconsistent with the validity check specified in the old EIP. Geth developer Matt Garnett (aka "Lightclient") said he had an alternative proposal to solve the consistency problem and simplify the validity check of EIP 7702. Developers were mostly in favor of finalizing the proposal for Lightclient and adding it to Pectra Devnet 4.
The next Pectra-related discussion was about the pricing of BLS precompiles under EIP 2537. Geth developer Jared Wasinger said that based on his benchmark analysis, BLS precompiles should be priced twice as high as currently specified. Currently, the cost is based on multi-threaded execution, which is not the standard to perform when pricing other precompiles. Therefore, based on his analysis using single-threaded execution, Wasinger suggested changes to the discount table for operations in EIP 2537. The Nethermind team reported that they are working on a tool so that other client teams can easily do their own benchmark analysis of the EIP as well. Beiko suggested that teams do their own benchmarking of BLS precompiles and come back with ideas about re-pricing these operations in the next two weeks.
Pectra EIP Supplement
Developers then began discussing the topic of adding new EIPs for the Pectra upgrade. Beiko opened the discussion by warning, “We already have a lot of EIPs in Pectra. It’s already the largest fork so far in terms of the number of EIPs.” Based on the perspectives developers shared prior to the call, Beiko said it was clear that EIP 7742 (blob count separation between EL and CL) was the least controversial of the list of EIPs still being considered for inclusion in the upgrade.
EF researcher Alex Stokes once again raised the idea of splitting Pectra into two smaller hard forks. "I think everyone agrees that this is a very large fork. So the natural thing to do is to split it in two. Generally, smaller forks are less risky. In particular, Pectra right now has a lot of cross-layer EIPs, which does increase the testing, security, and review burden," Stokes said. Jayanthi, who also raised the idea on a previous call, said he still supports it. "I think the main reason is that at the moment we have a lot of EIPs and we tend to touch many layers of the stack, and the more we add, it becomes difficult for any one person to have a global view of all the changes, even under the current load," Jayanthi said.
Regarding how the current Pectra EIP could be split into two branches, Stokes suggested releasing the first part of Pectra using all the EIPs currently running on the development network, and then releasing the second part of Pectra using PeerDAS, EOF, and some other additional EIPs. The developers are confident that by doing this, they will be able to release the first part of Pectra by February next year. "I think this fork would be a failure if we still only release the first half in June," said EF researcher Ansgar Dietrichs in a Zoom chat.
Beiko favors the idea of forking, but warns against removing any EIPs from the devnet, 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 suggests refining EIPs on Devnet 3 as soon as possible for mainnet activation, and then working in parallel starting with Devnet 4 or 5 to relocate PeerDAS and EOF to the Pectra EIP. In fact, in the upgrade after Pectra, Devnet 4 or 5 will become Devnet 0, and developers are unsure about what to call it.
In a previous call, developers agreed to name the upgrade Pectra Fusaka, but they also agreed to reserve this upgrade for the Verkle transition. On this point, Ferrin advised developers not to pre-order the upgrade until they were confident that the code changes were ready for mainnet activation. This drew the ire of Guillaume Ballet, a Geth developer who has been leading the Verkle transition effort and insisted that the Verkle transition was ready “a long time ago.” In an effort to ease tensions, Beiko said that the purpose of splitting Pectra in two is ultimately to try to release Pectra code changes on a faster timeline, which would help clear the way for the subsequent Verkle transition.
However, there is a risk that the second part of the Pectra upgrade could become larger with more EIPs and therefore take more time to release than the current list of Pectra EIPs could release simultaneously. Nethermind developer Ben Adams questioned how the testing process for Pectra would work if the upgrade was split into two parts. Given that this decision would drastically change the scope of Ethereum's next immediate upgrade, Beiko suggested that developers take a week to consider the idea. He asked developers to be ready to make a final decision on the matter at the full core developer consensus call next Thursday.
Network configuration structure alignment
Last but not least, EF Development Operations Engineer "pk910" shared an update on his work to clean up the Ethereum public testnet GitHub repository and adjust its structure for easier use. He asked the client team to check the node configurations of the Ethereum mainnet and testnet and add any missing information to the corresponding repositories.
