On the decentralization of the Cosmos Hub

Summary

This is not (yet) a concrete proposal or even set of proposals but rather simply a discussion of the “degree of decentralization” of the Cosmos Hub PoS consensus and a high-level analysis of some tradeoffs, technical and social concerns, and possible “incentive levers” which could be tweaked (in many different directions).

This analysis is mostly a brain dump and doesn’t draw any particular conclusions. Also, to be clear, these are my own views and not necessarily those of any official entities.

Part A: Gini coefficient calculation “Decentralization” is not rigorously defined. For now I will focus on just the decentralization of consensus voting power (as opposed to e.g. decentralizaiton of account balances), since that is most directly relevant to consensus safety, liveness, and governance, and since it is easy to measure and we have reason to believe we can measure it accurately (I expect most currently separate validators are not secretely operated by the same entitites). The Gini coefficient of the validator voting stake distribution seems like a reasonable first stab at a metric. It almost certainly fail to encapsulate everything one might mean by “decentralization”, but it seems to capture an important essence - a “centralized” system with all voting power in the hands of a single entity will have a Gini coefficient around one, and a “decentralized” system with exactly equal voting power (such as 1P1V democracy) will have a Gini coefficient around zero. The Cosmos Hub will necessarily fall somewhere between those two extremes - a blockchain of one validator isn’t particularly compelling, but nor would be a blockchain where all users validate, since it would be…

Excerpt (1197 of 3181 characters). Read the whole post on the forum ↗

Part B: Desiderata & Effects Incentive design for blockchains is particularly complex because blockchains are not “closed systems” - incentives in a proof-of-stake state machine affect decisions made by node operators and users in the outside world, which in turn affect properties of the blockchain state (e.g. stake distribution). I think it can be helpful to split effects into “orders”, where first-order effects are directly caused by some primary value we want to analyze (in this case the Gini coefficient), second-order effects are caused by first-order effects, etc. This cyclicality of causation has another important consequent - it may take awhile for an equilibrium to emerge (or one may never emerge). Likely a week after launch is too early to draw any high-certainty conclusions about the current incentive structure and which incentive changes would have what effects - but not too early to start analyzing possibilities . Possible effects of a high Gini coefficient First-order • A lower number of validators would need to be compromised or colluding in order for consensus to be compromised. • A lower number of validators may generate significant income (from…

Excerpt (1192 of 2277 characters). Read the whole post on the forum ↗

Part C: Incentive Levers One of the reasons I am particularly excited about proof-of-stake is that the design space is wide - there are many ways in which the incentives could be changed to attempt to encourage or discourage particular aspects of the network’s topology - and this holds true for the Cosmos Hub. I think it is helpful to split analysis into two categories: in-protocol changes, which change the Cosmos Hub state machine, how rewards are distributed, how slashing works, etc. and would require governance proposals or hard forks, and out-of-protocol changes, which include actions taken by individual actors, potential legal structures, or social norms, and can be enacted without governance proposals or hard forks (although governance proposals could still be used to poll stakeholder support). Generally these changes are not mutually exclusive. In-protocol • Sublinear rewards , where validators receive inflation and fees slightly less than linearly proportional to their stake, i.e. `rewards ~ stake ^ 0.9` (at the moment `rewards ~ stake ^ 1`). Of course, larger stakeholders could simply run multiple validators, but the real-world transaction costs (in the…

Excerpt (1191 of 2698 characters). Read the whole post on the forum ↗

Addition to C: Incentive Levers:

In-protocol:
Subliniear rewards: Incentivize splitting Validators to several accounts, thus driving out small validators. Also knowledge sharing like Certus.one did might not make sense anymore.

Another proposal:

Distribution based buff of rewards: Every Delegation from a single account yields more reward if the delegations are more evenly distributed among all validators. For example 7% default reward are boosted by up to 3% times (1 - Gini_coefficient_of_delegations). This is sybil resistant for delegations, but not for validators. So it should be complimented by correlated slashing.