Figure out order of magnitude for the number keys in a DKG ritual

[cygnusv]

where number of keys doesn't necessarily equate to number of nodes

Related issues: https://github.com/nucypher/tdec/issues/85, #77

[cygnusv]

There are two contexts here:

• Short-term MVP: The main restriction for outsourcing the coordination of DKG rituals to a public blockchain/L2 is the storage cost, since DKG transcript size per node grows quadratically with the number of shares/nodes of the ritual (which in turns implies more TX cost per node). In the short term we can work with a smallish cohort (see Validate 'small count cohort' DKG for memory optimization #77) so we can have an MVP with a smart contract coordination layer (see https://github.com/nucypher/tdec/issues/85) that's economically viable.
• Long-term solution: Here we will work towards removing the small cohort assumption. The decision here will be choosing between an iteration over the MVP solution (either assuming we can find viable optimizations to support bigger cohorts or because we just accept the small cohort restriction), and rolling our own chain (e.g. Tendermint). Metrics that will help us to take this decision:
  • Economic viability (i.e., TX cost per node participating in a DKG ritual)
  • End-user benchmarks (e.g., time needed to combine t-of-n shares, time needed to perform a DKG ritual)

[piotr-roslaniec]

Benchmarking the size of the primitives

• Benchmark results
  • A is the public key share, Y is the private key share
  • For n=8, the A size is 384 bytes, and the Y is 768 bytes
  • For n=16, the A size is 768 bytes, and the Y is 1536 bytes
• Using 1...n for threshold, where n is the number of shares, is feasible as confirmed by this test

[piotr-roslaniec]

Superseded by nucypher/taco-web#168