We propose here a variant of the current SnapDeal protocol, based on Poseidon Hash function rather than on SHA256.

Current SnapDeal protocol is based on SHA256 to ease client's CommD computation, given SHA is very efficient to compute, even without having access to GPU.

This efficiency on the client side comes with a cost: proving SHA256 is not efficient inside a Snark and this proving inefficiency results into a SnapDeal overall cost being comparable with the cost of sealing a new sector in the network.

This aspect (along with user experience issues related to software unreliability reported by different SPs) represent a clear downside and drastically reduce the appeal of SnapDeal as the solution for injecting datas into sectors.

We propose to keep the SnapDeal protocol as it is now, but changing the hash function used. Specifically, we would use Poseidon hash instead of SHA256.

Poseidon is an algebraic hash function, and in particular it can be efficiently proven inside a Snark. Compared with Sha, we have a 54x improvement in proving overhead (see

On the other hand, computing poseidon is more expensive than computing Sha. This represent a downside when the Client has to compute a poseidon based CommD (and the SP should also compute it, eventually to check it). From initial benchmarks, we estimate a Poseidon CommD to be ~100x more expensive to compute than a SHA based one on CPU.

Nevertheless, we are confident that the massive gain in proving should counterbalance the computing overhead.

The most controversial part of this proposal is of course the additional overhead required to the Client in order to allow for massive improvement at proving time for the SP.

One can wonder why a Client should decide to pick a more expensive path with apparently no gain on his side.

Here is where our thesis comes into play: we are convinced that, if the overall cost of the deal process is way lower than the current one, then it is in the interest of SP that the Poseidon based SnapDeal protocol is chosen by the Client. Moreover, in order to do so, if gains are remarkable, SP could potentially being subsidizing the Poseidon based CommD computation costs for the client, and still be gaining due to the 54x cost reduction in the proving step (either by providing access to their GPU or giving a discount to Clients, or paying them for choosing SnapDeal v2).

Of course this thesis needs to be confirmed, but we see an opportunity here for improving the entire deal process.

We present here the differences of the current SnapDeal protocol and the Poseidon based one, focusing on their costs.

Note that the SnapDeal protocol flow would not change (details can be found in

SnapDeals Project

In what follows, we assume CommP = CommD (i.e. a single deal equal to sector size)

Let

We know that

We also expect that

Nevertheless, in order to estimate the overall costs of the deal process, we need estimate the relation between MT computation and proving, in order to be able to estimate the overall gain of the entire process (basically: how cheaper is 2*Cost2 + Cost5 compared with 2*Cost1 + Cost4?)

Back on the envelope cost comparison estimation

Given all the above, we give present a rough cost estimation of the two strategies in order to have a dollar to dollar comparison

Costs of PC2 and C2 taken from here (status quo, before SN optimizations)

⇒ Overall cost of SnapDeal protocol using sha = Snark with Sha + 2*MT with sha = Snark with Sha + 2*MT with Poseidon/59 =0.1006 + 2*(0.1006/2)/59 = 0.102305

⇒ Overall cost with Poseidon = Snark with Poseidon + 2*MT with Poseidon = 0.1006/54 + 2*0.1006/2 = 0.10246296296

Conclusion: Overall costs with Poseidon are not better than with Sha (assuming GPU at least)

TODOs