Update status of various nv25/nv27 FIPs and FRCs to 'Accepted' #1189
Conversation
Marks various FIPs that have made it past last call for nv27 to accepted. FIPs/FRCs that were deployed with nv25 were marked as Final.
|
@Tanisha-fil : can you take over this PR (updating the FIP .md files as well)? |
Done. |
|
@Tanisha-fil : I see you created a lot of different PRs here (one per FIP): To make this easier on reviewers, I think we should do all the changes in one PR. (I was thinking you'd just use this PR to make the additional changes.). You can add commits/changes to this PR branch (https://github.com/filecoin-project/FIPs/tree/biglep/update-fip-statuses-for-nv25-nv27 ) and they'll be included in this PR. |
I’ve redirected all my PRs into biglep/update-fip-statuses-for-nv25-nv27, so they’re now consolidated. |
Updated the status of FRC as part of NV27 upgrade
Updated status from "Last Call" to "Accepted" as part of NV27 upgrade.
Updated status from "Last Call" to "Accepted" as part of NV27 upgrade.
Updated status from "Last Call" to "Accepted" as part of NV27 upgrade.
Updated status from "Last Call" to "Accepted" as part of NV'27 upgrade.
Updated status from "Last Call" to "Accepted" as part of NV27 upgrade.
Updated the statuses of all FIPs as part of the NV27 upgrade scope: filecoin-project/core-devs#196 (comment) Co-authored-by: Steve Loeppky <[email protected]>
|
@Tanisha-fil : I have merged all the PRs into this PR. Assuming it looks good to you, lets mark it "ready for review". Also, in future, I can show you how you can do all of this in one PR to begin with rather than one PR per file touched. That will reduce the admin on the reviewer side. |
BigLep
requested review from
TippyFlitsUK,
anorth,
dannyob,
jennijuju,
jsoares,
lanzafame and
momack2
as code owners
|
@Tanisha-fil : I've marked this ready for review. Can you confirm it looks right with all your changes merged in? |
| author: "Hailong Mu (@hanabi1224)" | ||
| discussions-to: https://github.com/filecoin-project/go-f3/issues/480 | ||
| status: Draft | ||
| status: Accepted |
There was a problem hiding this comment.
There is no precedent for accepting an FRC: all 15 previous FRC has been kept in draft status as, by definition, they do not require consensus. I don't think there's an (implicit or explicit) rule that an FRC cannot be accepted, but any particular reason for departing from convention on this one?
There was a problem hiding this comment.
Yes, because this FRC is different from the rest. This FRC needs a network upgrade to ensure compatibility even though it's not a protocol change. The status change is to reflect that it's moved beyond just being a draft standard to having active implementation.
There was a problem hiding this comment.
This argument is both internally inconsistent and inconsistent with FIP-0001 guidance. The bar for what is a FIP or FRC is not whether it is a protocol change but whether it requires agreement (or, per the text, whether users and implementers are free to ignore it). If you're saying this requires agreement, then it's a FIP, possibly classed as Interface rather than Core.
There was a problem hiding this comment.
This FRC is a bit of an edge case. It’s not a protocol change (nodes can still sync from old snapshots, and the chain rules don’t change).But it does require universal coordination to avoid fragmentation. If we allow some nodes to use one ad-hoc snapshot format and others to use a different one, we’d create interoperability and tooling debt.
In that sense, FRC-0108 is unusual because it’s a “standard” that needs to be universally implemented to be useful, even though it doesn’t touch consensus. That’s why we considered it closer to an accepted standard with active implementation rather than a perpetual Draft. The motivation for the Accepted status was exactly to prevent multiple competing snapshot formats from persisting.
I agree this highlights a gap in our taxonomy: FRCs that require coordination but not consensus. One option is to re-classify it as an Interface FIP, but the intent with keeping it as an FRC was to reflect that it’s not consensus-critical while still recognizing its “must-implement” nature.
There was a problem hiding this comment.
Looking at just examples, ERC-20, ERC-721, and ERC-4337 all went to de-facto mandatory because the ecosystem coordinated around them, even though they weren’t protocol upgrades. The reasoning was the same: once a standard is mature and requires universal implementation to avoid fragmentation, keeping it in perpetual Draft doesn’t reflect reality.
That’s the precedent we’re following here for an edge case: FRC-0108 is ecosystem-critical even if it’s not consensus-critical, and marking it Accepted is a way to signal that it’s moved past advisory into active adoption.
Yes, looks good to me. |
|
Also, @BigLep, we don't merge PRs with ongoing discussions. |
5 participants
Marks various FIPs that have made it past last call for nv27 to accepted. FIPs/FRCs that were deployed with nv25 were marked as Final.
TODO: ensure the FIP .md files themselves have the right status as well.