Draft of Phasing Out Fil+ and Restoring Deal Quality Multiplier to 1x

[dcasem]

Draft of Phasing Out Fil+ and Restoring Deal Quality Multiplier to 1x (Option 1 of Discussion 774)

[kaitlin-beegle]

Hi @dcasem, thanks for the PR Any conversation about the substantive content of the draft can continue in the discussion thread; our objective here is to ensure that this FIP is reviewed for formatting and completeness. This is a step that all FIPs go through.

That said, after initial review, I think there are a few things to work on together.

First, a nit for FIP Authors - Your draft needs to follow the FIP template. Your structure mostly looks good, but please go ahead and update the file to include the FIPs header when you can.

Secondly, this FIP obviously seeks to change core components of Fil+. What is less obvious, however, is how this should be governed.

Protocol governance and Fil+ governance have ALWAYS been separated; FIP0003 introduced Fil+, and gave the Fil+ community the ability to self-govern. And, importantly, the purpose of Fil+ is simply "...to maximize the amount of useful storage that Filecoin can and will support". Anything beyond this- the 10x multiplier, the election and maintenance of notaries, etc.- are programmatic choices that have been put in place by Fil+ governance processes, NOT the FIPs process. The only FIPs we accept (for example HERE and HERE) are those that may incidentally affect Fil+ due to protocol -level changes that are good and sound policy, and are not about Fil+ per se. When we have received FIPs aimed at Fil+ specifically (example HERE) they have been categorically rejected. This is simply not the purview of the FIPs process.

This FIP wants to remove Fil+, but seeks to do so by targeting a programmatic choice (the 10x multiplier) that should normally be governed by the Fil+ community. It is entirely reasonable that the Fil+ community could decide to remove the 10x multiplier and experiment with other ways of achieving their stated goal which, again, is not a FIP prerogative.

I do not believe this FIP can be specified on programmatic issues in the way that this one currently is. Whatever final proposal the authors settle on, this FIP needs to be written to supercede FIP0003. This will mean justifying why the mission of Fil+ no longer holds, and articulating (both conceptually, but also technically) what this change would look like in the spec. There is a broader issue of how much technical specification should be necessary or required, but I don't think we can answer this question until the draft is more tightly confirmed. Community conversations about this topic are still evolving, and I suspect the authors will want to propose additional changes and specifications to the content, etc., over the coming weeks.

Normally, we would just reject at this stage, but given the importance of the topic and the level of discussion, let’s work together on getting this into an acceptable form. A rejection would be appropriate, but would likely send the wrong signal.

FIP editors: @jennijuju @raulk @momack2 @arajasek @anorth any additional comments?

[The-Wayvy]

Yes, let’s work together to make the protocol permissionless. 100%

[jsoares]

Protocol governance and Fil+ governance have ALWAYS been separated; FIP0003 introduced Fil+, and gave the Fil+ community the ability to self-govern ... When we have received FIPs aimed at Fil+ specifically (example #203) they have been categorically rejected. This is simply not the purview of the FIPs process.

Without getting into discussions about the content of the FIP, I strongly disagree with this interpretation, whose implications are wider and more dangerous than anything having to do with Fil+.

FIP0003 explicitly delegated operational governance to the Fil+ community; it did not cede the power to govern it. This is analogous to the way that Congress gives the SEC latitude to draft market regulations within the constraints set by legislation or that corporate bylaws fill in the voids in the articles of incorporation.

In all of these cases, the goal is practical: minor procedural changes or clarifications should not require an act of Congress, an amendment to the articles of incorporation, or a FIP. However, the higher body retains the authority to revoke that delegation or to pass further resolutions constraining the delegation or restraining the delegate in whatever way it deems appropriate. A summary rejection on the aforementioned grounds would be highly improper.

That said, I agree that this FIP would be best written as superseding FIP0003. But that's strictly a matter of format, not one of forum or authority.

[dcasem]

@kaitlin-beegle It's essential to recognize that Fil+ was introduced through the FIP process via FIP0003. This establishes an irrefutable precedent that the FIP process has jurisdiction over Fil+ and retains the inherent power to amend or repeal it.

Arguing that FIPs aimed at Fil+ have been categorically rejected due to a supposed separation of governance contradicts this foundational principle. If a FIP can create Fil+, it logically follows that a FIP can repeal or modify it.

The support this FIP has garnered, with more than 53 upvotes and unprecedented engagement, clearly indicates the community's direction. The pull request process can manage any necessary modifications to the proposal.

It has been four days since this pull request was submitted. We look forward to edits submitted by the editors to achieve the will of the community, aligning the proposal with the demonstrated support and expectations.

[kaitlin-beegle]

Protocol governance and Fil+ governance have ALWAYS been separated; FIP0003 introduced Fil+, and gave the Fil+ community the ability to self-govern ... When we have received FIPs aimed at Fil+ specifically (example #203) they have been categorically rejected. This is simply not the purview of the FIPs process.

Without getting into discussions about the content of the FIP, I strongly disagree with this interpretation, whose implications are wider and more dangerous than anything having to do with Fil+.

FIP0003 explicitly delegated operational governance to the Fil+ community; it did not cede the power to govern it. This is analogous to the way that Congress gives the SEC latitude to draft market regulations within the constraints set by legislation or that corporate bylaws fill in the voids in the articles of incorporation.

In all of these cases, the goal is practical: minor procedural changes or clarifications should not require an act of Congress, an amendment to the articles of incorporation, or a FIP. However, the higher body retains the authority to revoke that delegation or to pass further resolutions constraining the delegation or restraining the delegate in whatever way it deems appropriate. A summary rejection on the aforementioned grounds would be highly improper.

That said, I agree that this FIP would be best written as superseding FIP0003. But that's strictly a matter of format, not one of forum or authority.

@jsoares yes, thanks, but I want to be clear that you and I are not saying substantively different things. You've chosen to describe nuance with different words, but the metaphor holds. I am not saying that FIPs cannot govern FilecoinPlus; I am describing how this FIP needs to be specified in order to do just that.

FIPs do not care about the specification of the multiplier; they can about the specification of the program, and that's what this FIP ought to address.

I appreciate your comments. I just don't want there to be any confusion about this. Ensuring style and process consistency is the sole job of FIP Editors, and the FIP Authors shouldn't be surprised when they receive a lot of editorial feedback.

[jennijuju]

Anything beyond this- the 10x multiplier, the election and maintenance of notaries, etc.- are programmatic choices that have been put in place by Fil+ governance processes, NOT the FIPs process.

I dont think I agree with this point exactly. While I think it is reasonable to say, how FIL+ programs (i.e: notary election process, dispute programs, and so on) are instrumented and executed are suppose to (at least implied so far) be governed by FIL+ governance - any core protocol changes, i.e: change of the FIL+ principle (via organizational FIP process) , change for the existing FIL+ protocol implementation (today being the verifreg and datacap built in actor, deal multipliers, and etcs via core technical FIP process), should ideally be

• ideated within FIL+ community and governance
• progress to FIP process for protocol update governance

Using the "restoring deal quality multiplier to 1x" idea as an example, it should go through an FIP process for a couple reasons imho

• It is a core protocol change that requires input from protocol development, cryproecon, network security & related perspective - which I would expect other than the community in general, core devs need to help review and refine the proposal and flag any potential uncovered impact it may cause.
• It is proposing a consensus breaking change and require a network upgrade to introduce. Like any other changes - it should go through the FIP governance process.

[dannyob]

My read of this is that there's essentially two-step FIP process for this. One is revising FIP003 to allow for a FIP multiplier change, and then executing the multiplier change. I'm not enough of an expert to know whether this should be broken up into two separate FIPs, or just two different parts of the same FIP.

@kaitlin-beegle isn't saying this is impossible through the FIP process, it's just that we don't want to end up with mutually contradictory, but still in force FIPs.

[jennijuju]

Reading through the FIP draft, I agree with @kaitlin-beegle's assessment here

Whatever final proposal the authors settle on, this FIP needs to be written to supersede FIP0003.

As the PR is written today, FIP authors are effectively proposing to suspend FIP-0003, rather than keeping the core principle of FIP-0003 in the protocol but improving how it is being implemented (i.e: redefine the multiplier mechanism).

improving how it is being implemented.

It is worth calling out there were a couple alternative solution being proposed as the core issue and expectation was refined in the FIP discussion, for example, here, here and here))

[jennijuju]

Note - in DM with @dcasem (main author of the FIP proposal), it is my understanding that they have the intention to work with @anorth on the alternative solution being proposed and update the FIP draft accordingly (to be more specific, this FIP directly). So base on where that proposal goes, my feedback as FIP editor above might be discarded. Happy to review again when it is up.

Normally, we would just reject at this stage, but given the importance of the topic and the level of discussion, let’s work together on getting this into an acceptable form. A rejection would be appropriate, but would likely send the wrong signal.

Kaitlin does have a point here imho. @dcasem given you have the intention to continue evolving the FIP proposal towards to its acceptable form, would you be open to convert this pr into Draft and reopen it when the updates are in?

[Fatman13]

Reading through the FIP draft, I agree with @kaitlin-beegle's assessment here

Whatever final proposal the authors settle on, this FIP needs to be written to supersede FIP0003.

Could FIP editors (@jennijuju @kaitlin-beegle) please clarify on why this FIP need to supersede FIP0003? Hypothetically speaking, if the changes offered by @anorth is incorporated into the FIP, there is nothing stops Fil+ to continue to exist on its own given the description of the program in the FIP0003.

[dcasem]

would you be open to convert this pr into Draft and reopen it when the updates are in?

@jennijuju the FIP as it's proposed is complete. As mentioned in the discussion, we are amicable to the proposal put forward by @anorth. We believe there is substantial overlap between this FIP, and any eventual future version of it that incorporates a free choice multiplier. We are happy to respond to to additions, in-line edits, etc. in the document. We look forward to FIP Editors' comments and contributions; we welcome co-authors.

[jennijuju]

Reading through the FIP draft, I agree with @kaitlin-beegle's assessment here

Whatever final proposal the authors settle on, this FIP needs to be written to supersede FIP0003.

Hypothetically speaking, if the changes offered by @anorth is incorporated into the FIP, there is nothing stops Fil+ to continue to exist on its own given the description of the program in the FIP0003.

please re-read my messages again, where I stated the feedback on current draft here and potential updates/evolvements of the the draft here

[anorth]

the 10x multiplier ... are programmatic choices that have been put in place by Fil+ governance processes, NOT the FIPs process.

I don't think this is correct. The 10x multiplier is specified in the protocol code here, existed at network launch, and could only possibly change or be removed via FIP. This is an entirely valid target for a FIP.

While this FIP is far from complete, I do not think rejecting it would be appropriate. I agree it should probably reference FIP-0003, perhaps to explain that the principles proved difficult to live up to in practice, or something.

I have been holding off from putting much time into editorial review here while the discussion has been so lively. I expected things to change and to review in detail once those changes were reflected in the draft. There does seem to be significant alignment around an implementation path, "free multipliers", that is quite different from that specified at present.

To avoid any confusion, while I am pleased to help the community identify and understand the impacts of various implementation ideas, and find ways to make them work safely and effectively, I have no intention of authoring or co-authoring any FIP, including this one, about them. I will willingly help identify where the specification falls short and help authors craft a more complete one, but I am not leading anything.

@dcasem do you intend to update this draft to adopt the free multipliers concept, or will someone open a new one, or will you continue this no-multipliers proposal?

[dcasem]

This PR has been waiting for review for a week. When can one be expected?

[Fatman13]

@filecoin-project/fips-editors New edits have been merged given the latest review. Please let us know if additional changes are needed. Thank you!

[Fatman13]

Hello, @filecoin-project/fips-editors, it has been 2 weeks since last edits were merged per review. Please kindly let us know if there is anything else we need to fix. Thank you!

[anorth]

The fact that pledge collateral requirements fall due to baseline crossing just make the problem even worse. It's not a mitigation.

[jsoares]

I think the argument being made is that by reducing non-hardware costs, more hardware will be onboarded to secure the network -- that seems reasonably intuitive in any scenario of finite SP financial capacity. It doesn't follow that this results in "increasing the cost to attack" as a very significant increase in storage capacity (certainly more than the 2x comparison between current and peak RBP) would be required to match the same level of resources at stake. This is not a deal breaker -- it's a choice -- but also not something that can be swept under the rug.

[Fatman13]

Resolved.

[jsoares]

Save for a couple of issues raised in Alex's review, I believe this is now detailed enough to merge as draft and discuss. I'm leaving my approval here, but expect the aforementioned issues to be resolved.

[jsoares]

Suggested change

If one's view on network consensus seurity aligns with the explorations released [here](https://pl-strflt.notion.site/2023Q3-Cost-of-Consensus-Security-Hardware-bda873f0c8a74387abeccd8c722abd59?pvs=4) and [here](https://pl-strflt.notion.site/2023Q3-Cost-of-Consensus-Security-Pledge-d9374ec5b68244c6b50fcb8c16ec113c?pvs=4). The proposed change may be perceived as lowering network consensus security because lowered pledge cost in the network attack strategy model of `HDDCost + StoragePledge + FutureEarnings`. However, the risks will likely be mitigated by the fact that **significantly** lowered initial pledge requirements will likely to incentive more hardwares to be onboarded to secure the network, which previously peaked at 17 Eib as opposed to 8 Eib right now thus increasing the cost to attack.

If one's view on network consensus security aligns with the explorations released [here](https://pl-strflt.notion.site/2023Q3-Cost-of-Consensus-Security-Hardware-bda873f0c8a74387abeccd8c722abd59?pvs=4) and [here](https://pl-strflt.notion.site/2023Q3-Cost-of-Consensus-Security-Pledge-d9374ec5b68244c6b50fcb8c16ec113c?pvs=4). The proposed change may be perceived as lowering network consensus security because lowered pledge cost in the network attack strategy model of `HDDCost + StoragePledge + FutureEarnings`. However, the risks will likely be mitigated by the fact that **significantly** lowered initial pledge requirements will likely incentivize more hardware to be onboarded to secure the network, which previously peaked at 17 Eib as opposed to 8 Eib right now, thus increasing the cost to attack.

[Fatman13]

My bad. Resolved.

[jsoares]

I think the argument being made is that by reducing non-hardware costs, more hardware will be onboarded to secure the network -- that seems reasonably intuitive in any scenario of finite SP financial capacity. It doesn't follow that this results in "increasing the cost to attack" as a very significant increase in storage capacity (certainly more than the 2x comparison between current and peak RBP) would be required to match the same level of resources at stake. This is not a deal breaker -- it's a choice -- but also not something that can be swept under the rug.

[anorth]

Ok, after the outstanding minor issues are addressed, I agree this is good enough to merge. I don't think it's great, probably not quite ready for last call. The text seems to be trying to do the very minimal amount of work to explain the issues. But we could iterate forever here until editors eventually get worn down pushing for better. So yes, let's merge this and improvements can come via new PRs to the draft.

@Fatman13 please take number FIP-0080. Update the draft to include this in the filename and header. Please also update the README to include this FIP in the table.

[Fatman13]

@filecoin-project/fips-editors New edits have been made per review and FIP number updated. Thank you for all the reviews! Really appreciate them!

The text seems to be trying to do the very minimal amount of work to explain the issues.

We will keep up the pace of PR to improve on the writings. Comments and reviews are welcomed!

[Fatman13]

Hello, @filecoin-project/fips-editors,

I trust this message finds you well. I am writing to request your valuable input and expertise in reviewing the draft of the proposed FIP. Your insights would greatly contribute to enhancing the quality and accuracy of this document.

We seek guidance of FIP editors' review on directions of which part(s) can be further improved and refined to move forward. Your feedback on the clarity of the language, coherence of the arguments, and overall structure would be immensely valuable.

If you could spare some time to review the draft, it would be highly appreciated. Additionally, any specific comments or suggestions you may have would be instrumental in refining the document.

Thank you very much for considering our request. We look forward to benefiting from your expertise and feedback.