FIP discussion: Allow storage provider to revert a deal back to CC

[Fatman13]

Summary

Given legal consequences a storage provider can face when storing sensitive data, on protocol level, maybe we should allow storage provider to revert a deal to CC to avoid potential prosecution/scrutiny. Basically the reverse of lightweight CC upgrade (now called snap deal).

Motivation

https://filecoinproject.slack.com/archives/C023PAQ5SJV/p1629383994084200

Design

TBD

Consideration

Assume rational storage provider who maximize profits from deals. It should always honour the deal unless there are legal interventions. Market would stop payments once the deal is reverted back to CC. Or for more conservative design, storage provider could be stripped away with all profits they made with the deal thus far, from, for example, locked funds.

Using @ZX's Airbnb analogy, landlord should be able to evict tenant any time they want just like storage provider should be able to revert deal back to CC. Like allowing setting deals to negatives, this also can be seen as a mechanic to grant more flexibility at protocol level.

[dd45e640b42e6da7da96faee3996ef7c]

this would mean making deal fulfillment optional. then we can just not do deals at all and put data into CC and utilize off chain payments

[kaitlin-beegle]

Additional context: this post/proposal is one in an ongoing conversation that storage providers are having regarding personal liability for illicit content stored on Filecoin.

Other relevant ideas include discussion post #132

[nicola]

Currently, the rational guarantees of a deal are also tied to the guarantee of a sector. If a miner were to remove a deal, they might have to lose more than the deal collateral.

If we simplify the proposal to the bare minimum, this proposal can be implemented via a new method called TerminateDeals(dealIds []Deal) in the miner actor.

If a deal is terminated (or expired), you can use the ProveReplicaUpdate skipping the deals you want to stop storing - which effectively allow you to remove the data.

---

Concerns:

• Technically it's not hard, the hard part will be the cryptoeconomic guarantee of the storage market - for which @zixuanzh is an expert.
• Since the miners are actually storing an encoded version of the data (file is "xor-ed" in the sectorKey), I wonder if they could claim that they are not storing the bad file in the clear and hence avoid sanctions of any kind.

[dd45e640b42e6da7da96faee3996ef7c]

i see the storage provider collateral at stake for this (you terminate the deal, you loose the collateral) and therefore increasing if deals can be terminated

[kaitlin-beegle]

Hi @Fatman13, this post has now been open for longer than a month. Do you plan to write a FIP draft on this topic?

If not, we can also flag this issue to live in our FIPs Discussion forum (coming very soon). That way, your idea remains, even if there are no plans to imminently implement a FIP. Please let me know.

[Fatman13]

Thank you for the reminder, @kaitlin-beegle. Will write a draft. Is there any updated template or we are using the old one? Found one.

[Fatman13]

---

fip:
title: Allow storage provider to revert deal back to CC
author: @nicola, Fatman13 (@Fatman13),
discussions-to: #143
status: Draft
type: Technical (Core, Networking, Interface, Informational)
category (*only required for Standard Track): <Core | Networking | Interface >
created: 2021-09-28
spec-sections:

requires (*optional): <FIP number(s)>

---

Summary

Allow storage providers to revert a deal back to CC.

Abstract

Given legal consequences a storage provider can face when storing sensitive data, on protocol level, maybe we should allow storage provider to revert a deal to CC to avoid potential prosecution/scrutiny. Basically the reverse of lightweight CC upgrade (now called snap deal).

Change Motivation

From a discussion thread in SPWG, concerns were raised as there is currently no means for storage providers (SP) to remove undesired data from their own storage systems without invoking "terminate" command, which may cause financial losses to SPs.

Specification

Quoting @nicola's comments...

Currently, the rational guarantees of a deal are also tied to the guarantee of a sector. If a miner were to remove a deal, they might have to lose more than the deal collateral.

If we simplify the proposal to the bare minimum, this proposal can be implemented via a new method called TerminateDeals(dealIds []Deal) in the miner actor.

If a deal is terminated (or expired), you can use the ProveReplicaUpdate skipping the deals you want to stop storing - which effectively allow you to remove the data.

Design Rationale

TBD

Backwards Compatibility

Should current deals be allowed to revert back to CC, or should it only concern new deals made after this potential FIP?

Test Cases

TBD

Security Considerations

Again quoting @nicola's comments...

Technically it's not hard, the hard part will be the cryptoeconomic guarantee of the storage market - for which @zixuanzh is an expert.

Incentive Considerations

Assume rational storage provider who maximize profits from deals. It should always honour the deal unless there are legal interventions. Market would stop payments once the deal is reverted back to CC. Or for more conservative design, storage provider could be stripped away with all profits they made with the deal thus far, from, for example, locked funds.

Product Considerations

Using @ZX's Airbnb analogy, landlord should be able to evict tenant any time they want just like storage provider should be able to revert deal back to CC. Like allowing setting deals to negatives, this also can be seen as a mechanic to grant more flexibility at protocol level.

Quote from one of the SPWG members...

To actually adapt to the real work, filecoin storage providers will need a tool to handle government requests to remove illegal content. Just like cloud providers are today. This is just a matter of Filecoin only being at the stage of proving its technology, and not moved into the area of handling real life application.

Implementation

TBD

Copyright

Copyright and related rights waived via CC0.

[kaitlin-beegle]

Great, thanks @Fatman13!

Tagging @zixuanzh to help provide feedback on the cryptoeconomic impact of this proposal.