Decentralization

[arjunhassard]

Following @cygnusv's initial look at testnet decentralization.

Some risks of overcentralization that impact NuCypher service quality & network health:

• Collusion Stakers might collude to compromise data privacy, to deny revocation, to game payout mechanisms, or to facilitate other (unknown) attacks.
• Censorship Blocking access to data by refusing to re-encrypt. This is hard to orchestrate – see nucypher/nucypher#803
• High threshold service discontinuation For whatever reason, if a dominant staker or staker cartel decides to spin up the minimum number of workers (1), then users (and indeed, mechanisms) relying on a large n may suffer.
• Weakening of economic mechanisms (i.e. stake-based sybil resistance)

Across which planes should we measure and monitor the gini coefficient / lorenz curve? At least these four: 1) Primary ownership of tokens Fairly obvious, since reward allocation and job assignment are stake-weighted 2) Control of delegated tokens Depending on governance rules, this could equate to the the political power @michwill mentioned 3) Total number of workers More of a functional issue (i.e. are there enough workers to satisfy the threshold choices of users) – doesn't have much impact on censorship or power consolidation risks 4) Client diversity Including dependency on underlying clients (i.e. Geth dominance)

The risks of overcentralization are also affected by:

• the reliability/security of the randomness with which stakers are selected for policies (initially and if user requests a worker re-shuffle)
• 'permanence of employment' - how long stakers are tied into (relatively) lucrative policies, during which they cannot be displaced
• liquidity and price of token: how feasible is it for a staker to join later and reduce a trend towards consolidation
• typical thresholds chosen by users

[jMyles]

@arjunhassard, I totally appreciate this memorandum - it needs to go somewhere. But as a github issue, I'm inclined to close it wontfix on account of not having a clear fix condition.

Perhaps this material is better suited for the forum?

[michwill]

I think, the biggest gotcha we've seen is that if someone is restaking, he/she can potentially get above maximum number of coins per staker and continue (I've got 20M out of 40M). Should we somehow make it possible to split one large node into two/three/...? Or are we ok if we start from initially diverse node distribution?

One of the answers to this question could be also given by Livepeer: they had fairly high inflation for a while, and they also had restaking on for everyone by default. Here's the result: https://staken.io/assets/docs/Asset%20Research%20Report%20-%20Livepeer%20(25.06.2019).pdf

[arjunhassard]

@jMyles that's fair. I think we agree that as we increasingly come under the scrutiny of the wider world, we must amass all material related to our protocol and economic system in a single location. It's practically impossible for someone outside NuCypher to follow the development of a solution, when this development is fragmented across PRs, public (& private!) discord channels, in-person discussions, whitepapers, forum posts, gists, elsewhere. This fragmentation also adds a substantial internal headwind for anyone seeking retrospective clarification on a component's workings that they weren't initially involved in designing.

My preference is to rename nucypher/mint-paper as nucypher/protocol, make it public and then capture all pre-implementation protocol debate there. Livepeer the standard-bearer once again: https://github.com/livepeer/research/issues is easy to follow. We can easily move issues like this one, nucypher/nucypher#1275, nucypher/nucypher#1302, nucypher/nucypher#803 and others over there.

While these discussions should of course be public (at the moment they're effectively private by virtue of fragmentation), my sense is that forum isn't the right starting point. The raison d'être of a forum is to encourage external participation, and I fear the esoteric and unpolished nature of a discussion today about, say, probabilistic micropayments, isn't particularly inviting. However, once refined and developed, the proposal can be reposted in the forum in a simplified/generalised manner that explicitly solicits external feedback, and doesn't require a deep understanding of NC character dynamics, business realities of AC services, the uptime monitoring problem, etc.

Wdyt?