Thread by @SarahJamieLewis

Since many of my twitter fights devolve into people saying "but it's actually not centralized tho", let's talk about wtf decentralization actually means.

This tweetstorm has background reading.

fieldnotes.resistant.tech/defensive-dece…

Decentralization is such a misunderstood concept, because people apply it to a whole system, when really it needs to be applied to multiple layers within the system:

The Protocol, The Politics and The Practical.

fieldnotes.resistant.tech/federation-is-…

Even within those layers, the essence of centralization can be hard to untangle. Protocols can appear to be highly distributed an autonomous, but may only work in practice through a centralized trust anchor.

There are lots of great looking protocols, with dubious assumptions.

In it's simplest definition, decentralization is the degree to which an entity within the system can resist coercion and still function as part of the system.

Now be careful, coercion doesn't mean force, it means negative incentives to align with an authority.

As an example let's take my favorite decentralized protocol: Ricochet. Assuming the continued operation of the Tor network - ricochet users can continue communicating with other uses without any interference or assistance from the developers or anyone else.

If the project shut down tomorrow, or updated the software to not allow nazis or whatever, old ricochet peers would still work fine, it wouldn't fail.

Something I've discussed before:

https://twitter.com/SarahJamieLewis/status/981565218202333184

I also built on top of the ricochet protocol completely separate from the canonical spec. My code can still interoperate should I choose that. It can evolve in many ways.

Ricochet is therefore decentralized at the Protocol, the Political, and the Practical.

When we consider more complex systems, we must contend with more complex relationships between the layers.

The nature of sybil resistance in blockchains dictates how centralization emerges.

If PoW is used for sybil resistance then some emergent centralization happens around Mining operators.

If PoS is used, there is an inherent pressure toward centralization of distribution (or delegated trust points)

Many projects try to hide their centralization and couch it in terms designed to demphasize it's importance within the system. "We will move away from this implementation in the future" which you should generally read as (we don't know how yet)

And here we come the concept of Practical centralization. The idea that even if a protocol is designed with autonomy in mind, the way that it has been deployed/implemented has resulted in uneven power distribution.

See: email (gmail), ntp (google, canonical) etc.

Practical centralization is a hard concept to grasp because it isn't obvious from reading a paper or protocol spec how adoption will play out.

However, it is nevertheless something that has to be designed against.

Hard coded defaults/trust anchors, centralized upgrade severs, user preference, proprietary features, spam, ddos prevention...so many things can practically cause emergent centralized and given a handful of people uneven control over the whole system (and it's future direction)

We need to move beyond naive conceptualizations of decentralization (like the % of nodes owned by an entity), and instead, holistically, understand how trust and power are given, distributed and interact.

Decentralization is important because building systems that distribute power is important.

Too many systems distribute work load at the protocol layer, but maintain power at the political or practical layer. Those systems are not decentralized. And many can never be.

Hidden centralization is the curse of protocol design of our age. Many people have become very good at obfuscating and rationalizing away power concentration to the detriment of everyone.

Adding to this confusion is that some power concentration is inevitable and in some cases desirable...having a singe team, and a canonical implementation is the best way to produce secure software efficiently.

We should ensue those trade offs don' have unintended consequences.