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 @David Dias and @ZX Zhang.

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.

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.

The basic flow above requires the compute provider to read the blockchain in order to sample the sealing and interactive randomness values. This allows the CP more scheduling flexibility and reduces the number of interactions necessary between SP and CP.

If maintaining a Lotus node for chain access is too burdensome for a compute provider, the could instead receive the values from the SP.

This simple flow doesn’t address aggregation of proofs.

If the CP has sufficient throughput and bandwidth to the SP, the SP can batch pre-commits at will without needing anything else from the CP.

However, batching PoRep does require the CP to aggregate the proofs of multiple replications into a single proof. How much aggregation occurs affects the cost to the SP of submitting the proofs to the chain. Thus, aggregation might require additional orchestration between parties.

[This was wrong] While the pre-commit deposit for sectors is not too large at small scales, it can be reduced to about 20% of current value with a small protocol change. This would reduce the financial cost to the SP if the CP does not produce the proof of replication on time. @Alex North wants to make this change to pre-commit deposit anyway, for other reasons.

This flow requires the SP to trust the CP to follow through with the proof of replication after the SP has pre-committed the sector. If the CP does not follow through, the SP will lose their pre-commit deposit.

This trust is needed on a per-sector basis. Thus, it can be built up over an ongoing relationship of successful exchanges. The deposit for 1 TiB of sectors is only $100 at risk (@FIL = $20).

While this proposal does not use smart contracts to enforce commitments, nothing prevents the entire thing being automated in principle. Compare to a video transcoding service provided via the web.

In practise, of course, to start with the system might be entirely manual. Success of the CP would then motivate investment in automation.

For sealing hardware currently resident in China, it is probably quite difficult to get the reliable network bandwidth outside China to transfer sealed sectors in a reliable fashion to SPs.