Author: Christine kim

Compiled by: Vernacular Blockchain

On January 16, 2025, Ethereum protocol developers held the 203rd All Core Developers Execution (ACDE) meeting via Zoom. This week's meeting was hosted by Tim Beiko, head of protocol support at the Ethereum Foundation (EF). The ACDE meeting is a biweekly meeting series where developers discuss and coordinate changes to the Ethereum Execution Layer (EL).

At the 203rd ACDE meeting, developers discussed the launch of Pectra Devnet 5 and the pending Pectra specification updates. They also discussed the next steps for testing the gas limit increase on the Holesky testnet, progress on RPC standardization, and the specification of minimum hardware and bandwidth requirements for nodes.

1. Pectra Devnet 5 startup

Developers launched Pectra Devnet 5 half an hour before the meeting. Parithosh Jayanthi, a developer operations engineer at the Ethereum Foundation, said he found gas estimation issues in the development network and planned to collect relevant logs and share the issues in the Ethereum R&D Discord channel.

2. Pectra specification update

Developers discussed five pending updates to the Pectra coding standards:

1) EIP 7623: Increase Calldata Cost The first update is a modification to EIP 7623 to clarify how Gas refunds are handled. This update has been merged on GitHub and incorporated into the testing of Pectra Devnet 5.

2) EIP 7840: Add Blob Scheduling to Execution Client Profile The second update concerns the base fee fraction in EIP 7840. There were no objections at the meeting, and the developers agreed to merge the relevant changes into GitHub before the Pectra testing meeting on January 20 (next Monday).

3) Update of Blob Base Fee The third update is also related to Blob Base Fee, which involves how to calculate excess Gas during Pectra activation. Alex Stokes, head of research at the Ethereum Foundation, explained that the calculation depends on the information of the previous block header. If the change in Blob capacity is activated on the fork boundary (Pectra activation block), the excess Gas calculation will be based on the information of the previous block built using the old fork rules. Stokes believes that it is necessary to clarify whether the Blob capacity increase is activated at the fork boundary or one block after the fork boundary. He said: "It doesn't matter which way you choose, but we need to unify the approach." The developers unanimously agreed to clarify EIP 7691, setting the effective time of the Blob capacity increase to one block after the fork boundary, so that only the new fork rules are used for calculation. Ethereum test developer Mario Vega said that the client is testing this logic. Geth developer "Lightclient" promised to update EIP 7691 before the test meeting next Monday.

4) EIP 2537: Precompiled cost calculation for BLS12-381 curve operations The fourth update is related to the multiplication cost calculation in EIP 2537. Developers agreed to explicitly specify the calculation as integer division in the EIP. Client teams that have passed the Pectra Devnet 5 test should have implemented this logic in the code, so only the specification needs to be modified. Ethereum virtual machine developer Paweł Bylica said that he will make changes to the EIP on GitHub and complete it before the test meeting next Monday.

With these updates, developers continue to improve and coordinate work on Pectra, paving the way for future Ethereum mainnet upgrades.

5) Finally, the fifth update is related to EIP 7702, which aims to add a new transaction type that allows external accounts (EOAs) to set code permanently. Julian Rachman, COO of Otim Labs, proposed a behavioral modification to this EIP, which is to enable code introspection. According to the document written by the Otim Labs team, code introspection refers to the ability of legacy contracts to examine their own bytecode or the bytecode of external contracts and adjust their behavior based on that information.

Although the Ethereum Virtual Machine Object Format (EOF) development team plans to disable code introspection in future Ethereum upgrades, it is mentioned in documents and meetings that enabling code introspection to check the "delegate_address" of EOA will not hinder the development of EOF. The benefit of allowing code introspection to check the delegate address of EIP 7702 type transactions is that it supports the safe use of relayers and other external accounts when EIP 7702 features (such as Gas sponsorship) are enabled.

Geth developer "Lightclient" supports the inclusion of this update in the Pectra specification. He said: "This update is very easy to implement. We are already determining whether the account is an EIP 7702 delegate account, and it is very simple to add a specified return address." Meeting moderator Beiko suggested that participants spend a few more days reviewing the changes before deciding whether to include them in the final specification. He suggested revisiting this topic at the testing meeting next Monday.

Beiko also asked Rachman's team to formally submit a pull request containing all EIP 7702 modification proposals on GitHub for developers to discuss on Monday. As for whether this update requires developers to launch a new Pectra development network for testing, Jayanthi said that the change can be included in the shadow fork of the public test network without launching a new development network. Beiko added that all other specification updates discussed in this meeting also do not require a new Pectra development network, so developers can continue to advance the update of the public test network after further testing of Pectra Devnet 5 is completed.

3. Pectra system contract audit update

Fredrik Svantes, protocol security researcher at the Ethereum Foundation (EF), said that all third-party audits of the Pectra system contracts have been completed. The audit found no major issues, and the relevant reports will be uploaded to GitHub for the client team to review. Svantes suggested that a special time be arranged in the next ACDE meeting for auditors to present their audit results and answer questions from the client team.

4. Pectra test network upgrade plan

Tim Beiko proposed a preliminary timetable for testnet upgrades. He suggested that the next two ACD meetings determine the block heights for upgrading the Sepolia and Holesky testnets, and prepare the client release version before February 3, 2025. The Sepolia fork is planned for the week of February 12, followed by the Holesky fork in the week of February 19. If there are no major vulnerabilities or problems, the Pectra upgrade may be launched on the Ethereum mainnet in early to mid-March, which is about three to five weeks after the Holesky fork. No one in the meeting opposed this proposal, and Stokes also suggested that the client release be tied to the Sepolia and Holesky testnet upgrades.

5. Holesky Gas Limit

EF General Engineer Sophia Gold proposed to set the default Gas limit of the client in the Holesky upgrade release to 36 million (36m), and continue to increase the default Gas limit of Holesky so that it is always higher than the Gas limit of the Ethereum mainnet. This will ensure that any increase in the mainnet Gas limit can be tested on Holesky, and no one in the meeting opposed this proposal. Representatives of the Teku, Besu, Prysm and Nethermind teams stated that their Holesky client release version has set the default Gas limit to 36 million.

6. RPC Standardization Efforts

Geth developer Felix Lange is disappointed that client teams are not giving enough feedback on the Ethereum JSON-RPC specification standardization efforts. One issue he mentioned during the meeting was the lack of a clear definition of the scope of RPC standardization and which ecosystem stakeholders should be included. Lange detailed his standardization efforts and suggested next steps in a blog post. Beiko suggested discussing this further on Discord and arranging a workshop for this. Besu developer Justin Florentine said he would be responsible for coordinating the scheduling of the workshop.

7. Node hardware and bandwidth requirements

EF Application Researcher Kevaundray Wedderburn requested feedback on its documentation on the minimum hardware and bandwidth requirements for Ethereum nodes. Beiko asked if these requirements should be drafted as an informative EIP for reference by developers and the wider Ethereum community. Prysm developer "Potuz" pointed out that the hardware requirements for validating nodes and full nodes are different, so the documentation should clearly distinguish between the two. Beiko agreed with Potuz and suggested further discussion on Discord about node hardware and bandwidth requirements and the next steps for formalizing Wedderburn's documentation.

8. EIP Editor Workshop

Finally, the meeting mentioned a special workshop on the EIP editing process, but the specific content and time have not yet been determined and may be discussed in further detail in subsequent meetings.

The Ethereum Cat Herders team will host an EIP editing workshop on January 17, 2025 at 16:00 (UTC). This meeting will provide an overview of the EIP editing process, and all Ethereum community members interested in the EIP workflow and editing process are welcome to participate. The recording of the meeting will be uploaded to YouTube after the meeting for everyone to watch.