This note sketches out a refactor of the interfaces and calls between the miner, market and FIL+ registry actors in order to support alternative storage markets.
This draft is replaced by Architecture for programmable storage markets â v2
- Goals
- Questions to check if this is a good architecture
- Design notes
- Notable changes
- Interfaces
- Miner actor
- Market actor
- FIL+ registry (without FIL+ premium)
- Workflows
- End-to-end verified deal
- Sector content update (Snap Deal)
- Sector termination
- Sector extension (optional)
- Deal extension into new sector (optional, new!)
- Deal extension with existing sector (optional)
Goals
- Break any dependency of the miner actor on the market
- Break coupling between the market and FIL+ actors
- Donât trust the market actor for anything except maintaining its own internal deal state
- Thus allow an alternative storage market to compete with the built-in one, including for FIL+ deals
- Retain the current economic structure, incentives, pledge etc
- Be compatible with future change to
Supporting alternative markets also requires Miner market registrations for market fault processing. See also Market/deal contract interfaces notes for other programmability enhancements.
Questions to check if this is a good architecture
- Could this work with an L2 market? How?
- Could we even further remove knowledge of deals from the miner actor, so they donât even pass through?
- Would like to notify market of sector content async, after PoRep.
- Challenge is associating piece CIDs with CommD when the CommD is proven to be correct, i.e. only at PoRep time
- Could we get features of deal extension after this re-architecture, even while FIL+ remains? (Maybe with FIL+ Forever)
- Deals decoupled from FIL+, so non-verified deals are easy
- Need extension of data cap
- Could we add feature of upgrading a deal to FIL+ after it starts?
- 2/3 of the way there, need a new method on miner to claim data cap after PoRep
- And the challenge of proving piece inclusion in CommR again :-(
Design notes
- We trust the miner actor as network code, so sensitive operations are moved into it.
- Assumes QAP mechanism remains, so the FIL+ actor must be known and trusted by miner
- Want to be on a path where FIL+ premium could be added later, with accounting in the FIL+ registry actor.
- CommD <-> CommR correspondence is only give at PoRep/Snap time. Itâs hard generally to prove the correspondence later.
- Thereâs no enforcement that sector content must be zero outside deals.
Notable changes
- FIL+ is actor informed about specific deal terms prior to deal
- This can be extended into the FIL+ registry dishing out the FIL+ premium in the future
- Miner actor invokes FIL+ to commit data cap, and gets the deal weight inputs for QAP in return
- Previously invoked the market for this
- Market no longer knows FIL+ or data cap at all
- SP provides deal metadata at PoRep instead of fetching it from market at PreCommit
- Miner computes CommD instead of calling market
- Miner only invokes market once (today: thrice)
Interfaces
Miner actor
State
- PreCommit state
- SectorID, CommR, expiration etc
- Sector state
- Sector ID, CommR, expiration, pledge etc
Methods
- PreCommitSector(SectorID, CommR, precommit stuff)
- ProveCommitSector(SectorID, proof, CommD, []Pieces) Piece is (PieceCID, size, marketAddr?, dealID?, FIL+ ID?)
- ProveReplicaUpdate(sectorID, proof, CommR, CommD, []Pieces)
Market actor
State
- Deal proposals
- Activated deal states
- Mapping (Provider, Sector)â[deal ID]
Methods
- PublishStorageDeal(...) â ID Or equivalent. Market-specific, does not need to be standardised.
- SectorContentAdded(provider, sectorID, [(deal ID, pieceCID, size)]) Invoked by provider whenever sector content is added, passing through the list of deal/piece IDs specified by them. The miner actor verifies the piece data. With QAP/write-once storage, pieces are all new. Alternative semantics will be needed for update-able storage.
- TODO: add ExtendDeal (or more generic renegotiation), plus tracking of deal sector expirations for automatic termination if not re-sealed
The on-chain DealProposal
loses its VerifiedDeal
field: the market is no longer trusted to determine verified status.
The off-chain StorageAsk
struct gains two optional fields:
-
FilecoinPlusApprovalID
: id of a previous data cap approval by the client FilecoinPlusApprovalCertificate
: a signed tuple of (pieceCID, size, start, end). The SP can submit this directly to the FIL+ actorâsClaimAllocation
when proving a sector.
FIL+ registry (without FIL+ premium)
State
- Data cap total/used per client
- Data cap approvals list by client
Methods
- AllocateDataCap(client, provider, piece CID, size, term, label) â AllocID Called by client. Allocates clientâs data cap for specific terms, prior to any deal. Consider allowing provider to be empty, so valid for any provider.
- An alternative flow is for SP to provide a signed message from client during ClaimAllocation, saving client messages but costing a signature verification.
- RevokeExpiredAllocations(client) Called by client. Removes inactive allocations with start epochs in the past, restoring the data cap for re-use. Removes allocations with end epochs in the past.
- ClaimAllocation(provider, sector ID, claims [(AllocID, piece CID, size)], [pre-signed certificates]) â [allocations] Called by SP. Marks allocation as active & irrevocable if ID/piece/size match. Sector ID is for future tracking of sector faults etc. Returns the approvals activated.
Workflows
End-to-end verified deal
- A client submits approval for specific deal terms to consume data cap to the FIL+ registry. This reserves a part the clientâs data cap immediately. The registry allocates an ID for the registration and stores the terms under the registration ID for later reference.
- Alternatively, an EOA client can sign a message approving the data cap for the specific deal terms, which can be submitted to the FIL+ actor by the SP when the deal is committed.
- We need the client to commit to the data cap in order to induce the provider to take the deal.
- A market matches a deal client and provider with terms. The mechanism for this can vary between markets (e.g. on chain vs off-chain). The market and SP must know the deal client, size, term, and piece CID. The client and provider are both committed to the deal.
- This is
PublishStorageDeals
today. - The SP pre-commits a sector, committing to CommR. The SP may have sealed deals into the sector, but they are not supplied on chain yet.
- The pre-commit deposit is changed from being equal to Initial Pledge, to being only the Storage Pledge part of IP for a fully-verified sector (i.e. 200 * BR). This is much less. No longer requires deal information at pre-commit.
- SP also provides a list of (piece CID, size, market addr, deal ID, AllocID) tuples for pieces sealed into sector. Pieces must exactly fill the sector (with an optional trailing zero piece consuming remaining space). A sector may have deals from multiple markets. A piece may have no deal or FIL+ data. Miner actor computes CommD from the piece CIDs The SP proves the sector, proving the CommD corresponds to CommR committed earlier. The miner actor claims each (AllocID, piece CID, size) as committed to the the FIL+ actor. The FIL+ actor checks these against client approvals, and returns the data capâs space-time. The miner actor can then calculate quality-adjusted power given the sectorâs expiration date. For each piece, the miner actor notifies the relevant market actor that the (deal ID, piece CID) has activated, and in which sector. The market checks the piece CID matches the deal, and records the sectorâdeal mapping.
- No deal information is preserved in miner sector state.
- Opportunity to allow deal lifespan to exceed sector lifespan, truncate QAP to the sector commitment.
If a sector is not proven after pre-commit
- After the approval start epoch has passed, so it canât be sealed into a new sector, client can revoke the FIL+ registration by garbage collecting. The market cleans up the deal in cron.
Old call sequence
- SP â Market.PublishStorageDeals
- SP â Miner.PreCommitSector[Batch]
- Miner â Market.VerifyDealsForActivation
- SP â Miner.ProveCommitSector[Aggregate]
- Miner â Market.ComputeDataCommitment
- Miner â Market.ActivateDeals
New call sequence
- Client â VerifReg.AllocateDataCap
- Contract clients need this, EOA clients can instead provide certificate along with storage ask
- SP â Market.PublishStorageDeals
- SP â Miner.PreCommitSector[Batch]
- SP â Miner.ProveCommitSector[Aggregate]
- Miner â VerifReg.ClaimAllocation
- Miner â Market.SectorContentAdded (aka ActivateDeals)
Sector content update (Snap Deal)
- SP commits and proves a zero sector (no calls to market or FIL+).
- Client approves data cap, and provider/client publish a deal.
- SP invokes ProveReplicaUpdate, proving a new CommR. Includes a list of pieces that exactly fill the sector, with associated market deal ID and FIL+ ID. Miner computes CommD from pieces. As for the usual flow, for each piece the miner claims a FIL+ approval to calculate space-time, and notifies market that the piece has activated, and in which sector.
While the QAP mechanism exists, miner must enforce that only pieces previously zero can be updated.
Sector termination
Every miner is registered to notify the market actor of any early sector termination, via Miner market registrations for market fault processing. The miner no-longer knows which sectors have deals.
- Miner notifies market/s of sector termination, with sector IDs (and originally scheduled expiration epochs?)
- Market looks up its sectorâdeals mapping and marks any such deal IDs as terminated, but defers expensive processing for later.
- This avoids sector termination being too expensive to process
- During normal cron processing of active deals, market checks the terminated deal list, and processes any terminations.
Sector extension (optional)
We could allow deals to be committed into sectors that are currently set to expire too early, if we can extend them later.
- The market allows deals to be activated in sectors that have earlier expirations. The market records each dealâs sector number in state, and the expiration epoch of each relevant sector. If the sector is not extended in time, the deal is terminated during normal deal cron processing.
- SP invokes
miner.ExtendSectorExpiration
with a sector number and new expiration. - Miner actor calls a new
market.SectorExpirationChanged
method with each registered market actor. The market actor updates the local sector expiration epoch cache.
Deal extension into new sector (optional, new!)
We could allow deals to be committed into sectors that are currently set to expire too early, if they can be moved into a new sector.
- The end-to-end deal flow happens, with a deal with a loooong expiration
- Or deal term is updated later
- Later, the miner proves the same deal in a new sector, providing the same (pieceCID, size, market, dealId, FIL+ ID) to PoRep, plus the existing sector ID. The miner actor claims the same (FIL+ ID, piece CID, size) from the FIL+ actor. If the approval term has not expired, the claim is allowed and FIL+ returns the sector ID that already hosts the piece, which the miner checks. The miner actor is trusted not the activate the QA power twice concurrently. Instead, the new sectorâs QAP is calculated as if the deal only activated the epoch after the existing sector expires. The old sector maintains its power until it expires. The miner actor notifies the market actor that the same (deal ID, piece CID) has been committed in a new sector. The market forgets about the original sector and updates the sectorâdeals mapping to the new sector.
Deal extension with existing sector (optional)
~Kubuxu
@alex
We could allow deals to be extended if sector lifetime allows for it.
QA power in its current form is a blocker as QA power of a sector is write once mechanism.
- Possible notion: FIL+ Forever the time component of QA power is essentially skipped
- Possible option: No QA power from extension â BAD
- Possible option: FIL+ premium
Scheme:
- The market recieves a message about a deal extension co-signed by both parties (either message + deal signature or dual message).
- Market calls into the miner checking the sector lifetime is sufficient for the extension (this step can be skipped if we implement âSector extensionâ.
- Depending on FIL+ mechanism:
- FIL+ Forever - the state of the sector does not change
- No QA power from extension - the Quality of a sector is not adjusted so in essence miner does not gain QA power from the sector (the QA power of a sector was possibly earlier reduced due to sector extension).
- Change to FIL+ premium is sent
- The deal can be either updated in place or new deal can be created.
TODO:
- Deal extension within the same sector already storing it