Proposed Updates to FIP0001

[kaitlin-beegle]

Simple Summary

Filecoin is an open-source, community -led protocol. As the network develops, it is important that its governance structures be adapted in a manner that best supports 1) the stable and secure development of the Filecoin tech stack, as well as 2) protocol decentralization over time.

Like other low-layer protocols, Filecoin uses an off-chain, constitutional process for reviewing, accepting, and implementing proposed changes. This constitutional process is codified in FIP0001, which outlines the purpose and process of Filecoin community governance.

The first purpose of this discussion post is to summarize some updates I'd like to make to FIP0001. These updates merely seek to document governance processes as they're currently practiced; they reflect the norms and behaviors that have organically developed over the last few months.

The second purpose is to propose the formalization of a governance working group within Filecoin Core Devs. The purpose of this group is to act as a formal mediation body in the case of consensus failure. This proposed change was motivated by recent developments in the Ethereum Core Devs group, experience navigating increasingly complex FIPs within the Filecoin ecosystem, and in response to many community requests for a formalized and publicly accountable governing body.

Proposed Updates

Clarify FIP Types

Remove the subspecification of technical FIPs (core, networking, interface, and informational), which are not currently used and do not meaningfully distinguish different types of FIPs as they're currently written and implemented.

Simplify FIP categories as:

• Technical - The category that most FIPs fall into, technical FIPs are those which propose technical changes that affect most or all implementations, block validity rules, network interoperability, etc.
• Community - A change of term; updating 'Organizational' to 'Community', as this is the way that many people refer to these FIPs. This lanugage also better centers procedural changes, etc., around community needs, rather than organizational decisions.
• Cryptoeconomic - A FIP which proposes fundamental changes to the Filecoin cryptoeconomic model, including token dynamics, minting schedules, etc.
• Recovery - A FIP type that can be used to revert state in case of emergencies (i.e., mission-critical bug, etc.)

Document Filecoin Requests for Comment (FRC)

Reflect guidance here in FIP0001, desginating FRCs as a formal way of documenting network standards.

Update FIPs Workflow(s)

• Reduce FIP types and standardize language as: Idea, Draft, In Review, Accepted, Implemented.
  • We will continue to maintain 'withdrawn', 'superseded', 'failed' statuses for FIP. The above refers to the average workflow that most FIPs proceed through.
• Define 'soft consensus' process for FIPs, as well as mediation procedure in the face of consensus failure (see: Proposed Changes)

Include governance policy for FIP Editors

Add a quick sentence or two about nominating and removing FIP Editors, which ought to be proposed by anyone and approved through soft consensus by Core Devs.

Proposed Changes

At Filecoin's current rate of development, most FIPs benefit from a 'soft consensus' governance process. This process- sometimes also called 'rough consensus'- is a practice where changes can be accepted through passive community consent rather than proactive stakeholder decisionmaking.

The process of 'soft consensus' is typical in open-source environments, particularly those that govern highly technical (i.e., expertise -intensive) changes. 'Soft consensus' allows for Filecoin to crowdsource proposals and innovate rapidly, minimizing governance friction while emphasizing open design, public iteration, and robust documentation as primary governing prerogatives.

In rare cases, however, soft consensus is not an appropriate governance mechanism for a proposed change. When changes are particularly complex, disproportionately impact a specific stakeholder group, or are otherwise contentious, soft consensus can fail to deliver a clear path forward (either acceptance or rejection) for the FIP.

In cases where difficult changes are necessary to achieve the network's stated mission and ensure its sustainability, there must be a mechanism in place to mediate consensus failure.

After months of discussion, debate, proposals, and feedback- and informed largely by conversations with both Storage Providers and Core Devs over the last few weeks- I'd like to propose that a Governance Working Group be formed in order to address this issue.

The Goverannce Working Group (GWG) ought to be a sub-group of Filecoin Core Devs. The group should serve as a technical governance group that offers mediation and decisionmaking in the case of consensus failure for especially complex FIPs.

Governance of the Goverannce Working Group

• Membership ought to be quasi-static, pre-set, and publicly known.
  • Those who wish to participate in the GWG are those who are or can qualify as Core Devs, i.e., community contributors who have expertise of value to the entire protocol, and who are able and interested in making governance decisions on topics outside of their direct work domain.
  • Volunteers or nominees for the GWG must be approved by existing Core Devs through soft consensus. If anyone vetos a nominee/volunteer, all Core Devs will be asked to cast a vote to accept or reject their candidacy. Simple majority wins.
  • Participants should serve 6 month terms; after 6 months, they should rotate out, or volunteer for another term. Regardless, other Core Devs have the ability to easily review and veto participants on a six-month basis.
  • Membership should be capped according to organizational affiliation:
    • TWO voting representatives of Filecoin Foundation
    • TWO representatives of Protocol Labs
    • TWO representatives of each of the network implementation teams
    • Up to FIVE other Core Devs, with no more than TWO coming from the same team
  • A GSG member can be recalled at any time by Core Devs, and removed with a 2/3 vote of no confidence.
• During consensus failure, a simple majority vote among GSG members will determine whether the FIP in question is accepted or rejected.
• GSG members will meet on an ad hoc basis; as Core Devs, they are expected to remain engaged and knowledgeable about relevant governance and technical topics, and are encouraged to attend monthly Core Devs meetings.
  • Ad hoc meetings will be closed, but recorded. Full meeting notes and meeting recordings will be made publicly available.
  • If ever a vote is taken, all votes must be publicly attributed. A decision document will also be drafted and published, explaining key arguments for and against FIP acceptance.

Rationale

The fundamental challenge of addressing a soft consensus failure is to avoid community politicization, and to deliver an informed decision that is made in the interest of the protocol.

Creating a governance working group within Core Devs addresses both of these challenges, while delivering additional social benefits:

• Pulling participants from Core Devs frames deliberation around technical constraints and trade-offs, with an existing bar for expertise, participation, and network involvement.
• Creating a sub-group within Core Devs allows for a separation between technical expertise and technical decision-making, while ensuring that these different functions can be clearly differentiated from, while informing, one another.
• The number of participants from each org ensures a diversification of perspectives, while weighting towards technical contributors who are deeply involved and responsive to the broader Filecoin community.
• Provides an additional incentive for a broader swath of skilled community members to participate as Core Devs :)

Fundamentally, introducing a Governance Working Group is a small yet signficant change for Filecoin governance. Such a change is aligned with and similar to the governance practices of similar, more mature organizations.

However, it is important that we think of this change as a first step towards improved governing capacity, and nowhere near final. We ought to accept changes, knowing that procedural iteration and the emergence of new norms will develop over time.

It is my hope that addressing this issue will give us a greater ability to make more tweaks, more quickly, increasing the rate which governance capacities are able to develop.

Specific Questions for Discussion

• Are there nuances or specificities that should be added to the defintion of each FIP?
• Do we like the way FRCs are currently specified? Are their definitional uncertainties that should be resolved?
• Should members of the GSG be allowed to serve as FIP authors? If so, should they be allowed to vote on their own FIPs?
• Are there other procedures- governance calls, public notices, etc.- that ought to accompany any changes to FIP0001, but which should not be codified in FIP0001?

As a reminder, nothing is static, and these changes ought to be incremental! Whatever doesn't work, or needs incremental refinement, can always be fixed and/or updated!

[dmc314]

I generally like the concept you propose here of having a subset of decision-making delegates that are more intentionally tuned in and accountable.

Can you clarify what you mean about the delegated members? Specifically, when you say:

Membership should be capped according to organizational affiliation:

1. TWO voting representatives of Filecoin Foundation
2. TWO representatives of Protocol Labs
3. TWO representatives of each of the network implementation teams
4. Up to FIVE other Core Devs, with no more than TWO coming from the same team

Is bullet three meant to refer to node implementer teams such as Forest, Lotus, and Venus?

And is bullet four meant to refer to PL sub teams such as CryptoEconLab or CryptoNet?

We may want to explicitly list the teams publicly along with the list of members, as they are all subject to change, re-orgs, new startups, etc over time.

[kaitlin-beegle]

Hey @dmc314, thanks for the feedback!

The idea of capping and delegating representation is intended to 1) limit uneven representation in the short-term, and 2) allow us to diversify and decentralize representation in the long-term.

For bullet three, you're correct: these are node implementer teams. They ought to have their own representation, given their obligations to incorporate FIPs. Also, network implementation teams are increasingly designing services for different cross-sections of the Filecoin community (Venus strongly focused on storage provider services, for example) and will be able to speak to their users' interests.

Bullet four refers to the broader group of Core Devs- whomever they may be. It is my hope that interest in decision-making will drive more community members (from outside of FF/PL) to want to participate as Core Devs. There is no singular definition of "team" because these things change over time and across organizations, as you pointed out. Rather, folks should be able to self-identify where they work, or on behalf of whom, and we can keep track that way.

And you're right! We should be listing who works where, for transparency's sake. I've pushed for Core Devs to this for quite some time; perhaps we can make the change this week.

[f8-ptrk]

why does PL here get 2 seats? they already have 5+2 seats on the table with core devs and ntwk implementation teams. PL is, besides financing a lot of the implementation teams, "just" a ecosystem participant - those should be voted for if there needs to be space for non implementation/FF

[momack2]

@kaitlin-beegle - can you share some examples from other blockchain networks of this sort of representative voting body working well? Would love to look more deeply into what other networks have done, and the pitfalls they've uncovered, so that we don't unintentionally make changes that actually increase the politicization of core devs and network governance, instead of mitigating it.

More canonical examples of blockchain governance systems are delegated voting or on-chain governance - ex this report from Polkadot seems like a very valuable read we should evaluate and consider: https://polkadot.network/blog/polkadot-governance

Overall, we should be very careful to consider potential negative implications of changes, and avoid fast-tracking a major change like this because of short-term pressures (ex the desire to avoid soft consensus dead-lock around cryptoeconomic FIPs). Agree we need increased definition of how the FIP process should improve its handling of a soft consensus dead-lock, however we absolutely need to take the time to war-game and closely evaluate all the potential downsides to proposed governance changes. While I see the benefits of the GWG proposal over other solutions discussed so far, I also can see it creating new problems that might be worse that what we're trying to mitigate today. 😅

[dmc314]

CryptoEconLab has also given some thought to governance benchmarking and research like this. We have done some light research (@juanpmcianci, @emceecoy, @vkalghatgi, @zixuanzh) and could look to dive in more depending on priorities.

Here is a pretty good paper we found: "SoK: Blockchain Governance" https://arxiv.org/pdf/2201.07188.pdf

And here is a list of other resources and papers: https://hackmd.io/@cryptoecon/r1Vp7B8xo

[anorth]

Thanks Kaitlin! I appreciate the concise yet quite clear proposals.

Proposed updates

These sound generally great to me and ready to implement. I've only a couple of minor suggestions:

• I'm not sure we need "failed" status for FIPs. I would just say they haven't reached acceptance yet. In most cases I'd expect authors to withdraw or supersede them. I think many of us involved don't think we should use the kind of binary voting procedure that could lead to a "failure" in the future (and even if we did, it could still be seen as "no consensus yet").
• What's an Idea stage FIP? If this refers to ideas that are in discussion phase in the forum, I don't think we need call it as a formal FIP stage, just an expected process before creating a draft.

Proposed change

Big 👍 to the general proposal here for a well-defined governance working group, entrusted to make decisions when other methods fail.

• There is a challenge with any use of voting by Core Devs to determine GWG membership, because the former group is not so well defined. At the very least we'd need to maintain clear membership here, for the occasional cases it's needed. As a group leaning towards inclusivity, there will be few barriers to entry.
• The GWG seems quite large, potentially beyond the size of group that can easily share high context, or ever meet synchronously. I concur we need some membership to bring sufficiently diverse perspectives and expertise. But I'd consider halving the proposed counts.

Should members of the GSG be allowed to serve as FIP authors? If so, should they be allowed to vote on their own FIPs?

It would be rather limiting to prevent GWG members from authoring FIPs, as good candidates are likely quite involved in protocol development. So I'd say yes to the first question. For the second, I don't see any first-order problem with allowing vote on their own FIPs, but the issue might be the incentives it creates to get on the GWG just for that vote in case it arises. I think the message sent by "no vote on your own FIPs" is good. It could be gamed by a team just nominating other authors, but overall I think it's probably a good rule: getting more GWG membership reduces a team's ability to push its own proposals. Teams should focus on clear communication and justification of proposal merits instead, to induce other votes.

[zixuanzh]

If we are moving to representational governance, I would like to understand better the principles and rationale in selecting groups of representation. Why is it only for implementation teams? Why is it equal weight across teams? What is the basis of governance? We can dedicate some resources and propose something based on first principles if it will be helpful.

[Fatman13]

The group should serve as a technical governance group that offers mediation and decisionmaking in the case of consensus failure for especially complex FIPs

Does it mean that GWG is kind like electoral college? It has the power to push through FIPs without consensus from stakeholders like SPs, exchanges and ecosystem partners?

IMHO "especially complex FIP" shouldn't be added to L1 at all. It will likely to add more complexity to the growth challenges the network is already facing today. Moreover, the amount of catchup a new SP has to do to join the network now is already quite hefty.