Alex NorthBackground
Goals
Remove direct calls from miner actors to the distinguished market actor, so that alternative markets could be built. It's ok for the market actor to call the miner.
Note: a mechanism like miner/market registrations could allow limited miner→market calls.
There are two pieces of state to remove:
- deal IDs stored in per-sector metadata
- deal weight
There are four calls to remove:
- calculation of deal weight at PreCommit/ReplicaUpdate
- calculation of commD from deal piece CIDs at ProveCommit/ProveReplicaUpdate
- activating deals when sector is proven
- terminating deals when sector is terminated early
Design ideas
Replace quality adjusted power with an explicit FIL+ subsidy. Move the sector→deal mapping to the market actor (or off-chain entirely). Have the miner operator call the market actor directly rather than through the miner.
Deal weight
After Filecoin Plus premium there will be no concept of sector weight so the miner will not need to compute deal weight when committing sectors nor record it. These data and calls will just disappear 🎉. The market actor may retain a concept of deal weight for distributing the FIL+ subsidy.
Alternatively, if the sector weight concept remains, the miner can call the market/s that own deals and, additionally, call the FIL+ registry actor to check the authority of the markets to do FIL+ deals. Pre-commit information will need market/deal IDs.
Second alternative: market/s register the FIL+ deals with FIL+ actor when they are published. The miner calls FIL+ actor to compute weight (less trust in market contract).
Data commitment
The market actor's calculation of CommD and subsequent reconciliation with the miner's CommR constitutes a proof that (a) the deals are in the sector and (b) all other space in the sector is zero.
Today, the miner actor calls the market with a list of deal IDs to compute CommD while proving the sector. The on-chain computed value is checked to correspond with CommR by PoRep.
Instead, the miner operator could compute CommD off-chain and simply declare it when proving or updating a sector. PoRep would verify it corresponds to CommR. See deal activation below for verifying that CommD includes specific deals.
Note that this mechanism doesn't enforce that CC sectors have zero data (but see deal activation).
Deal activation and sector update
When proving a sector, the operator provides a set of deals to activate indexed by the market actor address with which to activate them. The provider submits a sector CommD (checked by the PoRep), and, for each deal, the deal ID with an inclusion proof of the piece CID in CommD.
The miner actor checks the inclusion proofs, then for each market sends a message with the sector number, sector activation/expiration, and the deal ID and piece CID, declaring a sector→deals mapping.
The market actor checks the deal ID and piece CIDs match, that the deal term fits in the sector’s lifespan, and then stores the sector→deal mapping in its own state.
The cost of verifying the piece inclusion proofs is expected to be similar to the current cost of computing the CommD on chain from the piece CIDs.
Note that it’s not generally possible to decouple the deal activation from sector proving. The correspondence between CommD and the proven CommD is checked in the proof verification and then forgotten. To decouple the timing of these, we would need to either:
- Submit a SnapDeals-like SNARK proving the correspondence
- Store CommD for each sector on chain
- Store and maintain a digest of a mapping of CommR→CommD on chain
Early termination
Today, sector metadata includes deal IDs and the miner actor informs the market actor of deals in early-terminated sectors. Without this sector metadata, we could either (a) inform the market actor of all early-terminated sectors, (b) incentivise some party to inform the market actor of early-terminated sectors that have deals, or (c) use cron.
Approach (a) is probably fine given a publish/subscription mechanism that doesn't privilege "the" storage market but also doesn't open up unbounded extra costs for termination. Something like that proposed in https://github.com/filecoin-project/FIPs/discussions/265 for fault notifications is probably good. Early terminated sectors aren't likely to be particularly common. The miner operator is incentivised to terminate early rather than let cron do it. Thus the miner operator pays gas for the termination, and informing the market about a bunch of sectors that don't have deals won't be very expensive, especially if the miner has few deals overall.
Approach (b) may require incentives. We'd need some party to index sector→deal mappings and monitor sector terminations, then inform the market actor of terminations that affect deals. A single operator on behalf of each storage market could suffice in the near term.
Upon report, the market actor would call the miner to check the sector status, and process deal termination when the miner actor failed to respond with a non-terminated sector.
Approach (c) would use cron from the market actor to periodically check the health, via the miner actor, of sectors bearing deals. Perhaps daily, mirroring the Window PoSt period. This would be relatively expensive, though.