Parametrize & synthesize parameter (formerly 'trust') packages

[arjunhassard]

No description provided.

[arjunhassard]

From today's 7.0.0 scope-reduction exercise; trust/parameter packages can also incorporate distinct (and transparent) choices between i. semi-decentralized highly reliable long-term cohorts (NuCypher nodes + professionalized stakers + adopters own nodes) and ii. fully decentralized, permissionless cohorts sampled from the entire node population and relatively susceptible to cohort degradation (until cohort refreshing is rolled out in v7.1.0).

Noting that:

• observable evidence of independent entities (e.g. daylight between adopter and NuCypher)
  -implied trust in using an adopter's application may subsume trust burden of them running a node
• m of n can be used strategically for greater protection against service degradation 

• sampling randomness

• highly transparent prioritization, efforts & ongoing development towards in production cohort refresh
  are all relevant factors in designing the 'interim' packages

[arjunhassard]

(Purely illustrative to elicit reaction from adopters; wrt concept as whole, inherent trade-offs, swappable components, etc.)

[arjunhassard]

Proposal for the CBD MVP (v7.0.0):

1. Adopters will manually choose between two fixed sets of parameters:
   (i) Stable/Trustful
   This cohort will be composed of NuCo run nodes, plus a group of professional stakers (whitelisted by NuCo). The exact threshold is TBD, but should be chosen along with the whitelist size and composition such that no single commercial entity can unilaterally block sharing flows – i.e. len(whitelist) > m
   (ii) Permissionless/Trust-minimized
   This Cohort will be sampled from all eligible operators – i.e. those that have authorized the minimum stake to the PRE+CBD app. Note that while the Stable cohort will be the same exact n nodes, this cohort can resample a fresh cohort for each adopter.
   Outstanding q: How to minimize the trust burden associated with drawing addresses from the network for the permissionless cohort -> Design sampling for the permissionless cohort to minimize trust imposition at setup nucypher#3106

2. Adopters will pay ongoing fees (duration of cohort existence, per request basis, or both) – plus potentially an upfront* fee – to generate a cohort that they exclusively have the right to modify in the future. These modifications are also chargeable, but this can be worked out later. Updating the parameters of a cohort is not possible in early versions, but will be increasingly useful/essential as (i) modification, particularly operator replacement becomes cheaper, and (ii) adopters' business realities shift as they grow and expand their user base and feature sets. Adopters will likely choose to initialize new cohorts for new end-users, but the payloads encrypted under the v7.x.x public keys are real and may need servicing for years to come.

3. The total number of cohorts created will be artificially limited. The total and remaining slots will be clearly advertised. The limits will be different for the Stable and Permissionless packages, because it is easier for the Treasury and/or NuCo to subsidize future DKG rituals in the former.
   Note that restricting the total number of Cohorts is critical until we have a sharper picture of the long-term costs associated with operator replacement. Each cohort an operator is recruited to will pertain (possibly irreversibly) to real encrypted data out in the wild, whilst being coupled to unpredictable unbonding behavior, and the unknown costs of maintaining a persistent public key + remaining safely above the threshold to continue granting conditional access. See Economics of operators exiting cohorts (orderly unbonding)  nucypher#3072
   Outstanding q: What is the best (and most malleable) way for the network enforce a ceiling on the number of Cohorts that can be initialized under each set of parameters?

4. The exact parameters for these two packages – m, n, min. stake, min. time before cohort degradation, etc. – will remain TBD until they are validated by early adopters.

*Initializations may be subsidized by the network initially, if (a) makes integration less complex and (b) there's a robust way to limit the number of total cohorts on the network.
Future DKG rituals (initialization or otherwise) will have to figure in the fee model because they are theoretically unlimited and prompted by adopter/end-user actions.

The figure below is illustrative of how the parameter packages may look at genesis:

[arjunhassard]

For v7, we've coalesced around offering a single parameter package, a template for the cohorts generated at genesis. Because it will be permissionless – i.e. open to any staker who authorizes T token to the TACo app – cohort degradation must be considered (although a permissioned cohort could also degrade, potentially in more catastrophic ways e.g. regulatory shutdown).

In any case, it leads to the question: what is the optimum cohort size for longevity?

There are numerous factors that affect the decision to deauthorize away from TACo, most of which we cannot control for. However, starting with the assumption that the cohort size itself does not impact this decision, we can statistically compare cohort sizes (8-of-15 & 16-of-30):

• We assume that 10% of the total operator population (N = 50) will deauthorize within 6 months (this is very conservative, it will likely be much less), and all stakers are equally likely to deauthorize (this is also not exactly true as certain characteristics might indicate longer commitment, such as running a tBTC node).
• We assume that losing 13% of the cohort members counts as an 'emergency' and may warrant some expensive remedial measure. This number seems weird but is equivalent to losing 4 out of 30 or 2 out of 15 and makes the calculations easier to follow.

The probability that 4 or more of the deauthorizing operators are placed into the cohort of 30:

h(x>=4 ; 50, 30, 5) = [ (₅C₄) (₄₅C₂₆) / (₅₀C₃₀) ] + [ (₅C₅) (₄₅C₂₅) / (₅₀C₃₀) ]

= 0.32595

The probability that 2 or more of the deauthorizing operators are placed into the cohort of 15:

h(x>=2 ; 50, 15, 5) = [ (₅C₂) (₄₅C₁₃) / (₅₀C₁₅) ] + ... + [ (₅C₅) (₄₅C₁₀) / (₅₀C₁₅) ]

= 0.47609

So ceteris paribus, the chance of failure is greater when the cohort size is smaller. It is true that a larger fixed cohort size implies more overlap – i.e. the same operator who plans to deauthorize will be placed in more cohorts. However (I think) this does not increase the chance that any individual cohort will reach failure state.

It's worth mentioning that larger cohorts also offer more collusion-resistance; specifically with respect to:

• the difficulty of approaching, bribing and coordinating a collusion group in an opaque fashion
• the probability of one cohort being controlled by a single operator (this is only true when supplemented with observable, albeit non-verifiable evidence of independence)

[cygnusv]

Inspired by this, I made a similar analysis but I get different numbers:

Note that results differ because of the way I'm interpreting what configurations are considered "good" (i.e., don't trigger the emergency refreshing procedures). In your analysis, you say that for n=15, good cohorts are those with 0 or 1 bad nodes, and for n=30, it's 0, 1, 2, or 3 bad nodes.

However, I'm introducing this "risk %" column, which is just the number of bad nodes divided by the threshold, and that represents how close we are to the degradation breaking point for the cohort. Once you introduce this, it's clear we need to compare both cohort size options for similar risk %. E.g., for 12.5% risk, the probability of a "good" cohort is bigger with a small cohort than with large cohorts (52% vs 31%). Interestingly, for 25% risk, the result is the opposite: larger is better (85% vs 93%)

[jMyles]

On a call today, we resolved:

• That proper closure of this issue requires splitting it into multiple issues (as evinced by several of the comments above)
• That the parameters are sufficiently understood for 7.0.0 that this issue can be moved to >=7.1.

[derekpierre]

@arjunhassard can we close this issue?