Alex NorthQA power pays rewards for storing verified deals, but by attaching them to sector lifespan and consensus power.
The most flexible storage API for providers would be to treat their storage as a big homogenous blob into which they can write data and move to satisfy deals according to those deals’ terms. But QAP opposes that high utility.
The is one proposal that resolves the below. There might be other ways too, but these are some of the challenges and/or limitations we must overcome or accept.
Friction transferring deal data between sectors
Sectors have a fixed lifespan for security reasons. We would like deals to be able to be longer than sector lifespans, either/both through declaring a long deal duration up front, or extending it during operation. Deal extension should not (a) require the client to provide the data again, nor (b) consume DataCap already used for the deal. So “do another deal” doesn’t cut it.
This could be easily enabled if the provider could transfer deal data from one sector to another (with a later expiration). The QAP calculation for the new sector is reasonable, but we can’t generally recalculate QAP for the sector we are removing the data from. Unless the deal lifespan matches the sector lifespan exactly, the provider will generally have already earned rewards for part of the deal hosting not yet provided. Consider a deal that starts halfway through a sector’s life. By 50% epoch, the provider has earned half the reward, even though the deal hasn’t started. By the 90th% epoch, the provider will have earned 90% of reward but only provided 80% of the service. We can’t just recalculate sector power down to 1x at this point without overpaying.
As a work around, we might restrict deal transfer to happen only on the epoch at which the original sector expires, but this demonstrates the inflexibility. Miners can’t reorganise their storage for better operations or performance.
Friction transferring data between providers
This friction is amplified if we want to transfer deals between miners (with client approval). The overpayment would restrict transfer to the pre-declared expiration date of the source sector, which may be months or years away.
One motivation for transfer between providers is that the source provider knows they will not fulfil the deal. Rather than drop it cold, it’s a better outcome for both the client and the provider to negotiate a transfer. Restricting this transfer to sector expiration probably excludes all of this class of useful cases.
Friction replacing sector data
We can’t remove expired deal data from sectors either. Consider a sector with a deal that occupies its full space, but for only the first half of its life. Assuming the technical ability to prove it, we might expect that after the deal has completed, the provider could replace the data in the sector with a new deal, also for the full capacity and the second half of the sectors life.
But the provider has only earned half the reward for the first deal, even though they have fully satisfied the deal term. If we recalculate QAP in the usual fashion for the remainder of the sector lifespan, the provider will lose out on half the rewards. So the miner will be forced to sit on “useless” data while earning out rewards for service already provided.
Or perhaps we could carry the un-rewarded space-time into the second half of the sector’s life. But this would result in a sector power of 15x in order to earn the correct rewards, which is weird and possibly exploitable.
Limitation to capacity deals
Similar problems to the above. If a does a “capacity deal”, allowing the client to update data later, we’ll probably be limited to “write-once” semantics. If a client writes some FIL+ data, we can calculate QAP on the assumption the data will persist for the remainder of the sector’s life. But if the client were to replace that data later, especially with non-verified data, we may not generally be able to compute a QAP value equivalent to if we had known the deal duration up front (if we had, could just do a regular deal).
Delays rewards for hosting verified deals
Given a fixed deal duration, QAP spreads out the reward for the deal over the lifespan of the sector the deal is stored in. If the sector lives longer than the deal, this delays rewards. So the provider is incentivised to select the smallest possible sector commitment up front, while we would generally prefer long commitments. The provider may enjoy more profit from letting the sector expire and sealing a new one, thus consuming sealing throughput that could otherwise be used to add net-new capacity.
This disincentive remains, though reduced, to extend the sector lifespan: that portion of rewards not already paid will be delayed even further if the sector is extended, say to accomodate a new deal.