What network changes warrant a FIP?

[raulk]

This post is motivated by the exhibit below, but the discussion should be of general nature in order to better delineate the applicable policy.

nv15 is slated to introduce a change in the VM circulating supply calculation, such that the value remains constant for the execution of the entire epoch, as opposed to being adjusted intra-epoch by gas burns.

This particular case is a bit special. No FIP has been submitted yet because core devs consider that (a) the relevant spec is specs-actors, (b) specs-actors mandates the desired behaviour, (c) however, all implementations are non-compliant, including specs-actors.

Therefore, it has been classified as a "bugfix", suggesting that it introduces a correction to make implementations adhere to the specs, and that no FIP is necessary.

However, I come at this from a different angle:

1. Code is law, and more so in the case of specs-actors (which was conceived as an executable spec). No matter what the comment says, the logic that currently runs in the network takes precedence over the comment.
2. This change is consensus breaking in itself, i.e. it could not be performed successfully without a network fork and implementors coordination.
3. All consensus-breaking changes must be specified in a FIP, including "bug fixes", as this facilitates tracking, discussing, referencing, and managing the change. I don't think there should be FIP-less network changes, and FIP-ful network changes. There should only be network changes, and all should carry a FIP.

In my opinion, a most reasonable process for this case (and other similar cases) is as follows:

1. File an ERRATA against specs-actors to amend the comment to describe the actual present logic.
2. File a FIP to change the spec, and schedule it for nv15.

The broader question here is around the FIP element. What does the community think?

I do recognise that some bug fixes are security-critical, and an ex-ante FIP is a bad choice in those cases. However, those changes cannot escape the FIP process entirely, and after the change has been deployed and the upgrade has reached finality, there should be a public ex-post FIP filed.

[arajasek]

I think this is an interesting conversation. Since mainnet launch, we have had 13 protocol changes go in as protocol tweaks / bugfixes, with another 2 slated for nv15 (one of which is the exhibit used above). I think one thing that is probably non-controversial is that such tweaks should be nicely tabulated somewhere -- the recent section here is an effort at doing that.

Re: @raulk's proposal above, I think the challenge (as always) is that the FIP process needs to accommodate many different things, broadly divided into:

• Complex technical proposals (eg. FVM, SnarkPack, etc)
• Controversial governance decisions (eg. should we penalize certain behaviour?)
• Minor consensus tweaks (this is currently excluded from the FIP process).

I think it's pretty clear why the same process cannot neatly accommodate all 3 -- is there any interesting conversation to be had about the upcoming change that changes the error code returned when someone tries to send themselves 2B Filecoin?

Given that the FIP process is going through an active overhaul, @kaitlin-beegle I think this is mostly interesting food for thought for you :)

Nit re: the specific exhibit used above: the bug isn't actually in specs-actors, it's in the impls like Lotus that are non-compliant.

[kaitlin-beegle]

I'm interested in the nit :)

Can you help me understand a bit more about the motivation for change? Is it related to gas rebalancing for Snap Deals? Or is it really just that the spec lists a behavioral standard and different implementations aren't implementing it correctly? Or, perhaps it's some third option I'm not guessing at?

[arajasek]

It's the second option, completely unrelated to SnapDeals -- the spec (through specs-actors) says that the circ supply reported through the runtime interface should be constant per epoch.

Unfortunately, Lotus has done this wrong from the start (allowing the value to fluctuate as messages are processed in an epoch). I'm guessing the other impls have implemented the same bug in order to match Lotus here.

The fluctuation isn't significant enough to cause any major difference (and so isn't a critical problem), but it's still undesirable and should be fixed because it makes things significantly harder to reason about. It also theoretically means that message costs are affected by their position in the tipset, which is bad.

[kaitlin-beegle]

Cool; thanks for the detailed write-up! I reviewed specs-actors briefly but didn't want to comb through the revision history to see when/if this language had been changed. Glad to have the confirmation, it reinforces my sense that we don't need a FIP for this.

[anorth]

It is certainly the case in the past that many small changes (not only bug fixes) have been implemented without FIPs. This was a fairly explicit decision in the name of pragmatic shipping early on in the network. To mandate accepted FIPs for all changes would have dragged hugely on development velocity, hitting bugfix and cleanup work especially hard. I think much would have been deemed "not worth it" and so technical debt would have accumulated while we added new FIP-worthy complexity.

I think that's still largely the case today. The FIP process is heavyweight and, IMO, inappropriate at the moment to use as a project management process for small changes that uncontroversially aligned with the network participants' interests. Especially changes in actors or their peripheral systems. In the current world of relatively frequent network upgrades (each typically motivated by at least one accepted FIP), we have a working mechanism to coordinate change by bundling these fixed in to those upgrades.

I do expect this to change toward @raulk's proposal over time; not to aid project management but to increase stability (i.e. decrease velocity of change) at lower protocol levels. Our priorities will change from high velocity progress in the core protocol to slower, more predictable change, as we work through the remaining debt and complexity from the push toward liftoff. A critical component of this will be the introduction of the FVM, which will move most application logic into user-programmable contracts and out of the scope of FIPs (into a diverse range of end-user governance processes). These contracts will demand stability of the underlying runtime, and so FIPs for behavioural changes will be both appropriate and, hopefully, infrequent.

My bias here is as a protocol builder who would have to spend much more time on documentation and process, and hence less time on making actual technical progress, if we changed the process for making small behavioural changes.

[kaitlin-beegle]

@raulk, thank so much for raising this issue. Very timely, too!

One goal we have in revamping the FIPs process is to improve situational responsiveness in order to secure better network resiliency. Governance frequently requires that we balance mutually desirable trade-offs, but that doesn't mean that we aren't accountable to that which doesn't receive first priority.

In other words, @anorth and @arajasek are right, that the FIPs process can't do everything; it's worked pretty well in past similar instances, and adding new criterion for consensus -adjacent changes comes with a cost. However, @raulk is also right, that we are responsible for making legitimate decisions about collective network changes.

My perspective is that we ought to address this, but outside of the FIPs process. Since governance in the Filecoin network is primarily deliberative, we do not need explicit consent to make changes as much as we need to provide equal access to decision-making. Some suggestions for doing so:

• Creating a change log for consensus -bound changes, cross-implementation standardization, etc. (Aayush linked an early attempt, but this could be improved)
  • We could require Core Devs to review and sign off on changes before an update, etc.
• Requiring consensus for network upgrades via a new, separate type of FIP
  • Could be designed to be non-controversial and mostly good documentation, would have to explicitly exclude the acceptance of other FIPs so as not to require 'double' approval on proposals
  • Could be managed via voting (which everyone always wants, of course)
  • I have a feeling everyone will balk at this, but I actually like the idea...it would formalize the network communication work that @jennijuju is already doing.
• More explicit notification of the intent to change, which would not only provide clearer information to those who need it but would also give anyone the opportunity to raise an issue with, ask questions about, etc., a proposed change.
  • Lots of things this could look like, including notices on Github, in Core Devs calls, or in Slack via a bot that monitors and reports on the change log mentioned above :)

I'm open to feedback on these suggestions, as well as other ideas folks may have. If anything, though, I do not think we should (or need) to submit a FIP to address this issue in v15. Happy to elaborate on this in greater detail if anyone is interested.

[kaitlin-beegle]

(Also flagged this issue for our friends at Block.science, who may be interested in providing their thoughts.)

[jennijuju]

however, all implementations are non-compliant, including specs-actors.

Like @arajasek has pointed out - this is not true and the spec-actor has implemented as what the spec/comment in code says. So for implementations that compliant with the spec-actor, this won't be a network change for them.

Standardize the process and making sure a detailed Changelog is created is a great idea. I strongly agree good documentation and reaching consensus for network upgrades are important, and require all core implementers to participate and engage in the process.

I think we should dig more into the post communication on implementation specific security fixes - are they considered as network changes, if the change only apply to the users of the implementation involved? post-FIP is definitely an interesting idea that we should explore more, as it helps with transparency and historical change tracking.

Could be managed via voting (which everyone always wants, of course)

I think voting on network upgrade is very tricky :

• what's the voting mechanism? how to weigh the votes?
• when to vote? what happens when all the FIPs are accepted but the community vote against a network upgrade?
• How do we deal with urgent upgrades with this mechanism?

[kaitlin-beegle]

Fully agree - voting is never my preference, but it is an option (since 'should we upgrade the network' is a more binary choice than FIP proposals are).

Regardless, my agreement is more with the idea that we have opportunities to improve documentation, especially during the process of making decisions.

[raulk]

Thanks for all the responses. It's great to see the community cares so much about transparency, communication, and structure in change management ;-)

The majority of the pushback here has to do with the approval and consensus process around FIPs. Let me clarify my original stance a little bit. My motivation is NOT to subject bugfix changes to the same ceremony as evolutive protocol changes. That would grind us to a halt for things that are obvious and generally undisputed.

The bulk of my concern comes from the loss of traceability of network changes if we make FIPs optional for certain cases. My view is quite pragmatic here: I regard network versions as collections of FIPs, and this is also how other networks deal with change mechanisms (e.g. Ethereum, Bitcoin).

This boils down to me imagining future conversations. Five years from now, I don't want the Filecoin community to have to refer to this concrete change to "that circulating supply fix that went into nv15", but rather as "FIP-nnnn". This is unambiguous, well specified, does not rely on human memory, nor forensics by digging through filecoin-project/tpm notes when future folks need to trace why there was a small change in VM execution logic, at some point in time.

I like where @kaitlin-beegle is going with her suggestions. However, I would push back on maintaining a change log outside the FIP repository due to the extra indirection and process complexity.

My concrete suggestion is to create the notion of "corrective FIPs", a lightweight, informational FIP that acts as the formal recording of a bugfix/correction/defect resolution, where a network change is needed to fix something that is not working as intended/specified, so long as certain constraints are met (doesn't affect incentives, etc.)

This is in contrast to evolutive FIPs where the network's functionality is headed in a new direction, or adaptive FIPs where the network parameters are adjusted to account for new situations. Discussion for those FIP classes should be broad and inclusive. However, corrective FIPs could be automatically approved through informal core devs consensus; community opposing should be very extraordinary.

@kaitlin-beegle I also +100 your idea of "release FIPs", basically serving as release manifests.

[zixuanzh]

Havent had time to page in deeply on the whole FIP discussion but just calling out that sometimes seemingly “uncontroversially good” are not necessarily the case. I was going over past FIPs to onboard someone and realized that HyperDrive actually “started” in FIP8 and resulted in a loss in protocol revenue that hurts the interests of token holders in the short term but we havent had too much of a discussion since it was considered “uncontroversially good” by devs.

I personally think anything that touches the token (gas, collateral, reward, network fee, circulating supply), behavior, and policy should warrant a FIP and longer lead time (sometimes 3 weeks is not enough given how much other things we have going on). We also caught a bug in the implementation of the CircSupply change that this discussion referred to 🙂 (the lead time was 24 hours).

[yeqbfgxjiq]

Agree with @zixuanzh that anything that touches the token (gas, collateral, reward, network fee, circulating supply), behavior, and policy warrants a FIP and longer lead time.

Beyond that, reading between the lines, it seems like some of the dynamics at play here might be cultural: a startup mentality of building something people want vs a "crypto/Web3" mentality of building something people want to be part of (that also produces something people want). One requires moving fast to ship, while the other requires moving slow so that everyone moves forward together. This is often at odds, especially in the early days of a project.

So if I put on my startup hat I totally sympathize with not wanting to get bogged down in documentation and bureaucracy, but if I put on my "crypto/Web3" hat then I'd want anything that changes core properties of the system (consensus, token dynamics, etc) to go through a transparent and accountable process. The key is finding that balance: a process that is functional enough, yet also transparent enough, for now. I don't know where that balance is. I do know, however, that it's critical that any formalized values or processes reflects what people really want - not what they think they should want - otherwise the formal process will be in conflict with the informal culture.

Not sure if that's helpful, but with whatever path forward makes the most sense the key is going to be finding a process that's both adaptive/fast enough to build, while also being accountable/transparent enough for wider participation.