This is the first article in a series of posts covering everything from privacy, to smart contracts, to portability, and more concepts related to distributed systems.
When it comes to permissions, ownership, and authority there are roughly three different types of systems: centralized, distributed, and decentralized. Different business needs require different forms of ownership, authority, and permissions between the parties that are involved in any given workflow. In today’s world these workflows are often represented as applications that implement the underlying logic for a given business process.
The thing to think about here is what type of business workflow do I have that I will need to turn into an application and deploy on a system with one of these three properties. Keep this in mind as we work through these types of systems and then discuss applications that can run on them.
“If […] multiple entities/stakeholders need to know and enforce what is going on within the network then a distributed application may help you strike the right balance between collective decision making and adapting to changing needs. Daml does this.”
What is centralized, distributed, and decentralized?
Centralized is simple, a single entity has final say on all rules within the system, they can enforce the rules, change them, and ignore them to the degree they see fit. Websites would generally fall into the centralized category.
Distributed means multiple entities by some sort of process have come to have final say on the rules of the system, the control and relationships between these entities may change over time but ultimately this collaboration is the one in control. An example of a distributed system would be DNS in that it’s controlled by a multistakeholder group called ICANN.
Decentralized, perhaps the most misunderstood, simply means that all entities can freely choose (ie. without the approval of other entities) to directly participate in the network have their own independent and final say on the rules of the network. When they agree they can interact, and when they don’t they can’t. A decentralized system would be a network like Bitcoin or Tor.
What are the pros and cons of these systems?
A well designed centralized system will be maximally nimble, by reducing its ownership overhead it is able to change its rules to meet the needs of a changing world. Whereas on the cons side such systems also have the easiest time implementing rules that are detrimental to the system, or to remove those that were beneficial.
Distributed systems remain similarly nimble to centralized systems when those participating in them can come to a collective agreement about a change. However when entities disagree the system won’t change as easily. This provides the benefit of avoiding detrimental rule changes but may also hinder or delay the implementation of beneficial rules. In general, however, slower changing systems break less, and in systems requiring high reliability a little bit of friction is a good thing.
Decentralized systems are not nimble, they are publicly accessible, open to anyone to join, and opt for a slow speed of rule change. In exchange they gain maximum resilience such that all members of the system must agree to change the system; as opposed to a limited set of privileged users. Due to the extreme trade-offs these systems make they have a narrow band of uses where they are highly desirable, but for most regular business cases a centralized or distributed model is much better.
The application layer
We’ve spoken a lot about systems but now we need to talk about applications. Every application can have some variant of the 3 types of system design within itself and that may vary. In fact, you can run completely centralized applications on top of less centralized architecture. An example here might be a Daml application that has you as the sole signatory for exercising choices on a contract (ie. telling the contract execution/application what to do). You can go ahead and deploy it on a distributed network with many peers enforcing that the application executes as designed. So the enforcement of network execution and state is distributed, but the rules of the application are controlled entirely by you.
Effectively every level of increasing authority at the application layer can run on top of a system that is equally or more permissive, but not less. This is illustrated below.
Here we see distributed or centralized applications can run on distributed and decentralized systems. Any application can run on a network either as or less permissioned than itself.
Communication goes the same way. Centralized applications and systems generally have no difficulty keeping consistency with distributed and decentralized systems. However the opposite is not true, a distributed system could not expect a centralized system to give it consistent data every day. In the example above our Daml application could be running on a distributed network and have a side effect where some state is then recorded on a decentralized network that it is talking to.
When do I use these systems?
You use these systems when you have an application or workflow that has a business need for them. In general you’ll use these systems depending on who you need to involve directly in the maintenance of them and enforcement of rules.
If your business is developing an internal tool or consumer-facing website/service that deals solely between your business and the consumer then centralized may give you the best flexibility for iterating and improving that application. Daml does this.
If you have a complex series of relationships where multiple entities/stakeholders need to know and enforce what is going on within the network then a distributed application may help you strike the right balance between collective decision making and adapting to changing needs. Daml does this too.
If you’re looking for a completely open network where the entire world has equal ability to participate and determine the rules and state of the system then you’ll want to create a decentralized system. Bitcoin and a few other non-blockchain systems like Tor effectively do this.
Hopefully this short primer on the nature of these types of systems has been useful. If you find yourself wanting to create a distributed (or centralized) application then you may want to check out Daml which provides a highly portable language that’s specifically geared towards managing business processes and permissions. There’s very little backend to worry about and it runs on top of everything from SQL to Hyperledger Fabric, Sawtooth, and much more.
Also stay tuned for the next articles in this series where we’ll cover the theoretical basis of everything from privacy, to smart contracts, to portability and more.