Zero Termination Fees for CC Sectors

[The-Wayvy]

Summary

Set the termination fee of CC sectors to zero.

Motivation

Encourage new miners to try Filecoin (lower barrier to entry)

Decrease risk for all miners (pledge becomes a fully liquid asset)

Rationale

Other chains allow miners to join and leave at will.

Duration requirements handicap Filecoin in the competition to attract hardware/capital without providing any benefits to compensate.

References

Discussion 691

Discussion 712

[Fatman13]

LGTM

[steven004]

A fair proposal.

I support this, aside from zero termination fee for CC sectors, I also advocate for waiving the fault penalty for CC sectors.

To further this, I am particularly keen to simplify the layer 1 protocol and overhaul the QAP design. This involves dividing the current consensus into a combination of PoPW (rawbytes storage) and PoS (collateral), as separate entities, akin to the model outlined in #442.

[Stebalien]

Miners in Bitcoin can come and go because all they're doing is sequencing messages. On the other hand, in Filecoin, storage providers are providing long-term storage for the network and are generally expected to stick around and be online to provide that storage.

My concern is that this proposal (as-is) makes storing user data less attractive when compared to CC sectors as storing user data is now strictly riskier and less flexible. CC sectors are only rewarded at all because they demonstrate committed capacity to the network. They're demonstrating that the SP could use this capacity to store user data.

A middle ground might be a 0 or significantly reduced termination fee for non-faulty CC sectors, with some kind of ramp down delay. That is:

1. The SP submits a ProposeTermination message, marking a set of CC sectors as pending termination.
2. If, after proposing termination, the sector becomes faulty, this mark is removed and the sector is no longer proposed for termination.
3. Finally, some number of epochs later, the SP can submit a FinishTermination message, completely terminating these sectors (with a reduced and/or zero fee).

That way these sectors can still proved that the SP can reliably store data.

The one missing piece here is a demonstration of long-term commitment, which is important for storing user data. One solution there is to have a minimum sector duration where the sector must live for, for example, six months before it can have this zero or low termination fee.

Additionally, I'd like to explore other ramp down solutions such as selling sectors (even sectors with user data) to other SPs.

[taoshengshi]

At the key of this matter is a tragedy of the Commons, a struggle for profit between miners and the public network. Are users and developers involved?

[laudiacay]

heavy +++++ on selling sectors

[laudiacay]

(AA could work for this...? steb idk)

[Stebalien]

SPs that aren't interested or able to reliably store user data are extracting rewards that should go to SPs who are, that's why I care about this. I do want to enable clients and SPs to work together in any way they see fit, but I also want to ensure they're rewarded for it as much as possible: the block reward exists to subsidize this interaction.

In terms of my proposal...

1. I proposed a ramp down delay to ensure only "healthy" sectors can be terminated free of charge (faults cannot be free). Unfortunately this requires a small delay because WindowedPoSt is probabilistic.
2. I don't have strong opinions on my minimum duration proposal. Honestly, it probably isn't necessary given a ramp down delay, users can and likely will prefer SPs with longer track records anyways.

[Fatman13]

the block reward exists to subsidize this interaction.

imo, the block reward exists to encourage new network participants to join & to allow the network to grow, but right now the skewed incentive is doing the exact opposite (decrease of RBP) for well over a year.

I proposed a ramp down delay to ensure only "healthy" sectors can be terminated free of charge (faults cannot be free).

imo, this is the exact kind of core protocol complexity (over-engineering) which are preventing new investment / capital into the network, sprinkles on top of already bloated core protocol.

[anorth]

Thanks for beginning this discussion. I'm broadly supportive and would like to help figure out the details. I think we want to reach a scheme that's as simple as possible without breaking anything significant.

What's a CC sector?

For clarity, I am taking "CC sector" to mean a sector that is provably empty of any data. We can prove this contents by inspecting the data commitment (unsealed CID). After FIP-0076, CC is not the same as "sector without deals" or "sector with FIL+ that expired". The only thing we can simply and reliably test on-chain is "commits to zero data". Once we implement re-snap, it will be possible to transition a sector from "has some data" to "has zero data", but note that that's not possible today.

What fee is reasonable?

I agree with the motivations to reduce/remove termination fees. However I don't think exactly zero is the right number. As I surveyed in #691 (comment), I think there are some reasonable motivations for a non-zero offboarding fee. The most reasonable is to incentivize some stability of pledge (or storage, whichever you want to think secures the network). Complete freedom to add/remove network power at any rate at any time ("flash") makes it unreasonably difficult to ensure incentive alignment.

Almost all other chains, and on-chain applications, except Bitcoin limit the rate of on/off-boarding of pledge ("churn"). They usually do this with a lockup delay, rather than a fee. Lockups are an awkward fit for Filecoin sectors, though, because if an SP has lost the ability or desire to prove a sector, we can't enforce that they keep doing it anyway, whereas a proof-of-stake chain can enforce a token lockup period.

1. We could consider designing a lockup period for the pledge, such that CC termination is free but the return of pledge is delayed. I don't necessarily oppose this, but it adds more complexity.
2. A lockup period for the sectors themselves (like @Stebalien's proposal) is even more complex, and kinda reduces to a termination fee for sectors that aren't proven during the lockup. The protocol must handle physical loss of sectors, but cannot distinguish that from a voluntary withdrawal.
3. IMO it would be simpler to translate the lockup period into a financially-similar fee, by burning notional-lockup-period * notional-interest-rate * pledge tokens immediately on off-boarding. This would be much less than the current termination fees. A ballpark might be 30 days * 15%p.a = 1.23%; the current CC termination fee is a little over 8% of pledge. Maybe the notional period could be shorter.

I would note that actually delaying the release of pledge might have concrete security benefits over a 1% fee, the cost to an attacker with locked pledge being >>1%. I could easily be convinced the lockup is better, and worth the complexity. And maybe a delay is preferable to a fee to the good-faith SP operators anyway?

Further simplifications

If we touch anything related to termination fees, I think we should take the opportunity to make other easy-to-reach simplifications too. We can make the fees for all sectors (not just CC) much simpler, much more efficient, and remove onboarding-epoch bias.

Following the design goals sketched here, I think we should:

• Stop discriminating between sectors based on activation epoch, and specify the termination fee per unit power in terms of current rewards. E.g. CapacityOffboardingFee = 1.23% * ConsensusPledge (or zero, if we do lock-up instead) and DataTerminationFee = 90 * share-of-current-daily-block-reward. A data sector terminated would pay both fees.

This would permit us to remove 20% of active chain state and some code, and make offboarding costs more uniform for all SPs.

(Note that ConsensusPledge does depend on onboarding epoch. I think we should resolve that separately, e.g. #734 or something larger)

[The-Wayvy]

I'm assuming there is no formal analysis available of lock-up duration and consensus security that we could use to make a decision

[anorth]

Yes, I think you're right. We're handwaving a somewhat arbitrary "you can't attack the network without risking tokens for X days after terminating/exiting". I would start with 10-14 days, but yes it's somewhat arbitrary.

[The-Wayvy]

@anorth

Is this FIP ready for Last Call?

I have no objection to starting with a 14 day lock-up.

[rjan90]

Is this FIP ready for Last Call?

I don´t think there is a FIP Draft open for this discussion yet. So first step would be to open a WIP/Draft PR for this change before it can be moved to Last Call, following the template here: https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0001.md#fip-header-preamble. Another example you can look at is this PR: #993.

[anorth]

Theres an as-yet unspecified details of exactly how SPs will send "a message saying they intend to terminate". Equivalently, how to implement a delayed termination. I'm afraid I don't have the bandwidth to figure this out myself right now, but we'll happily review proposals. It will probably involve something in the miner deadline accounting state.