Should network upgrades and FIP acceptances be coordinated?

[kaitlin-beegle]

@anorth highlighted a great question is #262.

Historically, FIPs could pass into 'Accepted' status at any time. The question of 'accepting' a FIP and implementing a FIP were supposedly distinct, as was described in FIP0001:

[The Accepted] FIP is in the hands of the Filecoin implementation developers. Their process for deciding whether to encode it into their clients as part of a consensus upgrade is not part of the FIP process.

However, there appears to be a bit of ambiguity in the de facto separation of FIP processes and network upgrades. This seems primarily due to:

• Close coordination among staff, who were able to remain closely in-sync while planning for network upgrades and managing reviews and audits of mission-critical technical FIPs;
• An ad hoc network upgrade process, wherein the completion of FIPs would motivate a network upgrade;
• A small number of total FIPs in the first year of mainnet, where there was roughly an upgrade for every 1-2 FIPs.

As @anorth pointed out, recent FIP stewardship was unintentionally coupled with the planned v15 network upgrade. This was due to the importance of accepting and implementing the Snap Deals FIP and limited capacity for incorporating other FIPs on chain during this upgrade cycle. Both this prioritization and capacity limitation originated with Core Devs, who play an important role in both reviewing FIPs and stewarding the broader network.

---

Complexity in the Filecoin network is only increasing. As we consider changes to the FIPs process overall, I think it's also worth thinking once more how FIPs and network upgrades relate to one another.

As the editor responsible for FIPs, I see the appeal of decoupling FIP acceptance from network status. However, from a network governance perspective, this opens up an entirely new arena of decision-making that is currently unaccounted for.

We can already anticipate several huge network changes in 2022, including Snap Deals and the soon-to-ship FVM FIPs. Such large changes are technically complex, require quite a bit of labor and coordination, and pose challenges to the security and stability of the network (as any change does). As a result, it's likely that Core Devs will have limited capacity for including other FIPs in network upgrades.

If the number of FIPs increases (or even remains the same; we have ~30 issues in backlog), the decoupling of FIPs from implementation upgrades may lead to a large number of FIPs that are 'Accepted', but not 'Final'. In other words, we have a legitimacy chasm between FIPs that the community has approved, and FIPs that implementers have implemented.

This may not be a problem in and of itself, but it certainly is if there is no clearly defined way of prioritizing which FIPs get included in the network. My concern is that keeping the distinction between "Accepted" and "Final" FIPs, community approval and Core Devs prioritization, splits the governance space such that there are two places where decisions need to be processed.

I'm curious to know what others think of this issue.

[kaitlin-beegle]

To the above I'd like to note how 'human' the FIPs process still is, and what this means for decentralized governance.

Community members frequently have good ideas, and often open up FIP items for discussion. However, they rarely have the technical skills or time to author full and complete FIP drafts. This is to be expected, and it's why FIP editors and engineers at Protocol Labs are made available as technical reviewers.

However, there is only so much coordination and capacity available. Thus, it's not the case that FIPs simply become available, where it's then up to coordinators (including myself) to decide the procedure that gets them into the network. Instead, this intense coordination need means that we often interact and 'prioritize' FIPs really early on, with the intent to implement them as soon as they're ready. What other reason is there for us to apply limited resources to finalizing a FIP draft- with technical specs, security and cryptoeconomic audits, and moderated community deliberation- without interest in imminently implementing?

If we decide that FIP acceptance and network coordination need to remain distinct processes, how do we then prioritize which FIPs get priority review and resources? By keeping these processes separate, I worry that we end operating on the same prioritization assumptions (e.g., this FIP should land immediately, it gets resources, and will be implemented ASAP, etc.) but with less transparency. If FIP acceptance and on-chain implementation were connected, at least these prioritization decisions would be clearer.

[anorth]

Since the FIP editors and engineers overlap with the implementers, I don't think we're likely to end up with a huge mismatch here. Yes, we certainly need to prioritize attention on proposals, and likelihood of implementation will be a top criteria for that.

FIP editors and implementers are very close groups, as they should be. I think we can coordinate these activities without identifying them as the same.

[anorth]

Thanks for opening this discussion, Kaitlin.

Since the same group of people—the implementers committee—is the principal for both approval of FIPs and the decisions about implementation timelines, I think the potential for a chasm is limited. The "community" don't approve FIPs, but provide input and discussion to the approval decision made by implementers. I don't think we'd likely end up in a situation where there is a huge list of approved FIPs without a path to implementation. Back-pressure from the implementers would leave that long tail in draft or last-call state. It would be of greater concern if the two groups (approvers and implementers) didn't significantly overlap.

But it's quite beneficial to throughput to have a small list of approved FIPs ready for implementation, and also a set of last-call and draft FIPs committed but awaiting approval. Both protocol design and community consultation take a long time. If we pipeline the FIP development process and then the implementation process, we can achieve a greater throughput by keeping the implementation teams supplied with ready-to-build changes. If we instead held off meaningful FIP-development ("technical specs, security and cryptoeconomic audits, and moderated community deliberation" etc) until the implementation teams were done with the previous network upgrade, the pipeline would stall.

None of this should be taken too rigidly. Approved FIPs don't constitute the only possible work. Implementers may well propose smaller changes as new FIPs quite close to or concurrent with development. The approval order need not mandate the implementation order. If some FIP is postponed a couple of releases for good reason, no problem. The approved set may grow and shrink, adapting to changing circumstances and our projections for implementation bandwidth. So long as the implementers are transparent about the decisions made here, I don't think we need fret about a shadow governance system.

(In fact, I think perhaps the opposite. Take the FVM for example. There is ongoing active development, in secret. A range of decisions are being made that will be extremely resistant to subsequent challenge, on the basis of "we already implemented it". There is no FIP, and little community discussion. But everyone knows this will be immediately prioritised and the FIP will be rushed through as "whatever this implementation does". I couldn't be more exited about the change, except that it mocks our community process. [EDIT] The developers mean well and I'm sure will earnestly attempt to bring the community along with them. But that will require effort. The default outcome for FIPs during network development will be that community gets no voice, like pre-launch).

[EDIT] I guess I'd also be ok with non-participatory ownership by the implementers, conserving their scarce attention, if we were just up-front about that expectation.