As we did for the Pectra fork, we should reflect on how the process proposed earlier this year has served Ethereum governance so far.
For a general reminder about the process that dictated the Glamsterdam upgrade, a Pectra retrospective & a proposal to reconfigure ACD were published, followed by a headliner process proposal and a timeline for the Glamsterdam ‘headliner process’.
This helped ACD choose Glamsterdam’s major features, one for the consensus layer (ePBS) and one for the execution layer (BALs). Minor features (“non-headling EIPs”) were then proposed with a deadline to submit. We are currently in the process of selecting Glamsterdam’s minor features from the total list of Proposed EIPs.
Fusaka was a unique fork in that it split out of Pectra’s original scope. This scope being unmanageably broad was the instigator for a more formalized process with a goal to efficiently deliver forks with tightly defined scopes. Because this essentially predefined what was included in Fusaka, the process improvement proposal was applied to Glamsterdam as its pilot.
While structure and formal process has the potential to make things more efficient, it’s an inherently difficult problem to solve in decentralized governance because the structure has to be based in consensus rather than top-down rules to be followed. As such, formal process should be reflective of what works and what governance participants will follow because they’re good processes that make consensus less painful as nothing can reasonably be ‘enforced’.
To address what did and did not work, I’ll lay out a high level overview of what was proposed and whether or not we followed these goals. I think it would be useful to reflect on:
- If the goal was effectively followed, was it useful?
- If not followed, should we have pushed harder to apply these goals or were they just improbable?
- After having gone through this process, would we add new goals, reconfigure the entire proposal, …?
it’s important to maintain the ability to update or discard suboptimal processes. it’s hard to design processes upfront in one shot. probably lots of iteration will be required to get them right
| Goal | Followed? |
|---|---|
| Defining the fork focus prior to headliner selection | ?* |
| Open call for proposals | Yes |
| Select at most one headliner per layer | Yes** |
| PFI → CFI → SFI for all features | Yes |
| Headliner proposals (starting at PFI) structured explicitly in clear template | Yes |
| Structured community engagement at the beginning | Yes |
| Community testnet for validation near the end of the implementation cycle | No(t yet?) |
| Formalize working groups | Yes(?)*** |
| Document the full governance approach | Yes(?) |
*I’m unsure if anyone feels that we actually attempted this for Glamsterdam. It is my perspective that this turns out to be an unrealistic goal because the reality is that the community often has their eyes set on specific proposals long before we can decide on directions, so ‘fork focuses’ will likely be retrofitted to fit the desired EIPs.
**Though ePBS+BALs fits this, we actually did CFI FOCIL and then end up DFI’ing for fork scope, so we attempted to not follow this guideline though we ended up needing it
***Breakout rooms that revolve around features with dedicated champions seem to continue to be successful, while more generalized breakout rooms like RollCall didn’t seem to have the momentum needed to continue
for some added visualization:
