Our Path To Decentralization

Radix DLT
23rd August 2018

Since the popularisation of Decentralised Ledger Technology (Blockchain/DAGs/Tempo), we have figured out many uses for it, such as crypto currencies, digital collectibles, digital identity, voting, many different peer to peer marketplaces, tracing philanthropic giving, supply chain management and many more.However,  there has been relatively little  explorations of the multiple ways in which it can be applied into existing systems and how they compare to one another.Let’s start by taking a look into the different approaches that have been used so far.

First, there were centralized systems

Centralized systems have been used since the 1960s for every kind of enterprise application, although inherently built on the need to trust server operators, they are proven to be both efficient and safe. In order to deploy a centralized system, companies typically use the following approach:

  1. Business Logic (software) is stored in a Server/Data Center under their control.
  2. Data and files are stored in a Server/Data Center under their control.
  3. Value is stored in a Data Centre under the control of a Bank.

In the current system, value is never under the direct control of a non-financial company; this has meant that while other technology has been able to quickly progress, financial technology has always sat outside of the technology stack.

There are several reasons for this:

  1. Money has become gradually digital – banks were institutions with the physical custodianship of value for centuries before the idea of digital currency became possible. This position of responsibility spawned much regulation to prevent those responsible for caring for this wealth from being dishonest with it – with limited success!
  2. Traditional systems inherently rely on a system of very basic trust permissions; giving very little granularity over the access control for the systems that actually have the ability to make a financial transfers.
  3. Sovereign states currently have no unbreakable way of making sure that a digital asset (like fiat) has a limited supply. Instead, they regulate who can issue, hold and transfer their sovereign currency, and ensure that neither too much or too little supply is created through a system of checks and balances with a central bank
  4. This, combined with the regulation that surround banking, means that although the Banks are not infallible either, there are regulatory constraints that ensures banks to be  the only institutions allowed to control digital representations of fiat.

This lack of granularity and the trusted role of the bank has kept the control of the technology that controls money directly under the remit of the banking system.All these measures are extremely expensive to deploy and maintain.

Then, Bitcoin was created

DLT technology is fundamentally a merger of these three domains: Logic; Data; Value.

A set of primitive constraints directly built-in on the protocol are enforced by all the nodes on the network creating a set of rules that can be trusted by everyone, without the need of a central authority.

These rules also create a much more granular permission set – one where my permission to act in the system is strictly bounded, but unlimited in scope – meaning I could control one address, with a tiny balance, or millions with a huge balance – the system of permission and control scales up and down according to only that which I can prove to control; rather that which some central authority has given me permission to use.Bitcoin’s protocol however, provides a very limited amount of constraints, such as only allowing for a single asset to be transferred on the ledger. It is because of this that companies could only apply some of its benefits to their systems, such as:

  1. Value is stored in a Distributed Ledger.
  2. Simple logic is stored in a Distributed Ledger, such as multi-sigs and scripts.

This improvement may seem minimal, since companies were already trusting banks to store their value, but it is not. Imagine yourself selling a concert ticket to a friend. You can send him the email with the ticket in PDF, however you (and all the servers that store your email) still have a copy of it. Your friend needs to trust everyone else with a copy not to use it before he does.Thanks to DLT, value is transacted, not copied.

The rise of Smart Contracts

Soon after this, platforms such as Ethereum allowed for the inclusion of business logic (code) on the ledger, enforced by all the nodes on the network executing this logic in a deterministic manner. While inefficient at scale, it added the ability to audit the output of a simple program, as well as have that program deal directly with value.This allows for the creation of completely decentralized applications and even decentralized autonomous organizations – an idea of an organisation that is governed entirely by the rules of code and which administers its own finances according to those rules..In order to maintain their decentralization, smart contracts need all information required for their execution (including the code plus any input data) to be stored on the ledger as well.Therefore, the end state of most of these systems typically looks like this:

  1. Business Logic is stored in a Distributed Ledger
  2. Relevant Data is stored in a Distributed Ledger
  3. Non Relevant Data is stored in a Data Center (or IPFS)
  4. Value is stored in a Distributed Ledger

As you can see, this means that companies with existing infrastructure that wish to go fully decentralised need to migrate their entire (working and tested) business logic and data. This is a big issue, since using a DLT to store everything is a very expensive operation.It is because of this that most of what we are seeing on the ecosystem at this point are proof of concepts that explore how to use the technology, but hardly ever reshape the company’s core business process.

Our take on Decentralized Applications

For the last few years, DLT developers have shifted from completely centralized systems towards completely decentralized ones. However, each one of them have different properties and neither should be completely disregarded.Here at Radix, we are building a platform that aims at enabling the best of both and believe that:

  • Value should be maintained and transacted through trustless ledgers.
  • Protocol level constraints should be the only thing that need to be trusted.
  • DLT can significantly reduce the cost of software development and maintenance.
  • Most business logic doesn’t need to be decentralized. However, in some cases it should be.
  • Both centralized and decentralized logic can profit from using protocol level constraints.

On this series of posts, we will explore the different architectures that can be used when building decentralized systems, how they work and their benefits and issues.Stay tuned.