The general ledger holds account information that is needed to prepare the company’s financial statements, and transaction data is segregated by type into accounts for assets, liabilities, owners’ equity, revenues, and expenses.
The concept of the ledger in distributed ledger technology (DLT) came into existence before Bitcoin and blockchain technology. DLT systems emerged back in 1982, while the earliest occurrence of the ‘blockchain’ concept can be traced to 1991. Unclear terminology and fuzzy boundaries over the time between blockchain and DLT have resulted in ‘DLT’ evolving into an umbrella term used to designate a variety of loosely related concepts in the blockchain. Read more about Complete Guide to Blockchain.
Different Definitions of DLT
There exist many different definitions of distributed ledger technology (DLT) systems in the literature, and many publications on the subject set out their own unique definition in their preamble.
European Central Bank (2016) describes DLT as a technology that “allows their users to store and access information relating to a given
set of assets and their holders in a shared database of either transactions or account balances. This information is distributed among users, who could then use it to settle their transfers of, e.g. securities and cash, without needing to rely on a trusted central validation system”.
Bank of England (2017) summarises its definition as “a database architecture which enables the keeping and sharing of records in a distributed and decentralized way while ensuring its integrity through the use of consensus-based validation protocols and cryptographic signatures”. Read more about 10 Useful Consensus Mechanism Algorithms.
World Bank (2017) describes DLT systems as “a specific implementation of the broader category of ‘shared ledgers’, which are simply defined as a shared record of data across different parties”.
As shown by these definitions, there is no genuine and universal definition for what is referred to as a DLT system. Adding to the challenge is that on the one hand, definitions are sometimes too specific, technical, and inaccessible to general audiences; while on the other hand, some are too simplistic and broad so that no meaningful difference to more traditional database architectures can be observed.
One interpretation of the DLT concept in its most narrow definition isAn append-only chain of cryptographically-linked ‘blocks’ of data, maintained and updated by a decentralized network, with network nodes encouraged by economic incentives to engage nonstrategically25 to maintain and secure the system so that the data – organized in a specific structure often referred to as ‘global ledger’ – is robust to adversarial interference, double-spend, censure, counterfeit, collusion, tampering, or other types of malicious actions.
Centralized Database Vs. Distributed Ledger Technology
Before exploring the differences between centralized and distributed ledgers, first, understand the different types of systems. Here comparisons are made based on the perspective of control and perspective of the location.
Perspective of Control
From the perspective of control, there are two types of systems—centralization and decentralization database systems
- Centralized Database system: One entity aka node controls the entire system, where a node can be a person or an enterprise.
- Decentralized Database system: In a decentralized system, there could be multiple nodes controlling the system. There exists no single point of control, and the control is shared between various independent nodes.
Perspective of Location
From the perspective of location, there are two types of systems—centralized and distributed systems
- Centralized system: All the constituting parts of the system, such as servers, ledgers, and so on, are co-located and exist at the same location
- Distributed system: All the constituting parts of the system, such as servers, ledgers, and so on, are not co-located and exist at different locations
On comparing the centralized, distributed, and DLT systems, it can be seen that how each system takes inputs from various sources, control over how data is stored, processed, and executed varies from one type to another.
Five Properties in Distributed Ledger Technology
A DLT system needs to be capable of ensuring the following properties, either in the existing system or with minimal changes to the system.
a. Shared recordkeeping: enables multiple parties to collectively create, maintain, and update a shared set of authoritative records (the ‘ledger’).
b. Multi-party consensus: enable all parties to come to an agreement on a shared set of records
- If permissionless, without relying on a single party or side-agreements, and in the absence of before the event trusted relationships between parties; and
- If permissioned, through multiple record producers who have been approved and bound by some form of contract or other agreement.
c. Independent validation: enable each participant to independently verify the state of their transactions and the integrity of the system.
d. Tamper evidence: allow each participant to detect non-consensual changes applied to records trivially.
e. Tamper resistance: make it hard for a single party to unilaterally change past records (i.e. transaction history).
The Concept of Ledger in Distributed Ledger Technology
There is significant overlap and similarity among many of the terms used to describe the components of DLT systems. This often results in ambiguous or conflicting use of terminology. Consider, for example, the term ‘ledger’. Not only does the DLT system literature assign ‘ledger’ in distributed ledger technology a different meaning from the one used in disciplines like accounting or finance, but the DLT literature itself uses the term to describe two very different ideas
- the set of data held by an individual network node, and
- the set of data held in common by the majority of nodes.
The goal of a DLT system is to keep these individual instances (journals) of the structured record in sync, leading to a convergence towards a single accepted set of authoritative records (the ledger).
This enables a group of separate parties that do not necessarily trust each other to reach an agreement over a shared set of data without having to rely on a central authority. Conceptually, the ‘ledger’ should be regarded as a latent, abstract construct that is generated by the DLT system as a whole through the constant efforts of synchronizing the individual copies maintained by each full participant.
Five Key Ledger Concepts
- Transaction: any proposed change to the ledger; despite the connotation, a transaction need not be economic (value-transferring) in nature.
2. Log: an unordered set of valid transactions held by a node, which have not yet been incorporated into a formal record subject to network consensus rules (i.e. ‘unconfirmed’ transactions).
3. Record: transaction data that has been subject to network consensus rules. Note: A ‘candidate record’ is a record that has not yet been propagated to the network.
4. Journal: the set of records held by a node, although not necessarily consistent with the consensus of other nodes. Journal are partial, provisional, and heterogeneous: they may or may not contain all the same records.
5. Ledger: the authoritative set of records collectively held by a significant proportion of network participants at any point in time, such that records are unlikely to be erased or amended (i.e. ‘final’).
Transaction Maintenance in Distributed Ledger Technology
A transaction contains a set of instructions that will be executed once the transaction has been added to the ledger in distributed ledger technology. Generating a transaction can either be unrestricted (i.e. open to anyone) or restricted to select participants. Transactions are generated by users signing a message in a standardized format using the corresponding private key. There are different interfaces available to end-users for creating and broadcasting transactions to the network (e.g. desktop and mobile wallets).
Records are subject to the consensus algorithm used by the DLT system to reach an agreement over the state of the system. This includes a process for determining whether a proposed record is valid, as well as rejecting invalid records (e.g. records which are defective or noncompliant) and choosing among different, yet equally valid records.
Bitcoin Ledger Use Case
Using Bitcoin as an example, a transaction can be a transfer of an asset from one address to another; a node’s log is its mempool (i.e. the collection of unconfirmed transactions the local node has received from connected nodes, which have not yet been processed into records).
A record would be a confirmed block; a node’s journal is its individual, locally stored copy of the blockchain, which may be incomplete or contain data unknown to the rest of the network; and the ledger in distributed ledger technology would be the authoritative set of blocks which are, by consensus, considered ‘final’ – i.e. which have a vanishingly low probability of being overwritten by a more-worked subchain. Read more about Genesis Block of Bitcoin
Each node in the network has its own, potentially imperfect ‘copy’ of the ledger (i.e. a journal). This means not only that some of the data held by the node are provisional and partial, but that it may not always reflect the complete set of structured, authoritative records as determined by the consensus mechanism set out by the protocol.
DEAR READER, THANKS FOR READING THE POST.I would love to hear your comments or feedback on Ledger in DLT.