Snag²Deals

SnapDeals have hit a snag on Tuesday (2021-08-24) (see SnagDeals: CommD-plosion )

Today (2021-08-26) it was discovered that the snag is worst than initially considered.

SHA inclusion proofs are 75% more expensive than number quoted previously (45,331 vs 25,840 constraints per layer).

This significantly changes proving costs for "Accept SHA solutions"

We have 3.5 high level paths to proceed:

Option 0: Existing CommD + 1-message protocol, no optimisations

Proving cost of 11 and 12 partitions (32 and 64GB) or 110% of PoRep proof computation (40-60min GPU)
Increased proofs implementation time (2-4 weeks) due to need of circuit optimisations
1h-1.5h time to first deal

Proving cost of 2 partitions, 20% of PoRep proof computation (10-15min GPU)
Increased actors and lotus complexity
Miners required to place collateral for the first message, returned after successful second message.
1.5h-1.75h time to first deal due to wait for randomness (1.25h)

Option 2.5: Do both Option 1 and 2

Allowing it on actors side would not be significantly more complex than Option 2
Lotus side implementation for choosing option 1 or 2 can be done latter
Minimal complexity increase on proofs side (option 2 is one partition of option 1)

Significant complexity on deal making side and lotus, client needs to decide on whether to perform Snap or normal deal before computing CommP or PieceID
More computationally expensive CommP computation for the client but possible to reduce the impact with hybrid trees.
The CommD v2 question is related to PoRep v2 so we would need to assess requirements of PoRep v2 for CommD.
More complex circuit implementation, most likely variable mtree primitive needs to be created
Significant effort and delay
<30min time to first deal
Low proving cost <10min of GPU compute