Summary notes from discussion with @Irene Giacomelli @Luca Nizzardo @Kuba Sztandera.
How it works
Assume a single deal equal to sector size, so CommP = CommD.
Today
- Client computes SHA CommD
- SP computes SHA CommD (to check)
- SP updates replica, giving a Poseiden CommR
- SP proves OldReplica + NewData (with SHA commitment) = NewReplica
Optimistic
- Client computes SHA CommD
- SP computes SHA CommD (to check)
- SP computes Poseiden CommD
- SP updates replica, giving a Poseiden CommR
- SP proves OldReplica + NewData (with Poseiden commitment) = NewReplica
- [Optional] Client computes Poseiden CommD (to check)
Costs
Let
- C0: cost of data preparation, transfer and all other deal and replication overheads
- C1: cost of SHA data commitment computation (by either party)
- C2: cost of Poseiden data commitment computation (by either party)
- C3: cost of updating replica
- C4: cost of proof of replica update with SHA commitments
- C5: cost of proof of replica update with Poseiden commitments
Scenario | Total cost | Simplified cost |
Today | C0 + 2.C1 + C3 + C4 | C4 |
Optimistic unchecked | C0 + 2.C1 + C2 + C3 + C5 | C2 + C5 |
Optimistic checked | C0 + 2.C1 + 2.C2 + C3 + C5 | 2.C2 + C5 |
The costs are related:
- C4 >> 2.C2 + C5
- C2 > C1
TODO: get absolute numbers for SHA and Poseiden commitment costs, and SHA/Poseiden proof calculation+verification, e.g. in CPU/GPU-seconds.
In a perfectly efficient setting, both parties should strictly prefer optimistic [checked] to the status quo. There may be practical barriers to some clients computing Poseiden CommD (e.g. access to GPU), so the pessimistic case may still be relevant.
This optimisation is likely to be most worthwhile for non-FIL+ deals, where total protocol-enforced costs may form a significant barrier to deal-making.
Rationality
In the repeated optimistic unchecked case, it will be rational for SPs to store the real data if the client checks some of the commitments, and the SP is penalised sufficiently for a detected fraud.
A client can demand certain per-deal collateral given prior knowledge of how many commitments it will check (more checks → lower collateral). This collateral does not need to be held for the life of the deal, only long enough for the client to check and challenge commitments.
Note that in case a fraud is detected by client Poseidon computation, the client must also pay (~C4) to challenge the SP to submit proof of commitment equivalence (in case the client is griefing).
Filecoin Plus
For a verified deal, the network (i.e. other SPs) are an interested party, usually moreso than the client (often paying zero). The client and SP can collude, but the network much check some commitments to ensure rationality of storing real data.
For verified deals, no client will compute the Poseiden commitment off-chain before challenging; the SP will just have to make some proofs of replication with SHA commitments. But can probably avoid this proof for most of their sectors.
Endnotes
We may want to implement