Pectra Retrospective w/Nixo and Yorick

The Pectra retrospective has become a focal point in recent ACD calls, emphasizing community feedback to guide changes for the next hard fork. A public Ethereum Magicians forum thread has been created to facilitate contributions, highlighting the importance of community engagement in protocol development. Nixo discussed the decentralized nature of core dev calls and the evolution of protocol development since 2015, noting the need for improved record-keeping standards and a more organized approach to manage the complexity of recent forks.

Yorick pointed out that Pectra lacks a central theme, leading to a decline in interest and investment in Ethereum. To counter this, discussions have been opened to the community, proposing a 30-day window between announcing a fork and its execution, which received positive feedback. There is a push to expedite forks by reducing the number of EIPs per fork, simplifying management and testing. Developers are encouraged to test their proposals thoroughly before submission, as there are concerns about unapproved changes.

Future retrospectives are anticipated after significant upgrades, with a goal of shipping upgrades every six months. The focus will be on evaluating functional EIPs with test vectors to ensure readiness for implementation. Concerns about hardware requirements, particularly regarding PIRDAS, have been noted, but the urgency has diminished. The current plan for Fusaka is to limit it to EOF and PIRDAS, with the possibility of including one additional minor EIP.

The process of rejecting EIPs remains challenging due to the lack of clear veto power, often resulting in deferrals to subsequent forks. There is a desire for a higher bar for EIP inclusion, emphasizing the need for persistence from developers. Historically, Ethereum has struggled to implement two upgrades per year, but some developers believe a shorter upgrade cycle could invigorate core developers.

Concerns were raised about the governance process, particularly regarding potential manipulation by VC-funded clients. The current system shows inconsistencies in prioritizing code changes, creating a double standard. The governance process is described as "wonderfully wooly and messy," reflecting a tension between functionality and acceptance of existing dysfunction.

The retrospective process aims to focus on actionable next steps. Concerns were voiced regarding proposed minimum hardware and bandwidth requirements for validators, with discussions highlighting the need for recommendations grounded in real-world data. The introduction of the ETH candor ops data collection effort aims to gather data from home stakers about their bandwidth, CPU, and memory usage, with an upcoming EStaker annual survey to understand stakers' upload bandwidth capabilities.

Critiques were made regarding the lack of methodology in validator requirements, with calls for the Ethereum Foundation to provide reliable information. The performance of client machines was addressed, noting that typical machines operate well within their specifications, but users with 32GB machines have faced memory errors. Future-proofing hardware recommendations was proposed, ensuring economic viability for validators.

Suggestions included analyzing median incomes and upload bandwidths in major cities to tailor bandwidth requirements for solo validators. The hosts encouraged individuals to publish their analyses and hardware recommendations, concluding with hopes that listeners gained new insights into Ethereum.