Validate desired granularity of DKG rituals (per label, per end-user client, per adopting application, etc.)

[arjunhassard]

See https://github.com/nucypher/tdec/issues/13 for full discussion

• What is your ideal DKG ceremony frequency/granularity?
  • We just want to set our own cohort!
  • One DKG for simplicity is fine
  • More granularity later for higher value assets
    • e.g. NFT-gated film franchise would be more risky
  • Starting with low risk, if something goes wrong it’s fine

[arjunhassard]

If we assume that DKG Cohorts == Decryption Cohorts as an over-arching constraint, then the most economical option – is for each application is to reuse the same Cohort for everything; for DKG, for condition-checking; and to manage all decryption fragments/ciphertexts generated for/by end-users. I.e. a public key generation from-scratch happens just once (unless some edge case occurs) .

*Assuming a fee model that incorporates that uses the initiation of a DKG ritual as an input unit.

**I'm using 'application' here as a shorthand for a repeated sharing flow pattern that has some unchanging set of trust requirements. Actual applications with very wide feature sets may contain within their usage space some sharing patterns that have different trust requirements but this is unlikely for early adopters.

So it seems the answer to ‘what is the optimum granularity of DKG rituals’ shouldn’t be rigidly be ‘per label’ or ‘per end-user’, rather ‘per sharing pattern with a specific set of required trust assumptions’.

The problem is that in practice – say for a 9-of-16 Cohort – a malicious actor would only need to bribe 8 other entities to get access to the private data generated by the entire sharing pattern. And they would have ages to do it. The mitigations are: (a) Increase n and/or m – expensive (b) Refresh the cohort somewhat frequently – not free but probably more efficient than (a)

From what we've heard from adopters so far, they won't want a bunch of different DKG/Decryption Cohort formation parameters within their single application. Instead, they’ll likely choose one (or two) trust packages, and those trust packages will have to each include some kind minimum Cohort refresh cadence – and that will be complex enough, and safe enough.

In other words, DKG rituals (and all the other trust parameters) are not tied to an architectural object like a label/directory/device, but rather are tied to the domain expertise of an adopter with respect to various forms of risk, and how those map onto the primary sharing patterns within their app. In some senses, this is a big shift from the PRE model.