Summary of key points of the 203rd Ethereum ACDE conference: What impact will the Pectra upgrade bring?
Reprinted from panewslab
01/20/2025·1days agoAuthor: 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 session was moderated by Tim Beiko, head of protocol support at the Ethereum Foundation (EF). ACDE meetings are a bi-weekly series of meetings 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 increased Gas limit on the Holesky test network, the progress of 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 that he discovered a Gas estimation problem in the development network and planned to collect relevant logs and share the problem to the Ethereum R&D Discord channel.
2. Pectra specification update
Developers discussed five pending updates to the Pectra code specification:
-
EIP 7623: Increased Calldata Costs The first update is a modification to EIP 7623 to clarify how gas refunds are handled. The update has been merged on GitHub and included in Pectra Devnet 5 testing.
-
EIP 7840: Add Blob Scheduling to the Execution Client Profile The second update involves the underlying cost fraction issue in EIP 7840. There was no objection at the meeting, and the developers agreed to merge the changes into GitHub before the Pectra testing meeting next Monday, January 20.
-
Update to Blob Base Cost The third update, also related to Blob Base Cost, involves how excess gas is calculated during Pectra activation. Alex Stokes, head of research at the Ethereum Foundation, explained that the calculation relies on information from the previous block header. If a change in blob capacity activates on a fork boundary (Pectra activated block), the excess gas calculation will be based on information from the previous block built using the old fork rules. Stokes believes that it is necessary to clarify whether the increase in blob capacity is activated at the fork boundary or a block after the fork boundary. "It doesn't matter which way you choose, but we need a unified approach," he said. Developers unanimously agreed to clarify EIP 7691 and set the effective time of the Blob capacity increase to one block after the fork boundary, so that only Use the new bifurcation rules for calculations. Ethereum test developer Mario Vega said the client is testing this logic. Geth developer “Lightclient” promised to update EIP 7691 before next Monday’s test meeting.
-
EIP 2537: The fourth update to precompiled cost calculations for BLS12-381 curve operations is related to multiplicative cost calculations in EIP 2537. The developers agreed to explicitly specify the calculation as integer division in the EIP. Client teams tested with Pectra Devnet 5 should already have this logic implemented in their code, so only spec changes will be needed. Ethereum Virtual Machine developer Paweł Bylica said that he will make changes to the EIP on GitHub and complete it before next Monday's test meeting.
Through these updates, developers continue to promote the improvement and coordination of Pectra-related work, paving the way for future Ethereum mainnet upgrades.
- Finally, the fifth update is related to EIP 7702, a proposal to add a new transaction type that allows external accounts (EOA) to permanently set the code. Otim Labs COO Julian Rachman proposed a behavioral modification to this EIP, which is to enable code introspection. According to documentation written by the Otim Labs team, code introspection refers to the ability of legacy contracts to inspect their own bytecode or the bytecode of external contracts and adjust behavior based on this information.
Although the Ethereum VM Object Format (EOF) development team plans to disable code introspection in future Ethereum upgrades, documents and meetings mentioned that enabling code introspection to check the "delegate_address" of EOA will not hinder EOF. development process. The benefit of allowing code introspection to examine delegation addresses for EIP 7702 type transactions is to support the safe use of relayers and other external accounts when EIP 7702 features (such as Gas sponsorship) are enabled.
Geth developer "Lightclient" supports adding this update to the Pectra specification. "This update is very easy to implement. We are already determining whether the account is an EIP 7702 delegated account, and adding a designated return address is a very simple matter," he said. Meeting moderator Beiko suggested that attendees take a few more days to review the changes. Then decide whether to include it in the final specification. He suggested revisiting the topic at next Monday's testing meeting.
Beiko also asked Rachman's team to formally submit a pull request containing all EIP 7702 modification suggestions on GitHub for developers to discuss on Monday. As for whether the update will require developers to launch a new Pectra development network for testing, Jayanthi said the change can be included in a shadow fork of the public testnet without launching a new development network. Beiko added that all other specification updates discussed at the meeting also do not require a new Pectra Devnet, so developers can move forward with updates to the public testnet after further testing of Pectra Devnet 5 is completed.
3. Pectra system contract audit update
Fredrik Svantes, a protocol security researcher at the Ethereum Foundation (EF), said that all third-party audits of the Pectra system contracts have been completed. No major issues were found in the audit, and relevant reports will be uploaded to GitHub for review by the client team. Svantes recommends setting aside time at the next ACDE meeting for auditors to present their findings and answer questions from the client team.
4. Pectra test network upgrade plan
Tim Beiko proposed a preliminary timeline for the testnet upgrade. He suggested that the block height for upgrading the Sepolia and Holesky testnets be determined in the next two ACD meetings, and the client release version be prepared before February 3, 2025. The Sepolia fork is planned for the week of February 12th, followed by the Holesky fork the week of February 19th. If there are no major bugs or issues, the Pectra upgrade may be launched on the Ethereum mainnet in early to mid-March, which is approximately three to five weeks after the Holesky fork. No one at the meeting objected to this proposal, and Stokes also suggested that the client release be tied to the Sepolia and Holesky testnet upgrades.
5. Holesky Gas Limitation
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 main network. This will ensure that any increase in the mainnet gas cap can be tested on Holesky, and no one at the meeting objected to this proposal. Representatives from the Teku, Besu, Prysm, and Nethermind teams stated that their releases of the Holesky client already have a default gas limit of 36 million.
6. RPC standardization efforts
Geth developer Felix Lange is disappointed that the client team has not given enough feedback on the Ethereum JSON-RPC specification standardization efforts. During the meeting, one of the issues he mentioned was the lack of 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 issue further on Discord and arranging a panel for this purpose. Besu developer Justin Florentine said he will be responsible for coordinating the timing of the symposium.
7. Node hardware and bandwidth requirements specifications
EF Applications Researcher Kevaundray Wedderburn requested feedback on its documentation on minimum hardware and bandwidth requirements for Ethereum nodes. Beiko asked whether these requirements should be drafted in the form of an informational EIP for developers and the broader Ethereum community to reference. Prysm developer "Potuz" pointed out that the hardware requirements for verification 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 as well as next steps for formalizing the Wedderburn documentation.
8. EIP editing seminar
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 hold an EIP editing seminar at 16:00 on January 17, 2025 (UTC). This meeting will provide an overview of the EIP editing process, and all Ethereum community members who are interested in the EIP workflow and editing process are welcome to participate. The recording of the meeting will be uploaded to YouTube for everyone to watch after the meeting.