Preamble

I am writing this for developers, engineers and architects. This series is about facing a poorly structured problem and bringing order to it and then finding a right tool for each task within it. I personally like new tools – they help me solve new problems. Once they brought me this new tool called “blockchain”. At that point, I did not know what to do with it. Now I think I do. Some of it...

Intro

In this series, I would like to look at decentralization and blockchain and identify the correct tasks for them. Just like RDBMS or chatbots or PWA they can and IMHO should be viewed as tools (for architects and/or developers). Every newish tool that appears on the market typically comes with a lot of hype (and inevitable hype-backlash). In last two decades, I have succeeded and several times failed in getting to the practical side for Neural Networks, SaaS, Chatbots, ESB, Augmented Reality, NoSQL, etc. Most software developers can probably name their own lists. So I wanted to try to present my own practical thoughts on the subject of blockchain.

Decentralization

But before we talk about blockchain we need to have a couple of words about decentralization. We all heard of it, we kinda know what it is. To borrow from Wikipedia

Decentralization is the process by which the activities of an organization, particularly those regarding planning and decision-making, are distributed or delegated away from a central, authoritative location or group

However when building a system especially one with a myriad different concerns, an ecosystem of tools and users with different roles I found that I need to better understand it.

So when we are building a software product where does Decentralization come in?

Philosophy

Presented with a chaos of real world we typically want to create a model that organizes this chaos. And then on top of this organization we build systems that deliver real value. While complexity of this process is immense, classically we USE centralization as one of the tools to do that. Centralized systems (not to be confused with monolithic ones) are tidy, efficient, and well-understood solutions to most real world tasks. We know how to design them. We know to implement them.

But how much centralization do we have and when does it hurt us?

Let’s look at our systems in terms of

1. Logic (as in code)
2. Storage (DBs, files, etc)
3. Infrastructure
4. Ownership

Logic

After some (over)simplification we can, for now, say that: all logic in our system can be divided into Client-side logic and Server-side logic.

Client-side logic. Everything that executes in your browser, mobile phone, desktop client falls under this category. For many applications border between client and server has blurred significantly over last two decades, yet for most it can still be well demarcated. Client-side logic is run by millions of different users on their devices.
How is it centralized? In most practical ways it is not.
Interestingly many blockchain-based applications will force you to do bring more logic to client-side. I plan to discuss problems of “overgrown” client-side in blockchain applications in particular in future articles.

Server-side logic. For simplification let’s call all the logic that does not run on the client – server-side logic. Your REST and GraphQL services, your serverless logic, our analytics, and even operations centers all fall under this category. A question for you: do we put database trigger into this category?
Nowadays we can generally say that server-side logic runs in a cloud. Or at least it can. We can have a very high level of redundancy for it. I would say that on an «infrastructural level» it is decentralized. Google can shut down one of its datacenters tomorrow and you won’t even notice. As far as our code goes we do SOA, micro-services, functions on top of FaaS. We have been embracing decentralization in the names of reliability, scalability, productivity, manageability for decades already. More often than not, tools mentioned are more than enough to facilitate the necessary level of decentralization. The questions however are:

Do we need further distribution and delegation of planning and decision-making?
Do we know how to use tools given to do that?

I believe that as far as distributed ownership goes (discussed later) we are still sorely lacking in tools.

One important thing to note here is infrastructure-provider dependency. Simply put most solutions to one degree or another tie us to a particular cloud provider. Migrating SaaS solutions is all but impossible. I have never done FaaS solution migration and on paper it seems easier, but I might be horribly wrong.

Storage

We need to store data in our solutions. We need files managed by file systems, databases managed by DBMS, search indexes managed by search engines, etc. A well-studied problem of efficient content delivery has already given us tools to use decentralization in our systems. You need high level of redundancy, availability and performance for file delivery – use CDNs. How about the same for databases? Choose two letters from CAP theorem and there is any number of DBMS on the market for you. Infrastructure-provider dependency is of course an issue, but a well-known one.

Do we even need decentralization here? Do we want to distribute decision-making beyond contemporary DBMS and CDNs?

Sometimes. Interesting examples include projects like FileCoin, Storj, Sia, Genaro.

Infrastructure

We mostly covered this topic in previous two sections. We can have a fully in-house solution for infrastructure, but more often than not we will want to separate infrastructure concerns from solution concerns (debatable but I still believe this to be the case in all but very very very specific cases). One way or another infrastructure is typically provided by a cloud or hosting provider. If we want and need one we can always find provider with very high level of redundancy and availability.

Does this constitute decentralization?

I believe that without distributed ownership it does not.

Does it even matter as long as we get all the necessary benefits?

Usually we do not really care what honorifics our system has as long as the necessary features are delivered and will be delivered.

What about P2P solutions?

P2P systems are a very illustrative example of decentralization without any blockchain involved.

Ownership

This is the important part. Who owns, who operates, who manages the system? Who does the planning and decision making? One company. One beneficiary. One point of failure. All our tools, all our redundancy they all can be negated by a very simple fact of centralized authority. We know how to build system ran and operated by one authority.

The question is when do we want to distribute this responsibility?

I strongly encourage you before choosing blockchain as a tool for your project to do a research into Trusted vs Trustless.

Let’s try to look at some examples and understand what distribution of authority and blockchain, in particular, can give us.

Bitcoin.

Bitcoin has 1 feature: Value transference. To be able to do that on a global scale it has been built on top of a blockchain. People with long economic titles often say that challenges of modern financial system are best answered by a system like Bitcoin. We might even believe them. Which means that blockchains are best at supporting global systems built to transfer value.

Steem.

Steem has several features.

• Censorship protection. Transparent and immutable nature of blockchain guarantees censorship protection. Arguable. Personally I am not a big believer here. And I am from Russia where censorship is not some kind of a theoretical concept.
• Value determination. When you create an article on steemit, the system determines its value, and rewards you for it. This what really blew my mind because it meant that I can build systems that do that. IMHO there is huge potential here.
  So blockchain allows us to do value generation. I believe that just like value transference it is an emergent property which comes from the way the blockchain is built. Without blockchain, we still can rate an article and say that it is worth 2 “Exowuts”, but Exowuts can never become a globally accepted measure of value. I am on thin ice here as far logic goes and I spent many an hour debating this with peers. But at this point, I do believe this is true. And if your system demands a globally accepted measure of value blockchain is the best solution for you.
• Decentralized governance. Steem and to a larger degree BitShares can be viewed as an example to illustrate a very important thesis:

Decentralized systems better reflect wants of their users.

Because system beneficiaries are system users and vice versa. To understand this, imagine a centralized system. Owner of a centralized system is only incentivized to bring changes to the system that will benefit him. More often than not it is not a problem at all. He wants more users, to do that he wants happy users, to do that he delivers features which make them happy. But that is not always the case. What can be argued is that in systems with distributed ownership we can transparently guarantee direct or representative democracy, while in centralized one at best we can hope for a benevolent tyrant.

So for your system do you want Plato’s philosopher Kings or Aristotle’s democracy?

I strongly believe that we have ample evidence that in some domains of the Internet landscape monopolization is almost inevitable. Central authority with a monopolized market is a very nasty beast, easier avoided than slain. To illustrate my point imagine a video-sharing site - a place where you go to watch videos. More videos it has, less likely you are to consider its competitors. Ultimately the biggest video site will grow bigger smothering its competitors with its size (not necessarily its features). Yet again it might not be a bad thing. But after all, competitors are dead and it is almost economically unfeasible for new to appear,

What incentive is there for the site to respect the user ahead of the shareholder?

Does every system with distributed authority need a blockchain?

Blockchain is far from being “a must” for every project that needs decentralization and distributed ownership in particular. Blockchain imposes very strict rules as far as consensus goes, limits the performance of the system and forces your hand in many questions concerning the whole technology stack. However, a good tool needs a good ecosystem around it. And as far as distributed ownership goes at this point I do not know a more publicly accepted tool than Ethereum, a tool(box) with better commercial backing than Hyperledger, a more mature tool than Graphene, and a more promising tool than EOS. All four of them are blockchain-based. That said we are developing an in-house solution for a part of our own system which needs distributed ownership but does not necessary need blockchain. And I would gladly accept any feedback on this (or any other) issue.

Key takeaways

1. You have to understand do you even need decentralization and Trusted vs Trustless debate.
   https://hackernoon.com/ten-years-in-nobody-has-come-up-with-a-use-case-for-blockchain-ee98c180100
   https://medium.com/@kaistinchcombe/decentralized-and-trustless-crypto-paradise-is-actually-a-medieval-hellhole-c1ca122efdec
2. If you need reliability, availability, scalability there are better tools on the market than blockchain. I am planning to outline problems of blockchain-based solutions in future articles.
   https://en.wikipedia.org/wiki/Serverless_computing
   https://en.wikipedia.org/wiki/NoSQL
   https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html
3. If you need global value transference in your system then a public blockchain is currently the best solution.
4. There are domains for which this thesis can hold true: Decentralized system better reflect wants and needs of users.