Validate 'small count cohort' DKG for memory optimization

[arjunhassard]

Note that this could skip the centralized coordination version.

• Tests and benchmarks that show that the DKG and TDec works with N=8 and N=16, and t from 1 to N? including the size in bytes of A_i and Y_i vectors
  • Figure out order of magnitude for the number keys in a DKG ritual #9 (comment)
• Work out viability of proactive key refresh 'back-up' strategy to inform the value of high redundancy groups (both for m and n constraints (DKG Key Refreshing (maintain PK vs. trivial interactive new PK) from product perspective #78)
• Raise constraint of 8, 16, 32 and 64 DKG group size with adopters

[arjunhassard]

One downside of limiting the cohort size – it reduces the scope for a redunancy-driven mitigation of cohort deterioration. If
(a) proactive secret sharing / public key persistence proves impossible
and/or
(b) we find a workable compromise with long cohort persistence through long winddowns or incentivized long-term staker commitment and proactive user-driven public key replacement

then we may have prematurely limited the scope for large cohorts to provide longer, more robust redundancy and cohort deterioration resistance

Note this also brings into question the brittleness of a fixed 2/3 m-of-n ratio – even if adopters don't wish to tune it, we may want to select an m-of-n ratio more optimized for redundancy – e.g. 50% threshold (20-of-40, 50-of-100 etc)

See #78

@cygnusv

[arjunhassard]

The final checkbox – 'Raise constraint of 8, 16, 32 and 64 DKG group size with adopters' – has already been partially explored (and confirmed as viable) with adopters, and is now subsumed by the research into the practicality (from a collusion-resistance, redundancy, latency & cost perspective) and corresponding validation required to complete nucypher/taco-web#168