Decentralization as an attribute of blockchain technology gets a lot of press, but it’s actually relatively hard to pin down what it actually is and why is it useful. I’ve done a lot of thinking about the topic and work on implementing it, so I have a few things to say here. This blog post is meant to introduce technical decentralization from a high level. I intend to expand upon the topic in future posts, but this is the starting point.

What is Technical Decentralization?

Decentralization is relatively easy to define. In the sense that we’re talking about it, a decentralized system is one that is run on multiple, distinct networks with multiple, distinct owners. This sounds pretty simple, but it’s actually a big break from the way that infrastructure is traditionally run. Decentralized systems have gotten a lot of press with blockchains, but there are other examples as well, like bittorrent.

Let me explain. When you’re running infrastructure for something like a website, centralization is really a pretty good thing. As a business owner, you want your site to stay up the vast majority of the time. One really good way of doing this is to run it on a cloud provider. Cloud providers tend to stay up most of the time and are much easier to deal with than running your own IT. We’ve all heard about the shift to the cloud. It’s great for traditional business applications.

Okay, so you’ve got your service running on a cloud provider. However, your service is completely centralized at this point. That’s perfectly fine for a website, but not for a lot of blockchains. In order to be decentralized, we’re going to need to run on multiple networks with multiple owners.

Multiple Networks

It’s relatively straightforward to say that a decentralized system needs to be run on multiple networks. However, we need a concept of what actually constitutes a network here. People often say that particular organizations run their own network. What this actually means is that the organization has their own Autonomous Systems Number.

What is an ASN in Networking?

An ASN, or Autonomous System Number, is a unique identifier assigned to a group of IP networks managed by one or more network operators that present a common routing policy to the internet. Think of it as the address for a collection of routers and networks that belong to a single entity, such as an ISP (Internet Service Provider), organization like a company or DAO, or university.

Key Points:

Uniqueness:

Every ASN must be unique across the internet to ensure proper routing. The Internet Assigned Numbers Authority (IANA) manages the global pool of ASNs and allocates them to various regional internet registries (RIRs).

Routing:

ASNs are crucial for Border Gateway Protocol (BGP), the protocol used to exchange routing information between different networks on the internet. BGP uses ASNs to determine the best paths for data to travel across the web.

The takeaway here is that in order to be fully decentralized, a system needs to be run on at least two ASNs. This could be AWS and Google Cloud. It could also be two separate networks run in data centers by a blockchain project, for example, one run by a project’s DAO and the other run by the project’s labs organization. It could also be some combination of the above. That’s really the conceptual bulk of the multiple networks piece of the equation from a high level, but there are a lot of details left up to the implementer.

TLDR; If you want to be decentralized, you’re going to have to run at least one instance of your blockchain software on at least two different ASNs. These are the basic building blocks that organizations use to make up the internet. You may be thinking, “Wait, does this mean the internet is already decentralized?” Yes, it basically already is.

Multiple Owners

You would think that the multiple owners piece of decentralization would be relatively straightforward in that multiple networks would be owned by multiple people. However, this isn’t necessarily true, and there are some complexities involved. There are actually two traps that people tend to fall into here.

The first is thinking that the best solution is to load balance between two cloud providers. While this is definitely not a bad option, this can get very expensive, and this is especially true if you are using things like HSMs that cloud providers tend to charge a lot for. If your organization is entirely cloud based, this can be an option to consider though. If you go this route, I’d recommend looking at third party KMS solutions.

The second trap that people fall into when thinking about decentralization is going all in on data center infrastructure. Yes, this will give you complete control and potentially better security if done right. It really is the epitome of decentralization. However, this approach comes with all of the slowness of traditional IT. In order to completely decentralize this way, it also means building and running two separate networks which can be more cumbersome. This is definitely the way that it should be done, it’s honestly just really impractical for most projects.

I think that people initially assume that the process of decentralization looks like node runner adoption. With this model, a labs organization would develop and release software. Node runners deploy the code which allows for services to be consumed by users. This can be true for some projects, but it doesn’t necessarily have to go that way. Other models that I’ve seen employed to great success include what I would call gradual decentralization which involves creating a reliable, centralized network and gradually onboarding node runners.

TLDR; Decentralization is always going to involve multiple owners. This is hard, but it can be made easier if done in a thoughtful way.

Wrapping Up

There’s only a few things that are needed for technical decentralization on a high level. However, this paradigm shift is a big change from the way that things tend to be done in most organization. While engineers and operations staff likely won’t need much in the way of technical training to meet the needs of a Web3 organization, there’s a lot that needs to be understood conceptually.