Filecoin network storage limit due to deal expiry

In the recent storage throughput calculator I put together, A previously un-worried-about factor popped up, deal expiry. Essentially, if we assume that there is some average length of time that deals are made for, even under a distribution with high variance, we set a 'maximum' throughput in the system.

Potential avenues of mitigation:

Increase the block size
- Only gives us scaling linear to the increase in the block size. Not a workable solution
Reduce the size of bids/deals
- A much better lever to pull than increasing block size, though getting smaller bids and deals is complicated. See this doc on bid/deal aggregation.
Increase the average deal duration
- Easier said than done, this means changing how people will want to use filecoin.

The only real way to improve the actual scaling factor here is to increase the 'average deal duration'. So let's explore some ways we might do that:

Off-chain deal extension

We can find some way for clients to extend the duration of their deals without posting anything to the chain. For 'deals' made with storage miners, this is pretty simple, as nothing about the payment or the deal duration exists on chain anyways, an extended set of payment channel updates could be sent to the storage miner, and they would just keep storing files.

However, for deals made with repair miners, this gets a bit difficult. The current model has the duration of deals logged on-chain, in the deal. To change that, we can go one of two routes, either move the duration of the deal off-chain, or be okay with some small on-chain message to update that duration.

Small on-chain deal extension

A small on-chain message to extend a deal could just be a message, jointly submitted by the client and the repair miner, containing the new duration, funds to cover the storage, and a reference to the deal ID. With proper aggregation of signatures, this is quite small (it notably doesnt contain the hash of the data in question)

Off-chain deal duration

The duration of the deal existing on-chain is how the client can know that their data will be assured (economically) by the chain. Without a duration, nobody has any way of knowing whether or not any piece of data being handled by a repair miner should stick around, or if that miner can safely remove it from their set. (Note: the bid/deal aggregation proposal linked above also requires a solution to this problem.) I don't have any concrete ideas towards this, but one approach that i hear echoing from the far off reaches of rome is "Jury Trials" (cc @nicola ). Where effectively, we broadcast information about the deal durations to the network, and elect random subsets of miners to be responsible for ensuring that deals are kept for their proper duration.

filecoin-project / specs