CommD/CommP currently uses tree of 2-ary SHA. To verify 2200 challenges would mean the need to verify 2200 * 30 = 66,000 SHA evaluations. This results in more than 1.7B constrains (130% of PoRep constraints).
Below is list of proposed solutions with their trade-offs.
We are looking at 1.7B constraints, which is about 20% more work than PoRep or estimated 50 minutes of GPU compute. This makes the SnapDeals process compete for resources with on-boarding storage.
There are ways (mentioned below) to reduce the number of partitions down to 6 (60% of PoRep) at the cost of additional engineering on side of proofs.
There is minimal increase to complexity caused by the need to partition the proof. We may want to investigate aggregation of these proofs.
Major drawbacks: increased proving costs for the storage provider
Positives of this solutions: no changes to CommP/D calculation, low to medium complexity on proofs side
Apex Cut of 9 to layers would reduce the number of constraints from 1.7B to 1.27B (down to 10 partitions from 13) at the cost of more engineering work on the proofs side.
We estimate additional 2-4 weeks to complete the work in proofs necessary to implement apex cut.
Currently, we are using a 128-bit security factor for Fiat-Shamir transformation, it would be acceptable to reduce it to 80 bits.
This would reduce the number of challenges to 1375 and in combination with Apex Cut could reduce the number of partitions to 6, resulting in estimated 60% cost of PoRep GPU compute or 25-30min.