Pectra Retrospective

Magicians Process Improvement
1

On ACDC#149, we agreed that before jumping into Fusaka planning, we should stop and reflect on Pectra. More broadly, we’ve recently seen many questions, strong criticism and novel improvement proposals related to AllCoreDevs (ACD).

To keep the conversation tractable, I’d suggest using this thread as a coordination point to share retrospectives and analyses of ACD, as well as proposals for how to improve things. While it’s fine to highlight problems without necessary having a solution to them, hopefully we can keep the conversation civil and productive :smile:

I’ll use this top post to categorize high-quality responses from Client Teams, Infrastructure Providers & Developers, and Misc. Users / Community members.

In a few weeks, we’ll dedicate time on ACD to discuss what came out of this discussion.

While I don’t want to overly constrain how feedback is provided, here are suggested starting points for reflection:

  • Over the past year, what went better than expected in Pectra’s development and/or ACD generally? What caused this?
  • Over the past year, what went worse than expected in Pectra’s development and/or ACD generally? How could we have prevented this?
  • Looking forward, what should we start doing, stop doing and/or do differently?
  • What should we not compromise on, even if there is pressure to do so?
  • What parts of ACD are “legacy process debt”, which we should consider rethinking from first principles?

As we discuss this, we should deeply consider the second-order impact of proposals. For example, it’s often suggested that ACD should be “more efficient”. On the surface, no one would disagree. That said, it’s easy to see how there’s a tension between speed and other aspects of the process, such as security, openness and biasing towards work that has less “unknown unknowns”.

This isn’t to say that we shouldn’t try and make the process more efficient, but that we should be mindful of what we tradeoff to get those efficiency gains.

11 Likes
2

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 async review/response.

ACD stream/recording:
Adding the chat to the stream/recording of ACDC. The chat is where much of the discussion happens and contains a large amount of context.

Worse

Scoping:
Pectra was originally pitched as a small upgrade targeting end of 2024 (before Verkle), it became the largest upgrade ever (even after being split), targeting Q1 2025.

Planning started formally in January 2024 and the scope for the first half was finalized in December. We ended up with too many EIPs being included over many months, with the rush to get in before Verkle put everything on hold. (the irony being that this delayed Verkle so much that Verkle might not be used for statelessness, and statelessness may not be the highest priority on the roadmap anymore).

Start

Roadmap:
Upgrades should be driven by a public multi-year roadmap. This roadmap can and should be subject to change. EIPs should generally only be considered for inclusion if they significantly move the roadmap forward.

Informal Veto:
Rough consensus should include an informal veto of EIP inclusion by:

  • Client teams considered to have greater than one third market share.
    Currently assumed to be only Geth & Nethermind. As an example, Geth were strongly against EOF, as they were a majority client at the time (with all the responsibility & pressure that this status entails) they should have had a veto. If we don’t want teams to have this power then the community can remove it by improving client diversity.
    The veto should only be informal, to ensure that rough consensus isn’t captured by any one participant.
  • DevOps.
    If EthPandaOps believe they can’t safely test a combination of EIPs (or sheer number of EIPs) then those EIPs should be proposed for inclusion in a later upgrade. As an example ethPandaOps call for a Pectra split

Stop

Saying yes
We want to accelerate upgrades, increasing the reach rather than widening the scope, so we need to stop saying yes to EIPs that don’t significantly move the roadmap forward.

We need to heavily use denied for inclusion, regardless of how much good work/effort people have put in, EIPs should be weighed against the roadmap, and hurt feelings aren’t part of this equation.

Do differently

Scoping:
At the start of each upgrade cycle, authors should propose for inclusion EIPs that move the roadmap significantly forward. EIP authors/champions should add a 5 minute presentation (video & slides) to their EIP discussions topic in Eth Magicians.
This would allow client teams & the community to review them async. (without having to discuss on ACD).

Client teams (and the rest of the community) could writeup which EIPs they believe based on the roadmap should move to considered for inclusion or declined for inclusion.

A proposed scope of considered for inclusion and declined for inclusion can be created. ACD can decide on the remaining EIPs where there isn’t rough consensus on CFI or DFI. If needed those authors could take questions (depending on the number this should be a breakout).

The proposed scope can then be updated. Client teams having the opportunity to estimate the effort involved, along with recommending any changes to CFI or DFI. Informal vetos could also weigh in.

ACD
ACD should be the venue for (synchronous) decisions. Outside of scoping, ACD should be short, ideally 30 minutes. Any discussions should be time boxed (e.g. no more than 10 minutes). If longer discussions are needed then these should move to a breakout or async.

The agenda should clearly indicate what decisions are to be made and the agenda shared widely.

New EIPs shouldn’t be presented at ACD, instead authors/champions should create slides & a five minute video to review async.

Any mic issues should bump a presenter to the next call. #micDAO

ACD chat logs & transcripts
Chat logs (where there is a lot of contextual discussion) & AI generated transcripts should be made available within 24 hours of the call. (@nicocsgy is on the case). These can be stored in GitHub - ethereum/pm: Project Management: Meeting notes and agenda items and replace the current manual transcripts and third party call writeups (which often take weeks to appear). We should also copy the moderator summary from Eth Magicians to the call folder in ethereum/pm.

Not compromise

Rough consensus
Decisions are made by rough consensus. Clients have a variety of owners, including an L2, a VC and the EF. Other than the proposed informal veto, no ACD participant should have special status. Roadmap, CFI/DFI should all be decided by rough consensus and avoid ACD being captured by any one group.

Scoping process
Fusaka upgrade should be treated as a clean slate, rather than waiting for Glamsterdam. All EIPs should be reset to proposed for inclusion and reviewed against the roadmap. PeerDAS and/or EOF may end up being the only EIPs to be considered for inclusion, but we should also look at FOCIL, ePBS etc and choose only the EIPs which will significantly move the roadmap forward.

Legacy process debt

EIP process
ACD should own the EIP process or at the very least have the process work for them. It should be fast and easy to get an EIP to draft status. This was one of the goals with splitting out ERCs from EIPs.

Just as ERC now has a funded role for ERC & standards coordinator, we (EF or another group such as the Protocol Guild) should be funding an EIP coordinator.

1 Like