Ethereum ACDE meeting: Code changes may be released on Devnet3 next year

Pectra Devnet 3

EF DevOps engineer Parithosh Jayanthi presented the release of Pectra Devnet 3. The development network was launched on Wednesday, September 11. It includes fixes for validator merging 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, and that the two client teams are working to resolve these issues. Jayanthi added that as EIP 7702 goes live on Devnet 3, it would be a good idea 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 Spec Updates

Geth developer Felix Lange has proposed a change to the encoding of EL trigger requests in Pectra. For background, Pectra will enable smart contracts on EL to initiate withdrawals and merges from validators 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, Generic Execution Layer Requests;

EIP 7002, EL Triggerable Withdrawals;

EIP 6110, On-Chain Supply Validator Deposits;

EIP 7251, Increase Maximum Valid Balances.

Developers generally agree with Lange’s proposal. However, a Nimbus developer who goes by the handle “Dustin” believes that the proposal is “meaninglessly flexible” and is not forward-compatible with future changes to the EL serialization format. He also stressed that additional specifications are needed to clearly regulate the order of requests from EL clients and the behavior of CL clients when EL submits invalid requests to CL. Lange agreed to add more text to the Engine API to specify the order of requests. He also agreed with Dustin that the behavior of CL clients when CL clients detect invalid requests from EL clients 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 ordered 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 request. 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 noted that the validity checks specified in the EIP were inconsistent with the validity checks specified in the old EIP. Geth developer Matt Garnett (aka “Lightclient”) said he had an alternative proposal to resolve the consistency issue and simplify the validity checks for EIP 7702. Developers were mostly in favor of finalizing the Lightclient proposal and adding it to Pectra Devnet 4.

The next Pectra-related discussion was about pricing for BLS precompiles under EIP 2537. Geth developer Jared Wasinger said that based on his benchmark analysis, BLS precompiles should be twice as expensive as they are currently priced. Currently, the cost is based on multi-threaded execution, which is not the standard that is used 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 also easily do their own benchmark analysis of the EIP. Beiko suggested that teams do their own benchmarking of BLS precompiles and come back with ideas about repricing these operations within the next two weeks.

Pectra EIP Additions

Developers then began discussing the topic of adding a new EIP for the Pectra upgrade. To kick off the discussion, Beiko warned, "We already have a large number of EIPs in Pectra. It's already the largest fork to date in terms of the number of EIPs." Based on the views shared by developers 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, we tend to touch many layers of the stack, and the more we add, the harder it is 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 EIPs 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 of 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 favored the idea of a fork, but warned against removing any EIPs from the development network, 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 suggested refining the EIP on Devnet 3 as soon as possible for mainnet activation, and then working in parallel from Devnet 4 or 5 to relocate PeerDAS and EOF to the Pectra EIP. In fact, Devnet 4 or 5 will become Devnet 0 in the upgrade after Pectra, and developers are unsure about how to name it.

In a previous call, developers agreed to name the upgrade after Pectra Fusaka, but they also agreed to reserve this upgrade for the Verkle transition. On this point, Ferrin suggested that developers should not pre-order the upgrade before they are sure that the code changes are ready for mainnet activation. This has angered Geth developer Guillaume Ballet, who has been leading the Verkle transition work and insisted that the Verkle transition was ready "a long time ago." In an effort to ease tensions, Beiko said the purpose of splitting Pectra in two is ultimately to try to release Pectra code changes on a faster timeline, which could help clear the way for a subsequent Verkle transition.

However, there is a risk that the second part of the Pectra upgrade could become larger with more EIPs, and therefore require more time to be released than if the current Pectra EIP list were released simultaneously. Nethermind developer Ben Adams questioned how the testing process for Pectra would proceed 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 during the all-core developer consensus call next Thursday.

Network Configuration Structure Alignment

Last but not least, EF DevOps 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 client teams to check the node configurations of the Ethereum mainnet and testnet and add any missing information to the corresponding repositories.