Ruby’s Laws Of Decentralization

Ruby.Exchange
4 min readMay 17, 2023

Aka What Is “Decentralization”, And Why Does It Matter?

The idea of decentralization is critical to the blockchain space, but it’s often misunderstood, simplified, or used out of context. Counter-intuitively, an over-emphasis on decentralization can even be harmful for DeFi — though there are far more cases of centralization causing problems.

What Is Decentralization?

First of all, here’s a working definition of “decentralization”, courtesy of our favorite AI fren:

Decentralization refers to the distribution of authority, decision-making, and control across multiple entities or individuals rather than being concentrated in a central authority.

So far, so uncontroversial.

In the DeFi space, “decentralization” typically refers to the blockchain infrastructure on which dApps are built. By spreading control of a system across a large network of nodes, which work together to establish consensus, concentrations of power and single points of failure can be avoided. Cutting the head off the snake gets a lot harder when it has 1,000 heads.

The operation of the network as a whole is not reliant on any single node.

In its wider sense, though, there’s a lot more to “decentralization” than just the technical infrastructure of the blockchain, as we’ll see.

Three Laws

A little like Isaac Asimov, who gave us the Three Laws of Robotics, we came up with three Laws of Decentralization as a starting point to help explore the idea:

  1. Decentralization is a means, not the ultimate goal in itself
  2. A system or service is only as decentralized as its most centralized element
  3. Decentralization is an evolving spectrum, with a sweet spot

We’ll unpack them in turn.

1. Decentralization is a means, not the ultimate goal in itself

Decentralization is the key innovation for DeFi, underpinning a number of benefits that set it apart from TradFi:

  • Security
  • Transparency
  • Immutability
  • Openness and accessibility
  • Efficiency

Blockchain is currently the best and possibly the only technical means of achieving these characteristics, which are conspicuously absent from Web2 systems. However, it’s worth remembering that decentralization is a route to these benefits, not the ultimate aim. Decentralizing a system — or further decentralizing it — as a goal in itself risks prioritizing the wrong thing.

As an extreme example, a very high level of decentralization may limit transaction throughput, impacting a platform’s accessibility. There are trade-offs between decentralization, security, and scalability (the so-called “Blockchain trilemma”). Bitcoin has a high degree of decentralization and security, but does not support high transaction throughput. Solana is more scalable, but lacks Bitcoin’s decentralization, and so on. While numerous projects seek to solve the trilemma, there will probably always be some trade-offs.

2. A system or service is only as decentralized as its most centralized element

A chain is only as strong as its weakest link. Imagine a case in which a DeFi dApp is built on a blockchain that has a large proportion of nodes hosted by the same (centralized) provider. Both the chain and the dApp could go offline if that service goes down. That would be embarrassing

Decentralization should be maintained the further you go down the technology stack.

But there’s more to decentralization than tech. There’s the development team or teams, and the governance community, both of which can rely heavily on a few key individuals. There are also critical third-party services to consider: If the only way into the ecosystem is a centralized bridge, that’s a clear single point of failure.

All of these systems have varying levels of decentralization. Perhaps it’s therefore best to think of “decentralization” as a spectrum, or collection of spectrums — a little like a graphic equalizer.

3. Decentralization is an evolving spectrum, with a sweet spot

Following from these two points, decentralization is not a static or “one and done” thing. It’s an ongoing process: It’s generally possible to further decentralize the blockchain network, or dApp governance, or development.

However, it might not always be smart, or necessary. There comes a point where one or other domain is decentralized enough. Decentralizing it further may be costly or counter-productive, and the effort may better be spent elsewhere. For example:

  • Development of new platform features has to balance avoidance of single points of failure with speed and efficiency. Small teams of developers are usually a better option in this regard than a (highly centralized) large organization or (highly decentralized) collection of individuals. During the bootstrapping phase of a project, there is greater reliance on a core team.
  • Governance voting typically requires significant time and experience overheads. (While SKALE is gas-free, voting on other blockchain platforms also entails a financial cost, which can be considerable.) Delegate-based systems balance the burden this places on small token holders with the need to avoid centralized decision-making.

Ruby is committed to ensuring an appropriate level of decentralization for its current stage of development. We are actively working towards decentralizing governance, including functionality such as token listings, while maintaining a rapid pace of development.

Ultimately, the intention is to hand control over entirely to the community. You can read more about our ethos and approach to this process in Ruby: Our Roadmap To Full Decentralization.

Join the conversation on Discord, follow us on Twitter, and subscribe to the Ruby blog for regular updates.

--

--

Ruby.Exchange

Gasless, NFT-powered AMM/Dual DEX on the SkaleNetwork !