Problem

The FIL+ allocation strategy is slow, costly and does not scale onchain.

Let’s think as the datacap as a non-transferable token for simplicity. Currently, on a high level the FIL+ allocation looks like the following:

• Notary “mints” tokens to the client
• Client “burns” tokens to create an allocation (on-chain)
• The SP claims the allocation (which in turns, creates a “claim”) - on-chain

Each allocation is for only one sector at a time.

Note that all of these operations can be done in batch, but there is still per-sector overhead for each allocation and claim.

Goal

We want to change the process so that clients can create a single allocation for data that will span multiple sectors.

The primary goal is to reduce the workload/cost on the client (the second step mentioned in the above section). This proposal also enables to reduce the workload/cost on the SP as well by claiming multiple allocations at once but it is not required.

Proposal

We propose the client use a commitment to represent a set of Piece CIDs (CommPs) that the client wishes to put on Filecoin.

The client can then do a single allocation for this set of CommPs.

The SP can claim set of commPs either incrementally (one by one) or by batches.

A proposed workflow for the allocation is as follow:

1. The client computes all the CommPs they wish to store
2. The client computes a commitment to these CommPs, let’s call it C