The Pectra Upgrade and its Significance
Recently, the Ethereum core development team disclosed their plans for the long-awaited Pectra upgrade, set to be unveiled by the conclusion of Q1 2025. This unveiling trails the successful rollout of the Dencun upgrade in March 2024. The decision to postpone Pectra until early 2025 reflects a strategic move to ensure a meticulous release and embed more impactful user-centric features.
Upon evaluating various timelines for the Pectra upgrade, Ethereum developers reached a consensus to extend the launch post the Devcon developer summit that is arranged for November 2024 in Bangkok. This carefully considered approach aims to facilitate a refined development process, incorporating additional features that could substantially enrich user engagement. In the words of the Ethereum developers, “Being realistic, my vote would be to aim to ship Prague in Q1 2025. Delaying Prague slightly allows for a more comprehensive scope, potentially encompassing more impactful features for users.”
“We are observing that this is also what happened with Cancun, so being realistic, my vote would be to aim to ship Prague in Q1 2025. With today’s scope, delaying Prague seems to have a marginal impact on users and allows us to consider expanding the scope to include more impactful features for users.”
Improvements and Future Prospects
The forthcoming Pectra upgrade will concentrate on enhancing both the consensus and execution layers. A notable enhancement includes the integration of PeerDAS, with the objective of amplifying Ethereum’s Data Availability capacity before the Osaka upgrade.
The Osaka upgrade, a potential hard fork, is anticipated to encompass features initially earmarked for Pectra but deferred for a more polished execution. Particularly, Osaka is likely to introduce Verkle Trees, a novel data structure devised to advance Ethereum’s scalability and decentralization.
“We need to decide on EIP7702 on ACDE, and if so, implement it as a replacement for EIP-3074. We think it makes sense to do so as it’s a more native-AA compatible solution because of the new transaction type vs an opcode,” shared the developers.
Furthermore, discussions within the Execution Layer Meeting revolved around bolstering long-standing authorization scenarios in Ethereum’s account management system. Contemplations on mechanisms to sustain authorizations during transactions, such as Max L and non-optional authorizations, as well as the adoption of 7702 and standardized proxy message signing by wallets, were explored.
