Optimistic snap deal cost evaluation

Creator

Alex North

Created

Mar 19, 2023 3:52 AM

Summary notes from discussion with @Undefined @Undefined @.

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 Poseidon 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 Poseidon CommR
SP proves OldReplica + NewData (with Poseidon commitment) = NewReplica
[Optional] Client computes Poseidon 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 Poseidon 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 Poseidon 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 Poseidon commitment costs, and SHA/Poseiden proof calculation+verification, e.g. in CPU/GPU-seconds.

💡

The optimistic cases both represent a global optimisation, even if the client checks every time.

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 Poseidon CommD (e.g. access to GPU), so the pessimistic case may still be relevant.

💡

Whether the global optimisation is worthwhile pursuing depends on what fraction of total deal costs are represented by the potential saving. Is C4-(2.C2+C5) >> C0+2.C1+C3?

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.

💡

What does SP have to stake, given client will check some fraction of commitments at random, in order to give a (very) negative expected value of 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.

💡

If we take the collateral for FIL+ deals to be the termination fee of the verified data, what fraction of commitments must be randomly challenged in order for the SP to overwhelmingly prefer honest behaviour to fraud?

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 🏦Self-adjusting onboarding fees with demand pricing before implementing global optimisations like this.