Paradigm Shift — Decentralized Thinking
By now, you’ve probably heard the terms “blockchain” and “decentralization” thrown around as buzzwords more times than you’d care to count. You’ve probably heard all about how “blockchain is going to change the world” and how “decentralization is the future”. If this is you and you’re still unconvinced, keep reading and I’ll try my best to change your mind. If it isn’t — great! Let me be the first to try to convince you.
The popularity of blockchain is a double-edged sword. On one hand, as the saying goes, no publicity is bad publicity. On the other, the boom in popularity has given the industry the look of a sketchy cash-grab: the next dot-com bubble, as many have been touting. Don’t get me wrong, most industries are susceptible to scams, and blockchain is certainly no exception. But just as the internet emerged as one of the most important inventions in human history despite heavy speculation and doubt surrounding its early stages, blockchain and decentralized technology should be evaluated on its technological merits and shortcomings rather than on stigma or solely as a financial investment. To truly see the magic this new world has to offer requires a paradigm shift in how we think about technical design and infrastructure.
Before we move on, let’s define centralization:
the concentration of control of an activity or organization under a single authority.
and decentralization:
the movement of departments of a large organization away from a single administrative center to other locations.
To solidify these definitions a bit, let’s see how they apply in the world of software today.
The Problem With Centralization
While the internet itself is not inherently centralized, the internet as most consumers use it today has become increasingly so compared to just 20 years ago. Technology giants such as Google, Youtube, Facebook, Amazon, and Twitter (all Alexa ranked top 10 websites) are each examples of centralized companies, whereby all data that flows through any of their services is wholly owned and controlled by them. You may be thinking, “That’s not true! They have privacy policies that say I own my data!” To which I’d say, is the data really yours if you don’t own the pipes and buckets? This is what it means to be centralized — the pipes and buckets are owned by one or few entities.
An afternoon in early 2017 showed just how effectively centralized the internet really is. Amazon Web Services went down for several hours, bringing down with it hundreds of high traffic websites and web services, including Reddit, Spotify, Netflix, and HBO, among many others. This snafu immediately brought to light how reliant much of the internet was on AWS but also more generally, the dangers of consolidated infrastructure. In some ways, centralization is a good thing, producing products and services that facilitate people’s lives. However, the consequences of growing centralization are felt more so today than ever before, with concerns over privacy, data ownership, censorship, and (unsolicited) curation becoming increasingly warranted. In general, centralization offers convenience at the cost of trust, and today, more and more companies are violating that trust.
What Can We Do?
Centralization comes in many forms beyond just the services we use. In his post The Meaning of Decentralization, Vitalik Buterin, Ethereum Founder, describes three “axes” of centralization/decentralization in software: architectural, political, and logical. These axes essentially measure the fault tolerance of a system or network as its hardware, governance, and usage are broken up into smaller, independent pieces; the smaller it can be broken up into without disrupting its functionality, the more decentralized it is. In other words, centralization/decentralization is a multi-dimensional spectrum in which any axis that is too centralized calls into question the decentralization of the entire system or network.
So why is decentralized design so difficult?
The key idea here is trust. Trust negates fault tolerance by consolidating points of failure, a lesson the common idiom, Don’t put all your eggs in one basket, expressly warns against. However, the internet evolved to run primarily using Client-Server Architecture, a prevalent request/response design pattern in which clients request resources or services from servers. This model requires clients to trust servers to behave honestly and ethically, and gives servers an inordinate amount of power; the integrity of the network is contingent on this trust, and any breach of this trust immediately undermines the entire network’s integrity. Client-Server Architecture inherently favors political and logical centralization because servers are usually governed by a single entity or business and cannot be logically separated from the clients they serve. While the cloud architecturally decentralizes the internet for the most part, the widespread political and logical centralization of servers renders the cloud at large centralized.
Consider one of the example companies above: Google. Google leverages distributed data centers and infrastructure to support its massive-scale services and platforms. In this sense, Google is architecturally decentralized — many individual Google servers can fail before Google as a whole goes down. But that’s the thing. They’re all Google servers. In order to use Google’s services, you need to trust Google. That’s political centralization.
The alternative is decentralization. One of ARA’s goals is to bring decentralized compute to mass adoption (read more about us at arablocks.io), but the road to get there is far from simple. Centralized design patterns have made us developers lazy, and coming from years of thinking in these patterns means doing mental gymnastics to rethink how things should be done where there are far fewer “free” certainties and guarantees to rely on.
For example, what is a decentralized database?
Centralized and perhaps distributed databases at a high level can be thought of as buckets of data owned and maintained by some common enterprise. From a design perspective, this common enterprise element in centralized databases enables business logic assumptions to facilitate design and implementation decisions. In other words, an element of knowledge or trust can be assumed at any level of engagement with the database. There is likely a database administrator. Or maybe the databases are all stored on computers owned by the business and where every user is known. For most developers, these assumptions have been deeply ingrained in the way they think about software.
Enter Blockchain
Designing networks and systems in a decentralized way brings to the forefront a myriad of untraditional (within the scope of most software engineers) or underused topics, mostly falling under the umbrella of cryptoeconomics. If you are at all familiar with how blockchain works, it should be obvious that cryptography is the most important reason as to why it works.
While cryptography is used everywhere on the web today (check out this awesome post by ARA Engineer Vanessa Pyne for a quick peek into the world of cryptography), end users never have to know about any of it because: 1) they can (mostly) trust the forms they fill out online, or (2) it is used to protect the servers rather than clients. Decentralization implies trustlessness, but all participants in a decentralized network must trust cryptography. Cryptography offers security in the absence of trust.
Okay. So we have security. But how does a decentralized network get anything done if no one can agree on anything? The answer is consensus. No, not just agreement, but the algorithm that defines what agreement means and how it is reached. Consensus serves two main purposes:
- It brings a network to agreement
- It prevents network attacks
If you’ve heard of mining, you might’ve also heard about consensus. Mining, or Proof-of-Work, was the first consensus algorithm implemented into a cryptocurrency. Every decentralized network needs consensus to operate effectively, and consensus needs to be expressed through software but also through governance. After all, a decentralized network cannot remain static in perpetuity; it needs maintenance, updates, fixes, and improvements, and in order to support all of that, decentralized networks need decentralized governance. This can come in the form of formalized procedures for proposals and requests as well as agreed upon standards for approval. The problem is that productive consensus requires honest input, and most economically rational actors wouldn’t provide input for free, which is why we need incentives (and disincentives).
In Proof-of-Work, miners solve math problems to secure the network in exchange for financial reward. These incentives are essential to ensuring a level of predictability and order in the network, driving activity toward some desired behavior. Conversely, disincentives help drive activity away from some undesired behavior. The game of designing protocols to incentivize and disincentivize specific behaviors is known as mechanism design, and it should go without saying that well-designed mechanisms are paramount to productive decentralized networks.
What’s Next?
Most developers probably didn’t expect to need economics at any point in their careers, but with the explosion of interest in blockchain and decentralized software, the time has never been better to get started. Our responsibility as developers is to push the boundaries of what’s technically possible, and as decentralization becomes increasingly topical, embracing a paradigm shift in how we think about building software will be the fastest way forward.
If you’re interested in following the progress we’re making with ARA, check out our code on Github and join the conversation on our Telegram.
