Skip to main content

Ledgers

We first must gain an understanding on what centralised and distributed ledgers are. Only after which can we understand what distributed ledger technologies can offer.

Overview​

  • 1.1 Ledger Basics
  • 1.2 Centralized Ledger Problems
  • 1.3 Introduce Yourself
  • 1.4 Distributed Ledgers

[1.1] Ledger Basics​

Introduction

A ledger is a special type of database.

In a database, data can be organised in any particular manner.

Whereas a ledger records ownership of particular assets. These assets are moved from one owner to another via transactions.

Examples of ledgers include:

  • Currency ledgers operated by banks;
  • Land registries usually operated by a government body; or
  • distributed ledgers to track cryptocurrencies, operated by a group of pseudo-anonymous entities.

Historical Implementation

Historically, ledgers were held and updated by a single operator entity. Throughout these 3 sections we'll refer to this type of ledger as a centralised ledger. A centralised ledger’s single operator would be responsible for:

  • Allowing asset owners (and possibly others) to read the ledger;
  • Allowing and authorising valid transactions to update the ledger; and
  • Notifying any relevant party (e.g. regulators) about particular changes to the ledger.

Many years ago, all ledgers would have been paper based. Nowadays it is much more common to have digital ledgers. We will discuss the nuances between digital ledgers and distributed ledger technologies in the next sections.

[1.2] Centralised Ledger Problems​

Due to being operated by a single entity, centralised ledgers have a number of possible problems, which we discuss here.

Untrustworthy Operator

The worst case scenario is that the operator of this centralised ledger is malicious, intending to harm the users of this ledger in some way to benefit itself. Let’s look at two possible ways this can be done.

Data Manipulation

Due to the way that the ledger is stored, the operator has little to no accountability to its users. Therefore, the centralised ledger operator could modify any data in this ledger, so that when a user requests to read data from the ledger, they will be reading from an invalid version. To make this manipulation more complicated to detect, the ledger operator could route some user’s read requests to the correct version of the ledger, and route other user’s read requests to the operator modified version.

Charging for Access

With a centralised ledger, there is a lack of transparency on how its data is being used, which can benefit the single operator at the expense of the ledger users. For instance, the operator could sell access to the ledger data to third parties without the ledger users consent. Also the operator could enforce a paywall for any ledger user, such as registered asset owners.

Single Source of Failure

Even if a single ledger operator has the best intentions, the fact that the operator is one entity means that we are relying on only this operator to correctly maintain the ledger. But this can lead to the following issues.

Offline Operator

If the single operator’s system to access the ledger goes down (offline), nobody can access the ledger to perform actions such as reading the data or moving assets via transactions.

Attack on Operator

If the ledger data has value, it could become a target for attackers. In this case, we are relying on the single operator to have a secure enough system to repeal these attacks. Now if any attacks are successful, we are again relying on the single operator to identify the attacks and resolve them (by for instances rolling back any transactions added by the hacker).

Insufficient Data Backups

It can be the case that system failures occur (e.g. a server crash). If any centralised ledger data is destroyed in a system failure, we are relying on the single operator to have valid and available data backups in order to recover the ledger data.

Inefficient Dispute Resolution

Any disagreement with the centralised ledger data would have to be resolved after the disputed transactions have occurred. This dispute resolution process would be between the users the disputed transactions affect and the operator of the ledger. Depending on the issue, this dispute resolution process could be lengthy and possibly expensive. In the cases where the ledger operator is subject to an external regulator, disagreements with the ledger data could also be resolved via the regulator. But this will no doubt add further time and cost to any dispute resolution process.

[1.3] Introduce Yourself?​

Eh...

[1.4] Distributed Ledgers​

An alternative to a centralised ledger is one that is held and updated by multiple operators who reside in different locations. To do so, each operator is required to run distributed ledger software, commonly referred to as a node.

The vast majority of distributed ledgers are digital ledgers. In this course we will only concern ourselves with digital distributed ledgers implemented via software nodes. In these distributed ledgers technologies, it is assumed that there are multiple different operators running a node. Alternatively, a digital ledger with multiple nodes all run by a single operator, is conceptually still a centralised (controlled) ledger.

In this section we list the benefits of distributed ledgers. This section also highlights if any listed benefit is shared with a centralised digital ledger.

Regardless of the ledger type, when any ledger is held on multiple nodes, there needs to be technical protocols in place to make sure that the nodes contain ledger data that is consistent with each other node’s ledger data over time. These protocols must state how to realign the separate ledger data instances on each node if they become inconsistent.

Developing these technical protocols is a non trivial task, as in any multiple node system any of the following can occur:

  • Crash faults: a node may crash at any time.
  • Network faults: messages sent from one node to another may not make it to its destination.

Additionally, in a multiple node system with many different operators, the following can occur:

  • Byzantine faults: some operators may be malicious, intending to harm the users of this ledger in some way to benefit themselves. These operators may have modified the node software to run in unexpected ways to achieve their goals. Furthermore, a node could be faulty and be sending incorrect messages to other nodes.

Distributed Ledger Benefits

Using a distributed ledger has the following benefits, which mostly all relate to the fact that there is more that one node operator.

No Single Source of Failure

As there is no single source of failure, distributed ledgers have the following three properties, whereas digital ledgers can have only the first two properties.

Crash Fault Tolerance

If some nodes fail, data from the ledger can continue to be read and updated, as long as there is at least one node still running.

Partition Tolerance

The ledger can continue to be read and updated, even if there is a partition in the connections between the different nodes.

Byzantine Fault Tolerance

The ledger can continue to be updated correctly even if there are some malicious or faulty operators. Different distributed ledger technologies can tolerate different percentages of malicious actors on the network.

True Asset Ownership

With a distributed ledger, users can have full control of any asset assigned to them. This is because they do not have to rely on a single operator to authorise any related transaction, as they would in the centralised ledger case.

Decentralised Control

Some distributed ledgers allow any user to become a ledger operator should they want to. All the user would have to do is to download and run the relevant node software. This would allow the user to interact with the distributed ledger via locally running software. Using your own node provides the user with confidence that the ledger data being read is correct and that transactions are issued accurately.

Due to the technical knowledge and computation resources required, other users of the distributed ledger may prefer to not run the associated software. Instead these users can interact with the ledger through any operator running a node. If a user encounters a malicious or faulty operator (e.g. one that rejects transaction requests), the user can just select another operator to interact with.

Smart Contract Functionality

Another advantage of distributed ledgers is that they can contain automatically executing code (known as smart contracts). These smart contracts can execute code when certain data has been added to the ledger. For example, if someone adds data in the form of a vote for an election into the ledger, the smart contract could automatically update the vote count and keep track of the winning candidate.

Some distributed ledger technologies (e.g. Ethereum) allow smart contracts written in a Turing Complete programming language, meaning that any type of function can be coded. Whereas other distributed ledger technologies (e.g. Bitcoin) can have significant restrictions on the types of functions that a developer can write into a smart contract.