Sharing unsealed copies between SPs

[brendalee]

We have heard from some SPs that there is interest in sharing unsealed copies between SPs.

For example, there are multiple SPs that are closely situated to each other, and each of them is storing a sealed copy of dataset A. Instead of each SP sharing a separate unsealed copy of A, there could be one unsealed copy shared among the group. When any SP in this group receives a retrieval request for A (or a subset of A), they can retrieve from this shared unsealed copy.

This would reduce resources required to store unsealed copies, especially if there are SPs located in close proximity to one another. Please let us know what concerns you may have or specific items to consider for this.

[brendalee]

The simplest workflow is configuring this at the Boost level, where there is a fallback location for all retrievals.

[benjaminh83]

This is an absolutely brilliant idea! We would potentially group SPs in our primary region, and as a result heavily reducing redundant waste storage space, by allowing SPs to piggyback on a single location for retrieval on unsealed copies.

I like the approach of "fallback location", just as long as the client does not feel any difference. Like there should not be any retires or delay before reaching out to the fallback. This would be relevant, as many SPs would then only do sealed copies, and basically have 0 unsealed copies, while one SP does the full sealed/unsealed set. This could also be a mix between SPs, as long as there is unsealed copies for all the data that has this requirement.

A feature like this is VERY important for reducing wasteful HDD usage, and would come in extremely handy before launching SlingshotV3, which will have this hard requirement for unsealed copies.

[neondragon]

We frequently deploy multiple SPs that each store redundant copies of data.
Having multiple sealed copies of the data is necessary to provide fault tolerance.

We don't always have the same requirement to additionally store redundant copies of the unsealed data.
If fast or distributed access to data becomes required, that is the job of a CDN. As long as we maintain one unsealed copy, somewhere, the CDN can replicate it without significant delay. In the very infrequent event of loss of the unsealed copy, we can unseal it on a different SP in a predictable amount of time.

If we try to implement this today, then when a Boost node with no unsealed copy receives a retrieval request, it will always trigger a costly unseal of the sector on its local SP.

My concern/item to consider here is that if Boost nodes in a group proxy unsealed data to the client, it'll consume network backhaul capacity that wouldn't be necessary if, instead, there is a mechanism for the client to be redirected to perform retrieval directly from a different Boost node.

Our immediate need would be satisfied by simply having a fallback location for all retrievals. We would designate one SP to maintain all unsealed copies. Retrievals sent to other Boost nodes in the group would fall back to attempting retrieval from the designated SP, then only trigger an unseal operation if that fails.

A more fine-grained approach would be better, of course, but for ease of implementation, the simple catch-all fallback location would significantly reduce our costs in this use case, and reduce the costs of participation in SlingshotV3 for the ecosystem.

[DLTX-Github]

The idea seems great in theory, but I am concerned about the actual implementation of it.

1. One of the SPs will have to agree to be the host of the actual HW storage that will hold the unsealed copies
2. There has to be other SPs sharing the same dataset that they are all storing copies of.
3. Connectivity between the locations and use of bandwidth to transfer the data back and forth.
4. Filecoin is about decentralization, and this seems to be more of centralization

I'm starting to wonder why do we even seal the data in the first place if all we are serving is unsealed copies

[willscott]

I do agree with the concern of 4.

1-3 have emerged in some ways naturally - where groups of SPs work today with clients that want multiple replicas of their data stored.

As for your final question:

There are different types of data. Today, 'archival' data - think backups and disaster recovery - are already viable to store with filecoin. For this subset of data, the sealed copy is what provides the assurance to the client that there are multiple resilient copies of their data being stored. Even if the shared unsealed copy is lost, any of the sealed copies can be used to reconstruct the data if a disaster occurs.

There are other cases, like frequently accessed data, where a client will be more concerned about ongoing rapid access to data, and the value of the sealed replicas will be less. Increasing the stability of retrieval options is a first step in better addressing that segment of the data market.

[brendalee]

As a follow up, for the simple solution proposed by @f8-ptrk, which would start as the following MVP:

Enabling a method for booster-http, where an SP can specify a script redirect on where to retrieve the data.

• Would this solve the problem that SPs are looking to reduce resource overhead in storing unsealed copies?
• The SP would need to make sure that advertisements to IPNI reflect what they are offering (in this MVP for having unsealed copies stored elsewhere, it would only be available via http)

One note to call out here is the difficulty on SP coordination. We'd like to hear your feedback on:

• How worthwhile would this be given risks associated?
• How would coordination happen / how to SPs who want to share unsealed copies handle this?
• Are there any concerns with abuse (example: if SP storing unsealed copy deletes their data or is offline?)

[f8-ptrk]

Would this solve the problem that SPs are looking to reduce resource overhead in storing unsealed copies?

yes. but the real problem is not actually the SPs in the end but what will happen when the market flips from a buyers market to a sellers market --> sealing/pledge/space/... get rare. then wanting to store an unsealed copy will be an expensive market position without a shared way to do so on the SP side

The SP would need to make sure that advertisements to IPNI reflect what they are offering (in this MVP for having unsealed copies stored elsewhere, it would only be available via http)

same logic applies here. once a shared way is available there will be a markup on retrieval solutions that do not work with a shared copy.

to your questions:

• best invention since sliced bread!
• coordination shouldn't be boosts worry tbh.
• yes. but the market will solve that fast. you are dealing with businesses on the SPs side, abuse will not fly

[scaseye]

Honest question, can we just not have unsealed copies at all?

Can we just unseal pieces of a sector on the fly without unsealing the entire sector?

[f8-ptrk]

its on the client, ultimately the miner if unsealed copies get stored.

clients misusing the fielcoin system for fast access storage - that makes you store the unsealed copy (and the deal market situation. as soon as there are more deals than sealing capacity/pledge capacity/miners who want them - no more unsealed copy)

[brendalee]

@scaseye I am not a sealing expert, but I presume enabling unseal for specific pieces of a sector is not that easy to do (cc @magik6k @rjan90 )

[rjan90]

With the current Proof-of-Replication there is unfortunately no "selective unsealing" - in the sense that you only unseal XX part of the sector.

In the current PoRep-scheme you still have to do the work of unsealing the whole sector even if you just want a small piece of the data contained in the sector.

[scaseye]

Changing those both would be beneficial

[scaseye]

seems like SAAS would serve this use case as well. Unseal the sector, and put it somewhere to be retrieved. paid for by the client. SPs only need to send the sealed sector to saas, then they are out of the loop.