Creator
Alex North
Created
May 23, 2023 1:31 AM
Project
Storage Programmability
Interaction diagrams illustrating current and proposed flows for onboarding data.
View this page full-width to make diagrams readable
Assumptions and simplifications:
- Basic, common interactions such as fetching/updating network statistics, checking actor authority, burning funds are omitted.
- The client already has sufficient datacap balance from a verifier.
- Sector activation is synchronous (as for aggregated proofs).
Current flow
sequenceDiagram
actor Client
actor SP as Storage Provider
participant M as Miner
participant MK as Storage Market
participant DC as DataCap
participant VR as Verified Registry
Client --) SP: Send deal proposal off-chain
Note over SP,M: SP fetches data from client
SP ->> MK: AddBalance
SP ->>+ MK: PublishStorageDeals
MK ->>+ DC: BalanceOf
DC -->>- MK: Client's balance
MK ->>+ DC: TransferFrom(Allocations)
DC ->>+ VR: Receive(Allocations)
VR -->>- DC: Allocation IDs
DC -->>- MK: Allocation IDs
MK -->>- SP: Deal IDs
Note over SP,M: SP packs and seals sector
SP ->>+ M: PreCommitSector(Deal IDs, Sector Number)
M ->> MK: VerifyDealsForActivation(Deal IDs)
M -->- SP: OK
SP ->>+ M: ProveCommitSector(Sector Number)
M ->>+ MK: ActivateDeals
MK -->>- M: Allocation IDs
M ->>+ VR: ClaimAllocations(Allocation IDs)
VR -->>- M: Verified space
M -->>- SP: Ok
Direct FIL+ flow
With data termination penalty , free CommD, and upgraded miner onboarding API similar to #298.
- No market actor is needed at all so this consumes far less gas both publishing and activating.
- Exactly the same flow can support efficient multi-sector FIL+ allocations with no extra messages (not even one per sector).
- Max duration is up to 5 years immediately.
- Minimum term enforced is limited by sector commitments, currently 1.5y (soon 3.5y).
sequenceDiagram
actor Client
actor SP as Storage Provider
participant M as Miner
participant DC as DataCap
participant VR as Verified Registry
Client ->>+ DC: Transfer(Allocations)
DC ->>+ VR: Receive(Allocations)
VR -->>- DC: Allocation IDs
DC -->>- Client: Allocation IDs
Note over SP, M: SP fetches data from client, and packs and seals sector
SP ->>+ M: PreCommitSector(Sector Number)
M -->- SP: OK
SP ->>+ M: ProveCommitSector(Sector Number, Pieces, Allocation IDs)
M ->>+ VR: ClaimAllocations(Allocation IDs)
VR -->>- M: Verified space
M -->>- SP: Ok
Custom market flow
As above, but assuming a user smart contract is enforcing some additional deal terms (e.g. a client payment). If the user market supports multi-sector deals, this flow needs no additional messages to handle them.
Differences from the current flow:
- Client publishes the deal proposal
- Market doesn’t need to check client datacap balance before allocating it (because client is empowered to ensure there’s enough).
Many variants on this flow are possible (e.g. SP publishes deal instead of client). “Market” is just one type of data application. Others might include data DAO, automated replication/repair etc.
sequenceDiagram
actor Client
actor SP as Storage Provider
participant M as Miner
participant MK as User Market
participant DC as DataCap
participant VR as Verified Registry
Client ->>+ MK: PublishStorageDeals
MK ->>+ DC: TransferFrom(Allocations)
DC ->>+ VR: Receive(Allocations)
VR -->>- DC: Allocation IDs
DC -->>- MK: Allocation IDs
MK -->>- Client: Deal IDs
Note over SP, M: SP fetches data from client, and packs and seals sector
SP ->>+ M: PreCommitSector(Sector Number)
M -->- SP: OK
SP ->>+ M: ProveCommitSector(Sector Number, Pieces, Allocation IDs)
M ->>+ MK: ActivateDeals(Pieces)
M ->>+ VR: ClaimAllocations(Allocation IDs)
VR -->>- M: Verified space
M -->>- SP: Ok