FIP Discussion: migration deal

[Fatman13]

Summary

Given the need of storage migration, I propose a new type of deal besides storage deal, a migration deal.

Motivation

As stated by Juan in this comment.

Storage providers must be able to relocate their operations (without it being cost prohibitive).

Design

Like a storage deal, a migration deal can be initiated by SP A to SP B using online or offline methods. Once data (sealed sector/sealed deal) transfer is done and proper messages sent out on-chain, storage power of A (dictated by the migration deal) will be transferred to B without any service interruption of the actual storage deal/CC and the burden of maintaining windowPost of such transferred sealed sector/deal from a migration deal now falls upon B.

Residue locked funds of A for that sector can be reimbursed by setting the ask price of the deal (on B's side) so that current mechanism is not affected. Or just let it be determined by the market itself.

Use Cases

• SP A operates two nodes A1 and A2 and A wants to transfer power from A1 to A2 without service interruption
• When hardwares reached their lifespan and needs to be decommissioned
• When SP find a better IDC (lower priced, easier logistics, or just out of personal preference)
• SP A wants to liquidate and sell all its power to other SPs
• Local regulation forces SP A to stop operation before some date
• SP would like to merge two nodes into one
• Long deal duration from client (for example, 10 years)
• Move to another miner id

Consideration

This effectively creates a market of buying and selling of storage power while enabling migration of data. It is comparable to buying and selling of a mortgage among financial institutions.

[jennijuju]

Oh so this is like service ownership transfer?
I dont see any mentioning of client use case in this proposal, could you please elaborate more on that perspective?

Also - do you imagine SP A loses the power once the deal is transferred, too?

[Fatman13]

Oh so this is like service ownership transfer?

Yes.

I dont see any mentioning of client use case in this proposal, could you please elaborate more on that perspective?

Updated more use cases.

Also - do you imagine SP A loses the power once the deal is transferred, too?

All I have is a very high-level idea now. Haven't dig as deep. Will iterate on that.
Yes. That should be the idea. Not sure if it make sense to others.

[FroghubMan]

I think it is necessary to support the use of original data for resealing, or the use of sealed and cache files to redeclare

[dayou5168]

In my opinion, why do we need to migrate deals when the client needs to consider redundant backups, so why add a feature at the protocol layer

[anorth]

This is a good discussion, but we should migrate to the discussion forum. I will happily re-post my comments there.

Thanks @Fatman13 for the motivation and use cases. I think this idea generally has merit and would like to work towards things like this being possible. As @dayou5168 says, I think it would be troublesome to implement something like this without involving the deal client for approval as providers are not all equal and the client may have specifically negotiated redundancy, geographic location, certain retrieval expectations and any other kinds of out-of-band arrangements. If the provider could unilaterally offload the deal, the market for high quality of service would be compromised.

However, that's details. I think there could be a wide range of policy options that parties might want, and at the protocol level we want to move towards supporting various such arrangements rather than only one. As the FVM opens up the possibility of programmable contracts, these ideas should become options for on-chain contract implementation.

It's slightly too soon for me to post a concrete roadmap to this point, but I am actively working towards decoupling the storage market from the storage power consensus mechanism so that we can gain much more flexibility in market design and, post-FVM, make it a question of contract upgrades rather than core protocol upgrades. I'm thus reluctant to put much effort into how to realise this specific functionality within the current tightly-coupled protocol, though.