Any Distributed Ledger Technology (DLT) has a few specific components that we will discuss in this section.

Identity Management

In a distributed ledger, all data is linked to an identity (usually referred to as an account or address), to establish ownership. Accounts can be controlled by cryptographic key pairs or smart contract code.

In a permissionless DLT network, users can compute a cryptographic key pair locally on their machine (or outsource this feature to a centralised wallet provider). In permissionless DLT networks, an individual user can control one or more ledger identities.

In permissioned DLT networks, identity is usually more tightly controlled. Even though users can still compute a cryptographic key pair locally on their machine, they may also be required to be certified by a certificate authority before they can submit transactions to change the ledger.

We will discuss more about identity in week 3.

Ledger State and Ledger Updates

In a distributed ledger, its current and possible future states are defined by its virtual machine. Originally, each DLT could only have one associated virtual machine, but nowadays there is more flexibility. Properties of distributed ledger virtual machines, include:

• State Model: How does the virtual machine model the current and future state?
• State Transition Function: How are valid transactions formed and how are they processed by the virtual machine?
• User Defined Code: Can user defined code (commonly referred to as smart contracts) be added to the ledger and processed by the virtual machine?
• Turing Complete Smart Contracts: Can users write smart contracts using a Turing Complete language?

The Ethereum virtual machine was the first instance of a virtual machine that allowed Turing complete smart contracts to be added onto a permissionless DLT network, but nowadays there are a few others such as the web assembly virtual machine used by the Substrate DLT.

We will discuss more about the ledger state and updates in week 2.

Transaction Ordering

Distributed Ledger Technologies can have different ways to order the transactions to update the ledger.

Blockchain Ordering

A blockchain requires transactions to be grouped together in blocks. Each block must be linked to one previously accepted block. An accepted block is one that the DLT nodes have agreed to process to update the distributed ledger. For a blockchain, every DLT node must process each block in sequence order and for each block, every transaction must be processed in sequence order. Examples of DLTs using a blockchain include Bitcoin, Ethereum and the XRP ledger.

Directed Acyclic Graph Ordering

A Directed Acyclic Graph (DAG) does not group transactions into blocks. Instead, each transaction must be linked to other accepted transactions. An accepted transaction is one that the DLT nodes have agreed to process to update the distributed ledger. This DAG structure allows each DLT node to process transactions in different orders. In fact, a DLT node may not need to process large subgraphs of the DAG at all, if the transactions in these subgraphs do not affect parts of the ledger that the DLT node is concerned with. An example of a DLT using a DAG is Corda.

Block DAG Ordering

A block DAG groups transactions into blocks. Each block must be linked to at least one accepted block. Therefore, blocks become connected in a DAG structure. This block DAG structure allows DLT nodes to process blocks in different orders. Similarly to DAGs, a block DAG allows a DLT node to not process large subgraphs if the transactions in the blocks of the subgraph do not affect parts of the ledger that the DLT node is concerned with. An Example of a DLT using a block DAG is Hashgraph (where blocks are called events or transaction containers).

Selectable Ordering

Finally, some DLTs allow a selectable transaction ordering method. An example of a DLT with a selectable ordering system is Avalanche, which orders via a blockchain on it’s c-chain implementation and via a DAG on its x-chain implementation.

Consensus Protocol

The DLT nodes of each DLT network must come to a system wide agreement on the order of transactions to update the distributed ledger. This allows each DLT node’s ledger data to be (at least eventually) consistent. To do so, the DLT nodes follow a set of rules and procedures defined in the DLT network’s consensus protocol (sometimes referred to as a consensus mechanism).

Each consensus protocol must have the following two main components.

Anti-Sybil Mechanism

The first main component is the anti-sybil mechanism. The purpose of an anti-sybil mechanism is to prevent individual DLT nodes from replicating themselves to increase their influence on how the entire DLT network reaches consensus. There are many proposed anti-sybil mechanisms, the most prevalent ones in permissionless DLT networks are currently:

• Proof-of-Work: Where each single DLT node is weighted according to the amount of computation power it has. Should the operator of this single DLT node instead create multiple DLT nodes, the operator would now have to divide his available computation power between all of his DLT nodes. This would mean that the collection of all the DLT nodes would have an equal weight when compared to the single DLT node deployment, which implies that the operator gains no benefit, from a consensus perspective, of deploying multiple nodes.
• Proof-of-Stake: Where each single DLT node is weighted according to the amount of a certain token it has. Should the operator of this single DLT node instead create multiple DLT nodes, the operator would now have to divide his available tokens between all of his DLT nodes. This would mean that the collection of all the DLT nodes would have an equal weight when compared to the single DLT node deployment, which implies that the operator gains no benefit, from a consensus perspective, of deploying multiple nodes.

Communication Rules

A consensus protocol’s second main component is its distributed ledger data communication rules. These rules detail what functions a DLT node should run:

• Upon Receiving Messages: When receiving distributed ledger data (transactions, blocks) from other nodes or direct from ledger users. For instance, what checks should a node perform in order to verify a transaction or block received from another node before using it to update the ledger?
• Before Sending Messages: When broadcasting distributed ledger data (transactions, blocks) to other DLT nodes. For instance, how can a correctly formatted block of transactions be created?

Finality of Ledger Updates

A consensus protocol’s communication rules will be designed for deterministic or probabilistic transaction finality.

• Deterministic Transaction Finality: When a transaction is accepted to update the ledger, it can never be rejected.
• Probabilistic Transaction Finality: When a transaction is accepted to update the ledger, it maybe eventually rejected. Overtime, the likelihood of rejection decreases.

Probabilistic transaction finality generally promotes liveness of the ledger. Where the ledger can always be read and updated. Whereas deterministic transaction finality generally promotes safety, where correct data will always be read from the ledger (but there can be periods when the ledger cannot be updated).

Naming

Consensus protocols are commonly referred to according to their anti-sybil mechanism, even though the actual communication rules may differ. For example, both Bitcoin and Bitcoin Cash use a proof-of-work anti-sybil mechanism, and both are usually referred to as having a proof-of-work consensus protocol. But Bitcoin and Bitcoin Cash differ in their communication rules, where nodes of a Bitcoin Cash DLT network are allowed to create and send larger blocks of transactions compared to nodes of a Bitcoin DLT network.

Incentivisation

DLT nodes are incentivised to follow a consensus protocol. If a DLT node deviates from the consensus protocol, it’s copy of the ledger will go out of sync with others, leading to this DLT node being removed from its original DLT network and instead establishing a new DLT network for itself and any other DLT nodes that follow this deviation.

There is also a positive motivation for DLT nodes to follow a consensus protocol of a permissionless DLT network. That is, if a DLT node successfully produces an accepted block (or an accepted transaction for DAG ordering systems), then it will receive a cryptocurrency reward and this cryptocurrency will hold real economic value. This reward comes from:

• The generation of new cryptocurrency coins; and/or
• Collecting transaction fees from the newly accepted transactions.

If a DLT node deviates from a consensus protocol, thereby establishing a new DLT network, by definition the cryptocurrency given on the new DLT network as a reward will not be the same coin as on the original DLT network. This new cryptocurrency will usually be valued significantly less compared to the reward on the original DLT network.

In permissioned DLT networks, nodes will not have these cryptocurrency rewards. But DLT nodes in permissioned DLT networks have their identity established and verified, therefore these nodes have additional incentives from matters such as reputation or legal responsibility.