Pectra Retrospective

[abcoathup]

Links to Pectra retrospective responses

Consensus Layer teams

Grandine

Pectra Retrospective

This was Grandine’s first hard fork where we fully participated in the process, so it’s difficult for us to compare it with previous forks. However, we have a few key insights to share: Lack of a Clear Flagship Feature Pectra ended up being a hard fork with many small improvements but no strong central message, or direction. We believe hard forks should be driven by a single flagship feature, similar to how the upcoming PeerDAS fork is structured. Additional smaller changes should only be incl…

Lighthouse

Pectra Retrospective

Lighthouse Team Feedback Early and Aggressive Scope Freezes We support a stronger commitment to early scope freezes. Scoping out fork N+1 while N is being shipped, and freezing N+1 when N is shipped sounds like a good framework. Although there should be rare exceptions for critically important features. Governance and Call Structure We think separating “scoping/roadmap” discussions from deep technical dives could streamline the process. This would work will with the parallelization of fork N+…

Lodestar

Lodestar’s Pectra Retrospective and Future Fork Ideas

Nimbus

Prysm

Pectra Retrospective

The Prysm team has internally discussed Pectra Retro. Here is a summary of our thoughts Key Learnings and Observations Underestimating complexity of EIP EIPs can often appear simple at first glance, but their true complexity surfaces more during implementation (Example: **EIP-7549)**. This experience has taught us the importance of evaluating EIPs and client changes with greater care before making decisions on what to include. This also relates to formalizing specs earlier and ha…

Teku

Pectra Retrospective

The Teku team has shared a document reflecting on some of the points raised by Tim and also some observations from the team. The full retrospective document can be found here. Please read below a summary of our discussion: It is impressive to see how much we have evolved in our testing capabilities, largely due to the support from EthPandaOps and the tooling they have developed. We cannot stop praising them for all their work and how much more productive we are because of their help. It is rea…

Execution Layer teams

Besu

Pectra Retrospective

Feedback from the Besu team: Some EIPs were not specced sufficiently and delayed the fork because several rounds of spec changes where necessary along the way Scoping Pectra took way too long. Freezing the SFI list should happen very early in the planning process EIP-7742 was dropped too quickly. It might make sense to revisit it in the future to allow CL only hard forks PandaOps and testing teams are top notch Gating devnets seems like a good idea, but wasn’t strictly enforced. Seems to still…

Erigon

Pectra Retrospective

In my opinion, this hard fork was messy and full of things that do not benefit Ethereum neither in the short term or in the long term. The only improvements that are tangible is native AA and the increase of the blob count. The rest of the EIPs were unnecessary and most were only refactorings which might as well never happened. It is clear to me there is a problem in the decision-making part of the protocol rather than in the “development”. I think the development is fine but the decision makin…

Geth (individual responses)

Pectra Retrospective

This is a rewording of my comments during ACD last week. The problem isn’t the fork size, it’s that forks are bloated with EIPS that seem “small enough” that including them feels like it will not cause any delay in the fork. These claims are often taken at face value. Core developers get very busy implementing EIPs that are completely unrelated to the big picture of the roadmap, but it feels like something is being done because yet another EIPS is included. One can add as many committees and s…

Nethermind

Pectra Retrospective

The Nethermind team have discussed our opinions on increasing the rate at which we ship forks and thought of some ways to improve the process. Fork Scoping We should aim to have a provisional plan for the next 5 hard forks, mapping Vitalik’s roadmap into concrete updates. There would still be flexibility to change fork scoping, especially more distant ones, but having this provisional timeline would greatly help in deciding where to allocate resources. For imminent forks (within a year) we sho…

Reth

Pectra Retrospective

Reth team has gathered opinions on Pectra scoping and development internally, here is the aggregated summary our thoughts: EIP Consideration Currently, the EIP is considered ready when it has been summarised, the spec has been defined and sufficient number of community members have discussed it. Then the champion of the EIP brings it on a wider ACD discussion forum and it can be considered for inclusion. The crucial step that we think is missing from this process are test vectors. This would ma…

EthPandaOps

Pectra Retrospective

There were a couple of things we tried to do with Pectra and we’d like to start the retrospective by focussing on that. We had a major shift towards local testing instead of relying on live devnets. This was achieved by the use of Kurtosis (for locally running devnets), EELS/EEST (allowing the testing team to fill the tests via EELS instead of a client implementation), Assertoor (for executing actions on local devnets). This shift to local testing allowed client teams to debug and iterate quickl…

Community

Pectra Retrospective

Here’s an idea I wrote up last year when I was reflecting on how the current devnet process was flowing: it’s basically a draft of what could be released. The biggest feature is to keep devnets and make them so they could be shipped “on demand,” applying one of the learnings from Agile methodoligies. My note also includes a half baked idea aboult larger features working independently of slotting. However, I like Tim’s idea of N+2 is open for additions and closes when it becomes the N+1 fork b…

Pectra Retrospective

Community response Summarized ACD calls async for 3.5 years (former editor of weekinethereumnews.com). Collected summaries/writeups in Protocol Calls & happenings - Fellowship of Ethereum Magicians Better ACD summaries: ACD call summaries of actions/decisions written by moderators on Eth Magicians, generally within 24 hours (thanks @timbeiko & @ralexstokes). Scoping priority writeups Client team writeups of scoping priorities: e.g. Reth, Lighthouse, Lodestar & Prysm. Allows for considered…

Pectra Retrospective

I think the Paradigm Ethereum Acceleration post is totally correct that ACD is a bottleneck and that client developers should not be the primary decision-makers. I don’t think this is desirable for anyone, not even the client developers, who have too much responsibility and have to constantly make controversial and stressful decisions they shouldn’t have to. I think the main issue with Ethereum development is that we’ve erroneously felt that “sufficiently decentralized” means that the process h…