This is a sketch of the mechanics for an off-chain sealing market. This is an arrangement whereby SP’s can outsource the computationally-intensive work of sealing a sector to compute providers that have hardware, but no on-chain presence. It does not require any Filecoin protocol changes, but requires a business agreement between the parties.

The idea came to me via @Anonymous and @ZX Zhang.

Background

Sealing a sector is a resource-intensive operation. It requires (a) significant CPU use for the pre-commit stage, (b) 14x the sector size in intermediate storage, and (c) significant GPU to compute the PoRep SNARK. Sealing is thus a capital-intensive operation. Achieving a high sealing rate requires significant up-front investment, much greater than the capital cost of subsequently maintaining that storage.

The investment required in sealing hardware is anecdotally a significant barrier to new or smaller-scale miners onboarding storage. One must have a fairly large total storage commitment in mind to justify investing in high sealing throughput.

Current storage onboarding rates (~25 PiB/day) is about half the maximum enjoyed by the network last year. Thus significant amounts of sealing infrastructure must exist that are either idle, or being used for something else. Much of it is probably in China.

Goals

• Increase network-wide CC sector onboarding rate
• Reduce capital investment and operational complexity required for new/small storage providers to grow fast
• Minimise change required to core protocols

Design ideas

In an off-chain market for sealing, a storage provider (SP) outsources the work of sealing a committed-capacity (no deals) sector to a compute provider (CP). The parties strike a business deal; blockchain contracts are not involved. The compute provider must be trusted to (incrementally) honour the deal, but is not trusted with any access or control over the storage provider’s operations.

During the process of sealing, a sector has an identity which is tied to the SP who will commit it. Thus a CP must respond to a specific sealing request by an SP.

Outline

1. SP makes request to CP to seal a sector, providing
   1. the SP’s miner actor ID
   2. the desired sector number (unique to the SP)
2. CP samples the Filecoin chain to obtain seal challenge randomness, which is an input to replication
   1. (The SP could instead provide this to CP, but it’s a time-sensitive value. Having the CP sample it allows flexibility in scheduling between multiple clients).
3. CP performs the replication step (CPU-intensive)
   1. This generates a large intermediate data that must be retained until the sector is proven
4. CP transmits the replica’s seal challenge epoch and computed CommR to the SP
   1. At any point from here onwards, the CP can also transmit the sealed sector itself to the SP. This is a large transfer which may take some time. The most conservative approach would be to transmit it in full prior to pre-commitment.
   2. The SP should verify the CommR matches the sealed sector data to ensure they will be able to compute Window PoSt in the future.
5. The SP submits sector pre-commitment to the chain
   1. The SP must stake a pre-commit deposit at this point, which will be lost if the sector is not subsequently proven.
6. The CP observes the pre-commitment on chain, and obtains the interactive randomness, which is an input to PoRep.
   1. (Again, the SP could provider this to the CP)