DLT and Blockchain: History, Differences and Solutions
Distributed Ledger Technologies (DLT) are the set of technologies from which the blockchain is derived.
D as in Distributed (and Database)
DLTs fall into the IT category of decentralised or distributed databases. A database is a set of structured information stored in a computer system.
Centralised databases (CDB) are databases located, stored and maintained in a single location, which is usually a central computer. They are generally used by companies or institutions.
Distributed databases have emerged with the spread of the Internet, and are based on multiple computers, which may be in the same location, or distributed around the world and connected via a network. In the illustration below, these two types of databases are distinguished by the programming language used (SQL).
The particularity of DLTs is that they are databases distributed over a global network and are based on cryptography.
L as in Ledger
The ledger is normally the record of all financial transactions of a company, all cash spent and received.
The ledger, together with the journal, is used for general accounting. In the journal, transactions are recorded chronologically, whereas in the ledger they are recorded systematically, i.e. according to the object to which they relate.
The L of DLT, therefore, describes the function of these technologies, implying an immediate use case.
T as in Technology
The technological solutions that have enabled the emergence of a functioning DLT such as the blockchain are many.
In 1991, Stuart Haber and W. Scott Stornetta wrote “How to Time-Stamp a Digital Document”, where they propose practical procedures to certify when a digital document is created or modified.
In 1997, Adam Back proposed Hashcash, a proof-of-work system used to limit spam e-mail and denial-of-service attacks.
A denial of service is a computer attack that aims to render a network or service inaccessible.
In 2002, David Mazières and Dennis Shasha proposed blocks as a system for storing data on a network.
In 2005 Nick Szabo proposed the first decentralised currency, which he called ‘bit gold’.
However, it was Satoshi Nakamoto who was the first to solve the problem of double-spending and the Byzantine Generals (see Diving Deeper). He/she/they put all these concepts into practice by creating the first truly decentralised cryptocurrency on blockchain, whose consensus is reached through Proof-of-Work.
This is a risk associated with virtual currencies, in particular the possibility of spending the same amount several times, thus increasing the number of currencies in circulation and obtaining money illegally. Centralised systems such as payment circuits overcome this problem by relying on an intermediary. Decentralised systems such as blockchains, on the other hand, use consensus mechanisms such as Proof-of-Work and Proof-of-Stake.
The difference between DLT and blockchain
The terms DLT, blockchain and blockchain technologies are often used synonymously. This is because their terminology is still being defined, and few official dictionaries and encyclopaedias have understood and included them. They have not entered the standard language.
Authoritative sources such as the World Bank define DLT as a set of technologies from which blockchain is also derived.
What distinguishes blockchain is that it uses cryptographic and algorithmic methods to create and verify an ever-growing data structure that takes the form of a chain of so-called “blocks”, acting as a ledger.
In fact, apart from the blockchain, there are few viable examples of DLT.
DLT besides blockchain
Within DLT, a distinction is made between private and public, permissioned and permissionless DLs (Decentralised Ledgers). This determines who has access to participate.
Currently, the only permissionless and public DLs are cryptocurrency blockchains, while DLs that meet other use cases are permissioned, as they are mainly used by financial institutions, government agencies or companies.
A distinction is also made between “pure” DLs and blockchain-like DLs.
“Pure” DLs use different solutions to execute transactions.
Let us take as an example the Ledger Hashgraph of Hedera, a company whose board of directors is composed of large international companies.
- It does not use a system of blocks, but of DAG (Directed Acyclic Graph) to arrange transactions in sequence.
- It does not use validators (or miners), but a “gossip about gossip” protocol in which individual nodes in the network “gossip” about transactions to create DAGs.
Each “gossip” message contains one or more transactions, timestamps, a digital signature and the cryptographic hashes of two previous events. This consensus mechanism makes the ledger Byzantine Fault Tolerant, i.e. immune to any inactive or malicious nodes.
Hyperledger and Corda, on the other hand, are two projects that fall under DL permissioned, and have blockchain-like features.
These ledgers are both open-source and allow collaboration between tens of companies and institutions.
Use cases beyond Crypto
Finance is undoubtedly the most receptive sector for these technologies, but DLs have also proven to be useful for private companies, governments and institutions to minimise fraud, data security and streamline processes.
The CBDC discourse as well as the issue of privacy and the use of sensitive data are accelerating the process of research, prototyping and implementation of these technological solutions.
The potential use cases that await us in the future are similar to those of blockchain, so they cover any sector that requires data protection and tracking, especially in order to solve privacy issues in data sharing.
Diving Deeper: Byzantine General problem
As anticipated, the problem of Byzantine Generals was overcome for the first time by Bitcoin and allowed the development of new DLT solutions.
Byzantine Fault Tolerance is the property of a blockchain to be immune to the Byzantine Generals problem, which is known to logic and game theory enthusiasts.
The problem consists of allowing 4 generals to make a decision and make their move in a coordinated manner.
Here are the assumptions:
- Around a fortress, there are 4 Byzantine generals, each with his own army
- They can decide to either attack or retreat
- The decision and action must be unanimous
- They cannot change their minds
- They can send messages to each other to communicate the decision
The difficulty is created by the fact that messages can be lost, or one or more generals can betray others and send a message that puts others in danger.
A Byzantine Fault Tolerant system, thanks to a specially designed consensus system, is not hindered if a network participant acts in a harmful way or does not participate.
On the blockchain, this greatly reduces the latency of transaction verification.