jakiro
Author: Christine Kim, Galaxy; Compilation: Wuzhu, Bitchain Vision
On September 12, 2024, Ethereum protocol developers held the 196th All-Core Developer Execution (ACDE) conference call through Zoom virtual meeting.This week, the conference call was hosted by Tim Beiko, head of agreement support at the Ethereum Foundation (EF).The ACDE conference call is a biweekly conference series where developers discuss and coordinate changes to the Ethereum Execution Layer (EL).
On ACDE #196,The developers shared the latest updates released by Pectra Devnet 3 and discussed various Pectra code changes implemented on the development network in the future.They seriously discussed breaking the upgrade into two parts so they could post code changes on Devnet 3 on a faster schedule (probably by February next year).The developer agreed to make a final decision on this on the next ACD conference call.Finally, an EF developer operations engineer named “pk910” shared the latest developments in his work on cleaning up the Ethereum public testnet GitHub repository and tweaking its structure for easier use.
Pectra Devnet 3
EF development and operations engineer Parisosh Jayanthi introduced 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 updated specifications for EIP 7702.Based on tests on Devnet 3 so far, both EIP 7251 and EIP 7702 seem to be working as expected.Jayanthi noted that there were some issues found in the Netherlands and EthereumJS clients, and both client teams are working to address them.Jayanthi added that since EIP 7702 is online in Devnet 3, it is best to have wallet developers test the implementation and provide feedback on their use.All information about Pectra Devnet 3, including the taps requesting testnet ETH, can be found on this website.
Pectra specification update
Geth developer Felix Lange has proposed changes to the encoding of EL trigger requests in Pectra.As a background, Pectra will enable smart contracts on EL to initiate validator withdrawals and mergers on CL.During the last ACD call, Lange shared a suggestion to reduce the amount of work required by EL clients to resolve these requests.Since last week’s conference call, Lange has formalized his recommendations and the work the EL client team needs to do to update the encoding of the following four EIPs:
-
EIP 7685, general execution layer request;
-
EIP 7002, EL can trigger withdrawals;
-
EIP 6110, on-chain supply validator deposit;
-
EIP 7251, increase the maximum effective balance.
The developers generally agreed with Lange’s proposal.However, Nimbus developers, whose web titled “Dustin”, believed that the proposal was “meaninglessly flexible” and was not forward compatible with future changes in the EL serialization format.He also stressed that additional specifications are needed to clarify the order of requests for EL clients and the behavior of CL clients when EL submits invalid requests to CL.Lange agrees to add more text to the Engine API to specify the order of requests.He also agrees 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 based on the logical behavior of CL clients under the current specification, CL clients should reject blocks from ELs that are not sorted in the correct way.Additionally, if there are invalid requests in the list shared by the EL to the CL, the CL should simply process all valid requests in the list and ignore invalid requests.Dustin agrees with Miller and advises developers to specify this behavior in the appropriate documentation.Beiko said developers should work on solving problems in the Lange proposal and complete it before the next ACD call.
Then,Eragon developer Andrew Ashikhmin proposed an update to EIP 7702, setting up the EOA account code.He noted 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 has an alternative to address consistency issues and simplify the effectiveness check of EIP 7702.Most developers favor finalizing the proposal for Lightclient and adding it to Pectra Devnet 4.
The next discussion related to Pectra is about pricing for BLS precompilation under EIP 2537.Geth developer Jared Wasinger said that according to his benchmark analysis, the price of BLS precompilation should be twice as high as currently stipulated.Currently, the cost is based on multi-threaded execution, which is not a standard for pricing other precompiled execution.Therefore, based on his analysis using a single thread, Wasinger recommends making changes to the discount tables operated in EIP 2537.The Netherlands team reported that they were developing a tool so that other client teams could easily perform their own benchmarking analysis of EIPs as well.Beiko advises the team to carry out their own benchmarks for BLS precompilation and to come up with ideas on repricing these operations over the next two weeks.
Pectra EIP Supplement
The developers then began to discuss the topic of adding new EIPs to the Pectra upgrade.At the beginning of the discussion, Beiko warned: “We already have a large amount of EIP in Pectra. It is by far the largest fork in terms of the number of EIPs.” According to the views shared by developers before the call, Beiko saidIt is obvious that EIP 7742 (the separation of blob counts between EL and CL) is the least controversial list of EIPs that are still being considered for inclusion in the upgraded list.
EF researcher Alex Stokes once again proposed the idea of splitting Pectra into two smaller hard forks.”I think everyone agrees that it’s a very big fork. So the natural thing to do is to split it in two. Usually, the risk of smaller forks is less. In particular, there are a lot of cross-layers in Pectra right nowEIP, that really adds to the testing, security and review burden,” Stokes said.Jayanthi also proposed the idea on a previous conference call, which he said he still supports.“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, it’s hard for anyone to have a global understanding of all changes even under the current load.”Jayanthi said.
Regarding the way that the current Pectra EIP can be divided into two branches, Stokes recommends using all EIPs currently running on the development network to publish the first part of Pectra, and then using PeerDAS, EOF, and some other additional EIPs to publish the second part of Pectra.Developers are confident that by doing so, they will be able to release the first part of Pectra by next February.“I think if we still only release the first half in June, then this fork would be a failure,” EF researcher Ansgar Dietrichs said in a Zoom chat.
Beiko favors the idea of forking, but warns against removing any EIP from the development network, as this may bring more work to the client team and extend rather than shorten the timeline for preparing these code changes to activate the mainnet.Danno Ferrin, an independent Ethereum protocol developer, recommends improving EIP on Devnet 3 as soon as possible to activate the mainnet, and then working in parallel from Devnet 4 or 5, relocating PeerDAS and EOF to Pectra EIP.In fact, in the upgrade after Pectra, Devnet 4 or 5 will become Devnet 0, and developers are not sure about how to name it.
On a previous conference call, developers agreed to name the upgrade after Pectra Fusaka, but they also agreed to keep the upgrade for Verkle transition.Regarding this, Ferrin advises developers not to book an upgrade in advance until they are sure that the code changes are ready for mainnet activation.This has caused anger from Geth developer Guillaume Ballet, who has been leading the Verkle transition and insists that the Verkle transition was ready “long ago”.To ease tensions, Beiko said the goal of splitting Pectra in two is ultimately to try to release Pectra code changes on a faster timeline, which will help clear the way for the Verkle transition thereafter.
However,There is a risk that the second part of the Pectra upgrade may become larger as more EIPs are added, so it will take more time to release than the current Pectra EIP listings are simultaneously released.Nethermind developer Ben Adams questioned,If the upgrade is divided into two parts, how will the Pectra test process proceed.Given that this decision will revolutionize the scope of Ethereum’s next immediate upgrade, Beiko advises developers to spend a week thinking about this idea.He asked developers to prepare for a final decision on the matter on next Thursday’s consensus call for all core developers.
Network configuration structure alignment
Last but not least, EF Dev Operations Engineer “pk910” shared his work update to clean up the Ethereum public testnet GitHub repository and tweak its structure for easier use.He asked the client team to check the node configuration of the Ethereum mainnet and testnet and add any missing information to the corresponding repository.
