Capped Penalty for Sector Termination and Fault Slashing

[steven004]

Several discussions have taken place regarding the collateral dilemma for supporting the power growth of storage providers (SPs), as mentioned in issue #666 . The underlying reason for this is outlined in #334 , highlighting the potential undesirable outcomes resulting from sector faults.

This proposal suggests implementing a capped penalty for sectors, encompassing both fault slashing and termination fees. The aim is to establish a predictable risk model for the lending market, and make the penalty more practical and reasonable.

Problem

1. The unpredictable nature of penalty risks makes it very challenging to create a contract that satisfies both lenders and borrowers. It is also difficult to strike a balance between interest rates and risks.
2. Unpredictable penalty risks deviate from standard practices even in real-world scenarios. General service contracts typically define boundaries for penalties incurred due to service interruptions or outage.

Currently, if a sector remains faulty for 42 consecutive days, it is automatically removed from the chain state and incurs a termination fee. However, if the faults persist for a shorter duration before recovery, it may lead to excessive slashing throughout the sector's lifecycle. This raises the question of why a sector should not be terminated if faults persist for 41 days, recover for one day, and then experience another 40 days of faults.

Proposal 1

Introduce a capped penalty for sectors that includes fault slashing and termination fees, such as setting it at 90-day block rewards.
This approach aligns with general service contracts, where boundaries for penalties related to service interruptions are defined. In this case:

• Storage providers enter into a contract with the Filecoin network to offer power through a specific service, ensuring consensus and acting as data containers.
• Storage providers earn block rewards proportionally based on their ability to maintain power efficiently.
• In the event of sector faults, storage providers incur penalties to the network, capped at a maximum of 90-day block rewards.
• Once the penalty reaches the capped value, the power is permanently removed.
• The storage provider has the ability to terminate a sector at any time, with the maximum termination fee not exceeding the capped penalty minus the accumulated fault slashing fee already paid by that sector.

Proposal 2 (for future consideration perhaps)

Eliminate termination fees and slashing altogether, simplifying the process, as mentioned in #691 comment.

However, this may raise concerns about the data storage service agreement. Who would be willing to store data in Filecoin if sectors could be terminated without any penalty?

This option may not be feasible until we transition market, deal, and data handling to the upper layer, with operational services in place. By that time, we hope to achieve a data service level agreement for deals between clients and storage providers within user contracts, without impacting consensus.

Further Discussion

1. Should the capped penalty be adjusted based on the sector's duration? For example, should the capped penalty fee differ for a 1-year sector compared to a 3-year sector? In other words, should the capped penalty be a percentage of the expected block rewards over the sector's entire lifecycle?
2. Should termination be enforced earlier, rather than waiting until the capped penalty is fully reached?
3. Is it possible to implement proposal 2 directly at this stage?

[steven004]

Btw, this is originally commented in #334 . Moving it here for comments as a separated discussion thread.

[zhiqiangxu]

I support this, as it's a precondition that lending market for SP is possible on fvm.

[mingxiaokai]

Is the 90-day reward based on the estimate at the time of encapsulation?

[steven004]

The 90-day rewards in the proposal is just an example. The detailed number is to be discussed.
No matter how the capped penalty is defined eventually, I think what you mentioned is reasonable, it might be easier to calculate the capped penalty based on the state at the time of proof submission, which also matches the current implementation.

[anorth]

Thanks for raising, @steven004. This is worth exploring, but I think there are challenges with any scheme that alters a sector's future penalties depending on its past. My understanding is that you are proposing accumulating a per-sector penalised amount, and terminating a sector if that amount is exceeded at any point, cumulatively, during the sector's life.

I don't think we would be happy ending up with a scheme where some previously faulty sector faced a much lesser termination penalty than some others. Whatever the penalty cap, C, is, it would have to be much more than one termination penalty TP. As soon as a sector uses up C-TP of penalty, we would have to terminate it. Otherwise, this sector can misbehave at a discount to other sectors (analogy: if ex-convicts got reduced sentences for repeat offence).

Maintaining per-sector history information (even just one number) is extra per-sector state and heterogeneity, which I think we should be moving away from as a general design goal. It's costly on chain, and complicates some future scalability ideas.

One thing we could easily do is reduce the 42 days to a smaller amount. I have forgotten why it was increased from 14 originally (I think I was absent when this happened) – maybe the justification is no longer relevant?

If we still need the long time period, it may be possible to reduce the daily fee charged to a repeatedly-faulty sector such that the total 42*FF+TP is less than the current total. But each additional day still needs some penalty to act as incentive to either terminate or recover promptly.

I think this is all orthogonal to ideas about changing termination penalty amounts – we can discuss both in parallel. I doubt we can justify zero termination penalty, but there may be room to adjust these penalties generally.

[steven004]

This kind of thing would be much better solved with smart contracts intermediating the miner actor, with arbitrary logic, ACLs etc.

Agreed. That's why I support move this kind of data fault slashing into contracts, in other words, no slashing and termination fee at all at the core protocol.

I'll be much happier to support changes in support of that than forcing a arbitrary decision about that on all SPs inside the protocol.

I have different opinion on this understanding. I agree what you mentioned literally. However, we have already an arbitrary decision about that on all SPs inside the protocol, which is forcing termination of a sector at the time of 42-consecutive-day fault. The questions is why? why we should terminate a sector with 42-consecutive-day fault, or just let the SP handle it. I would think there are two reasons behind:

1. the service quality is significantly degraded to lower than the minimum SLA, then, terminate it and remove corresponding power;
2. to avoid too much penalty, which could significantly larger than the collateral;
   If there are any other reasons, please name it.

Considering the reason 1), the service quality could be much lower than 42-consecutive-day fault and recover if an SP have a sector fault 300 days in one year; why this should not be terminated by the protocol?
Considering the reason 2), it is basically not reasonable to punish a service provider more than the collateral, especially in the decentralized world.

So, this proposal is trying to fix the unreasonable arbitrary decision in the current implementation, instead of defining a new arbitrary way.

Again, I do think we could remove all the penalty from sector fault, but apply them to data directly.

[anorth]

I agree that the 42-day (was 14-day) SLA-like maximum fault period is an arbitrary decision inside the protocol. This is market-level logic that was put into the miner actor as a hack during the initial protocol design. When we can support markets that can be aware of faults and implement their own policies, I would advocate for removing this "feature" and letting a sector stay faulty for its entire life.

This would only increase the SP's maximum potential penalty, but again they are free to terminate. The only reason not to is because they think they will recover the sector and that they have positive expected value for doing so.

I don't think minimising SP penalties was a factor in the original design, and certainly not in tripling the delay to 42.

It is very likely that a constant per-day fault fee is excessive for such extended faults. I don't think protocol security requires it indefinitely. I hope we can do analysis to support reducing these fees, which might better get at your aims about limiting SP downside potential. But still I would be reluctant to employ any mechanism that requires per-sector history.

[steven004]

We know it is very popular that an SP needs to borrow FIL from a lender. Let's consider some real cases.

1. A SP S borrowed some token from A Lender L , and L takes S's beneficiary as collateral because L thinks the balance is enough to repay even though early terminating all sectors. One day, S's owner key is taken by a hacker H. Now, the S loses everything. However, H provides S a deal, to work with him together to blackmail L because they could work together to make L lose everything too. That is, they asked L to pay some money to them to ask H or S to terminate all the sectors so that L could take its money back.
2. On the other side, an investor lend money to some SPs, but he asks the owner addresses as collateral for safe. One day, this investor lost everything in Las Vegas. He is on run. However, he remember all the owner addresses and private keys, now he blackmails all the SPs to pay much more than the principle+interest, otherwise, he will let SPs lose everything too.

Even though these are rare and extreme case, but, it could happen, and all these risks the market needs to handle. The problem here is that the penalty is almost unlimited, which is not reasonable.

[steven004]

For the cases listed above, it is quite interesting if you think more about it. For either case 1 or case 2, the claim by the SP or the Investor could not really be confirmed on chain, that is, they could do this kind of blackmail even it is not a real case.

[merceddong]

Completely agree what @steven004 said, though I am not in lending business, but as we talked to those who are from lending platform, they are really struggling to calculate the risk as there is no upper bound of accumulated penalty. And it's hard to understand how security is breached if we set a cap.

[Fatman13]

From what I am seeing, a lot of discussion could be saved if we have a clearer guiding principle of where we, the network as a whole, want Filecoin to be in the long-run.

Consensus V.S. Storage

Filecoin is two completely different things depend on what you want to achieve with it on L1. It could be...

• A) a network that have strong incentive for consensus miner to keep joining the network where consensus mining business model is viable just like in more prominent chains (BTC/ETH). And storage is merely seen as the by-product of the consensus.
• B) a network that focuses on L1 storage. Key components of storing humanity's most important information need to be implemented on L1 to accommodate storage requirements.

Problems

After FIP0018, miners are indoctrinated into believing they are "storage providers" and consensus mining was seen as politically incorrect. Instead of properly incentivize miners into storage providing with value driven / free market principles, network forces its will and in the process distances itself from potential new miners.

With all the storage related gimics introduced on L1, miners are not able to hedge against macro economic uncertainty and complicating L1 protocol further is barring out lots of the potential for the network to grow.

Conclusion

If we are to put the emphasis back on consensus mining, then the answers to many of design choices would be much more clear. All storage related SLA, game theory protocol design could be moved to L2 to further incentivize storage, which in turn making L1 consensus mining more attractive again.

[momack2]

I feel like this conversation is clearly missing the obvious context of Filecoin's mission. Filecoin is a storage network - its purpose is not "consensus mining", and from that context it is correct that we should have significant termination fees that create stability in the storage market of Filecoin, such that clients can trust it as a robust storage layer for their data.

We have an increasing number of prominent clients - now including SETI and CERN! - that are trusting Filecoin for exactly that. This will be even more critical in the future as other compute L2s build on the data stored in Filecoin to access large dataset and store the output of compute jobs back in Filecoin, for access by compute clients. The storage market is not an L2 function of Filecoin, it is core to its design and purpose as an L1. I agree with the desire to simplify - but would suggest these other alternatives that better fit with Filecoin's mission:

• If you want an L1 that is just consensus mining (a la Bitcoin or Chia or some other chain), you could create a new L0 "consensus only" chain that underpins Filecoin and other L1s. Filecoin itself would still correctly utilize this consensus chain to incentivize useful storage.
• When it comes to protocol simplifications, the FVM is a great technology for us to leverage to continually simplify the Filecoin "node" and move more logic into the FVM runtime itself. However the Filecoin L1 itself will still be focused on useful storage (as per our mission and purpose as a network), just bringing more of that logic into easier to upgrade FVM actors.

[The-Wayvy]

Filecoin is a blockchain.

Blockchains must be permissionless.

End of Story.

Ethereum and Bitcoin never had to incentivize 'useful' use cases with a permissioned mechanism.

We don't either.

Everyone who is not on PL's payroll understands that.

"It is difficult to get a man to understand something when his salary depends on his not understanding it."

[nothingjustaminer]

Don't think of a catalyst as a cause. Yes we have an increasing number of prominent clients, however it wasn’t totally caused by significant slashes. The correlation might be 0.1, but we shouldn’t consider it a simple causation. There is an illusion similar to “lecturing birds on flying”. It’s tempting to draw conclusions like this if we have Thought Stamps or prejudice.
Put it simply, you may still have prominent clients even without significant slashes.

Another similar mistake we're making is explaining network pledge and QAP growth by Filplus and its multiplier. The correlation may even be negative here because the raw byte is not lying and you cannot deny it. You may need more curiosity to ask the employees how they feel when they’re bluffing the growth of QAP while ignoring the decline of raw byte. A more reasonable explanation to me would be it's CC sectors made network growth so that Filplus could have a chance to exist, not vice versa.

Can we be more careful before jumping to conclusions @momack2

[The-Wayvy]

@momack2

'useful' will be defined by the market, as it was in Bitcoin and Ethereum.

Your job is to build a neutral platform and let participants find PMF.

The first real use cases will be underwhelming (Uniswap, Aave) and will only appeal to crypto natives.

The big clients that you want to brag about will only come at the very end.

You can't shortcut the process and go straight to making deals with JP Morgan.

And the taxes and subsidies in FIL+ might even price out grass roots innovation and slow down the process.

[The-Wayvy]

@momack2

Molly, why is it that we chose 'storage' as the mission of our network? Why didn't we start with general compute or data retrieval or matrix multiplication for AI models?

The answer is that our consensus algorithm is also a proof of storage.

So nodes/miners/servers maintaining our blockchain all have the hardware necessary to provide storage services. That is not true in Bitcoin and Ethereum. Why? Because they have a consensus algorithm that does not demand lots of storage hardware.

And so we can provide storage services cheaper than other chains because our L1 nodes are equipped for the job.

But the only reason we amassed so much storage capacity is that we had a trustless/permissionless/verifiable/neutral mechanism that incentivized the provision of that hardware.

As soon as you try to force nodes to provide services that require human supervision and cannot be incentivized/enforced by the protocol itself, you will get bad results.

[steven004]

I do not think we will conclude the discussion about CONSENSUS vs. STORAGE any time soon. And we have some other threads talking about this, including #725 , #774.

This discuss is focusing on the sector fault slashing and early termination fee. Here, I would like to propose like the following:

1. TP (Termination Fee) = 70BR;
2. The maximum accumulated fault days: 15, so the maximum fault slash < 14*3.5BR = 49BR

So, the capped penalty of fault slashing and early termination fee is 70BR+49BR = 119BR.

I would leave this proposal here for about one week for more comments before submitting the FIP PR.

[steven004]

An alternative approach to adhere to the original concept of Filecoin's initial pledge collateral design involves the equation:

SectorInitialPledge = SectorInitialStoragePledge + SectorInitialConsensusPledge

Here, the InitialStoragePledge would be set as the capped penalty fee for fault slashing and early termination.

Rational

The InitialConsensusPledge mirrors the concept of a miner's stake in a PoS system, ensuring that rational behavior benefits the network. This approach rewards value creation and penalizes malicious actions through slashing from a consensus perspective. On the other hand, the InitialStoragePledge acts as a safeguard for the network's quality of service for clients by providing collateral for a sector in case of slashing.

While Filecoin already defines certain consensus faults and implements associated slashing mechanisms, sector faults or early terminations are viewed as service quality degradation rather than consensus-based malicious behavior. From a conceptual standpoint, it's reasonable for such slashing to be sourced from the storage pledge.

One challenge lies in the current InitialStoragePledge not being sufficient to guarantee service quality. This implies the need to raise it to a suitable level, like 100BR. This adjustment could be acceptable since the current `InitialStoragePledge constitutes a small portion of the overall initial pledge (about 2.37%). Moreover, this value is expected to decrease as the network's power grows and block rewards decline.

Implementation

1. Increase Storage Pledge: The storage pledge will be adjusted to 100BR.
2. Adjusted Early Termination Fee: If early termination is initiated by users, the early termination fee will be set at half of the InitialStoragePledge.
3. Forced Early Termination: When the fault slashing fee reaches half of the InitialStoragePledge, a forced early termination will be triggered. In this scenario, the early termination fee will be calculated as InitialStoragePledge - totalSlashedFee, effectively resulting in the entire InitialStoragePledge being subject to slashing.

With regards to the SectorOnChainInfo, the following changes will be made to the existing fields:

Original:

    /// Pledge collected to commit this sector
    pub initial_pledge: TokenAmount,
    /// Expected one day projection of reward for sector computed at activation time
    pub expected_day_reward: TokenAmount,
    /// Expected twenty day projection of reward for sector computed at activation time
    pub expected_storage_pledge: TokenAmount,
    /// Maximum day reward this sector has had in previous iterations (zero for brand new sectors)
    pub replaced_day_reward: TokenAmount,

Updated:

    /// Pledge collected to commit this sector, including both consensus and storage pledge
    pub initial_pledge: TokenAmount,
    /// Expected 100 day projection of reward for sector computed at activation time
    pub initial_storage_pledge: TokenAmount,
    /// Total slashing fee due to sector fault
    pub total_fault_slash: TokenAmount,

Please note that the expected_day_reward and replaced_day_reward have been removed, as they will no longer be required in this context.

Additional Points to Consider:

1. The proposed implementation cost is low, and lower than accumulated fault days approach;
2. The introduction of the total_fault_slash field for sectors offers the additional advantage of ensuring a transparent financial report directly accessible from the on-chain state.
3. In the event that all slashing and termination fees are phased out in the future, the two fields (initial_storage_pledge and total_fault_slash) can be removed. This would naturally render the initial_storage_pledge obsolete.

[The-Wayvy]

@anorth

Hey Alex

Do you think we should finalize the no-termination fee for CC FIP here or start a separate discussion?

[anorth]

Separately. There is other background context too like #691. If we touch termination fees I think we should fix some easy other issues too. If that discussion is started, I can outline what I think we should do.