distributed ledger technologies (DLTs)

•  What are distributed ledger technologies (DLTs)?

In a traditional marketplace, middlemen oversee the exchange of assets. When you receive your paycheck, for example, a bank controls the transaction. The bank validates the check, verifies that the employer holds the required funds in their account, and records the exchange. This record, or ledger, documents the transaction and the resulting change in wealth

Imagine, for instance, that your employer owned the ledger instead of the bank. Your employer could falsely claim that they paid you and manipulate the records to back up their lie. Because of this security risk, neither participant in the exchange should be given sole control of the ledger.

For most of history, the best way to avoid this kind of fraud was to entrust an unbiased intermediary with the ledger and hope that this middleman would faithfully maintain the ledger. In other words, traditionally, two parties who agreed upon a transaction relied on a third-party institution to carry out and record the exchange

Blockchains & distributed ledgers explained

Distributed ledger technologies, like blockchain, are peer-to-peer networks that enable multiple members to maintain their own identical copy of a shared ledger. Rather than requiring a central authority to update and communicate records to all participants, DLTs allow their members to securely verify, execute, and record their own transactions without relying on a middleman.

While there are a wide variety of DLTs on the market, they are all comprised of the same building blocks: a public or private / permissioned / permissionless distributed ledger, a consensus algorithm (to ensure all copies of the ledger are identical), and a framework for incentivizing and rewarding network participatio

Public vs. private and permissioned vs. permissionless

Distributed ledgers are categorized as “private” or “public” and “permissioned” or “permissionless” — they can be any combination of any of the two.

To achieve full decentralization, Hedera believes distributed ledgers must be public permissionless networks.

Private / Permissioned: 

This type of network offers no decentralization

The applications and the network nodes running those application must both be invited to join the network and meet certain criteria or provide a form of identification

Private / Permissionless: Requires that applications deployed in production be invited to join the network and can be removed without warning at any time. The nodes which constitute the network and run said applications can freely and anonymously join and contribute, typically in exchange for a network’s native cryptocurrency. 

Public / Permissioned: Allows applications to be deployed in production or removed, without having to notify anyone, reveal their identity, or meet any application criteria requirements. The nodes which constitute the network and run said applications must be invited to join the network.

Public / Permissionless: This type of network is the most decentralized. Applications can be deployed in production or removed, without having to notify anyone, reveal their identity, or meet any application criteria requirements. Additionally, the nodes which constitute the network can freely and anonymously join and contribute, typically in exchange for a network’s native cryptocurrency.

Reaching consensus

Although every node on a permissioned or permissionless distributed ledger maintains and updates their own copy of the ledger, it is imperative that each of these ledgers remains identical. Imagine, for instance, that your copy of the ledger reveals that you have $100 in your account, while the cashier’s ledger holds that you have $1

Without identical ledgers, participants in the network could not make transactions.

In order to keep the distributed ledger consistent, DLTs must have a consensus algorithm, or a method of ensuring that all copies of the ledger agree

A consensus algorithm is a method of synchronizing the data across a distributed system. In the case of a DLT, the consensus algorithm ensures that all copies of the ledger are identical.

Perhaps the most intuitive algorithm is a simple vote. According to this algorithm, each node independently calculates how they think they should update their ledger based on the information available to them

Because DLTs become more secure and transparent when more nodes are added to the network, many other consensus algorithms have been developed to better suit the need for large, efficient, and reliable peer-to-peer networks

Just as DLTs distribute the responsibility of maintaining the ledger to each participant, so do they divide this computational burden. Every node must donate computing power to run the consensus algorithm and process transactions.

DLTs typically reward active membership with cryptocurrency. Cryptocurrency is a virtual, encrypted token which can be exchanged using across a decentralized network. These coins can be exchanged, purchased, or earned by participating in the network.

Therefore, participants have an incentive to contribute computational resources to the network. Not only is their work rewarded in cryptocurrency, the value of that currency may rise as the network grows and more build useful applications on the distributed ledger platform.

Distributed ledger technologies allow businesses and individuals alike to quickly carry out secure transactions without needing to rely on a middleman. By avoiding intermediaries, distributing control of the ledger, and providing a tamper-apparent network, DLTs present a more cost-efficient, accessible, and reliable transaction platform than centralized ledger systems.

Without a central agent, there is no need to pay a central agent. And, without the need for clunky bureaucracy, you can exchange assets directly and immediately. You no longer have to limit the speed of your transaction to the efficiency of expensive bankers, lawyers, or politicians

Moreover, you no longer have to trust bankers, lawyers, or politicians with the ledger and your assets.

Tamper-apparent

Traditional ledgers may provide fast and simple record-keeping, but they are vulnerable to corruption and hacking. Because only one central entity controls the ledger, a corrupt central agent can tamper with the records without the consent or knowledge of the affected members.

Distributed ledgers, however, are inherently resistant to tampering. While a malicious agent could compromise a central system by altering the single ledger, they would need to alter at least a plurality of ledgers to have an impact on a distributed system. 

Though DLTs are not tamper-proof, they are tamper-apparent. That is, if tampering does occur, the network’s transparency ensures that all members of the network will be aware of the change. Though a participant of a DLT cannot be completely certain that the ledger will remain unaltered, they can rest assured that they will know if tampering does occur.

Immutability and controlled mutability

Some distributed ledgers take security beyond tamper-apparent by establishing immutability, preventing any and all participants from changing established records for any reason.

Members of these immutable DLTs can only view the ledger and carry out new transactions. Even if all participants in the network wished to change the ledger, there would be no pathway within the system’s architecture for that change to occur. Therefore, participants of an immutable distributed ledger can be certain that their ledger is not only tamper-apparent, but tamper-proof

A distributed ledger technology is immutable if it does not provide any participant or group of participants the ability to alter or delete established records.

 In some cases, changing past records could be beneficial. For instance, if a bug in the DLT’s code causes a transaction to be misrepresented in the ledger, immutability would prevent anyone from fixing that problem. The invalid transaction would forever be part of the official ledger. 

 

 Additionally, as laws change to catch up with technology, new government regulations may necessitate a change in record-keeping practices. Immutable systems would not be able to adapt to these changing legal conditions, and would therefore risk violating government standards.

 

 some DLTs opt for controlled mutability. DLTs with controlled mutability allow records to be changed, but place heavy restrictions upon that pathwa

 

 Controlled mutability is the best of both worlds: no malicious participant or group of participants can alter the records without everyone knowing (tamper-apparent), but the DLT can adapt to bugs and changing regulations.

 

 

https://hedera.com/learning/what-are-distributed-ledger-technologies-dlts?utm_term=distributed%20ledger&utm_campaign=Learning+Center+-+DLT&utm_source=adwords&utm_medium=ppc&hsa_acc=1782665900&hsa_cam=11155745237&hsa_grp=106221302541&hsa_ad=466328121346&hsa_src=g&hsa_tgt=kwd-328485320044&hsa_kw=distributed%20ledger&hsa_mt=b&hsa_net=adwords&hsa_ver=3&gclid=CjwKCAjwy_aUBhACEiwA2IHHQCKBLfq4-DlgFTVYEqJmdbgWBJ5IxP2klKiF6AlJ2rn7vnManyh9choCsS0QAvD_BwE

• Distributed Ledger Technologies

All participants share a consistent copy of the database, there is no central server

 Some participants might not have a full copy

 Network connections are peer-to-peer

 Participants must comply with ledger rules

 permissionless ledger – anyone could join

 permissioned ledger – participation is subject to rules of the members

 Using a type of consensus protocol, to agree on validity of a given transaction

 Transactions – could be financial and/or exchanging of assets and/or services

 Rules for a transaction could be coded into what is called smart contracts

 Uses digital signatures (private/public key) to sign and/or encrypt transactions on the ledger

 Signatures could be linked to identity

 Represents a temporal order of how assets evolve over time

Miner

A miner is a participant in a Blockchain that participates in securing the network and validating new

transactions. The mining and validation process happens via either competitive, voting or luck-based

methods dependant on the consensus protocol chosen. Miners are incentivised to participate in a

Blockchain either because they receive mining rewards in the form of cryptocurrency (eg. Bitcoin) or

because they have a vested interest in accessing and exchanging data on that network (such as a business

that chooses to participate in an industry or market-specific Blockchain).

Consensus protocol

The core difference between a distributed ledger and a traditional database is the way in which datasets

evolve over time. The system allows multiple participants to submit new inputs to a distributed ledger.

Consensus is then used to determine over time which state of the database is considered as valid. This is in

contrast to a traditional database, where multiple participants submit new inputs and one counterparty is

relied on to provide the valid state of the database.

One of the key aspects of a distributed ledger is that the data held within it, is considered valid because all

parties agree to a single “true” version.

In the event that existing participants in a Blockchain decide to

include data in a non-compliant manner with established protocols, an event named a fork occurs.

Forks result in a split of the ledger and the consequent creation of two groups, each validating their

own version of the ledger. In order for participants to be able to continue to interact with each other,

they are required to follow the same fork of the ledger.

The following table gives a brief overview of main consensus protocols in use

Proof of Work

Uses computational power to validate new blocks of data.

To participate in this scheme, participants are required to collate transactions within a

single block and then apply a hash function with the use of some additional metadata.

Proof of Stake

Validators (special nodes) voting on valid blocks whilst posting collateral in order to be able

to participate in the validation process.

Unlike Proof of Work, Proof of Stake relies on proving the user is invested in the underlying

token of value of the network being mined rather than being the owner of a large amount

of computing power

Ripple Protocol

In order to validate new transactions, servers amalgamate outstanding transactions into a

“candidate list.”

All participants then vote on valid transactions to be included in the ledger.

Proof of Elapsed Time

As part of its Intelledger proposal, Intel has devised a means of establishing a validation

lottery that takes advantage of the capability of its CPUs to produce a timestamp

cryptographically signed by the hardware.

Whoever in the chain has the next soonest timestamp will be the one to decide which

transactions will be a part of the next block in the chain.

This consensus method is extremely energy efficient compared to Proof of Work and

therefore more adapted to IoT devices

Cryptography

Distributed ledger technology relies on the use of asymmetric cryptography to sign messages and encrypt

data through the use of a private/public key pair. 

Cryptography is also involved in some of the consensus protocols (e.g. Proof of Work) and is the primary

vehicle in achieving consensus.

The private keys, which allow a given entity to transact with the assets or virtual currency allocated to it in

the Blockchain are typically stored in what is called a wallet. 

Sidechains

The standard operation of a distributed ledger might allow thousands of transactions which in some cases,

might result in slow processing.

 These are the concept of running a separate distributed ledger off of the main chain but with

transactions able to take place in the same currency as the core system

 By performing transactions on a such specialized ledger, transactions should be processed faster

 Users who are able to see the content of a transaction, may also be restricted depending on that

sidechain’s implementation

Cybersecurity Challenges

4.1.1 Key Management

The methodology of the attacks seeking to gain unauthorised access to a system via stolen credentials

remains fundamentally the same- try to capture information, plant malware and/or use social engineering

to steal the private keys from the user’s machine

Potentially different private keys could be used for signing and encrypting messages across the distributed

ledger. An attacker who obtained encryption keys to a dataset would be able to read the underlying data.

However, if the signing key is secured, they will not be able to modify the data or interact with that smart

contract (providing it has been appropriately designed).

The significance of protecting the private key is due to the fact that actions taking place on a hacker’s

machine, such as file decryption attempts or private key reproduction, are not subject to server imposed

query limits and are run without anyone else being able to notice

Unlike with traditional systems, where before a server administrator was capable of tracking attempts to

break into a customer or user account, the malicious users can keep trying limitlessly to decrypt or try to

reproduce a private key out of encrypted data from a given ledger. With Blockchain, there is no way of

knowing this is happening until after the hacker has succeeded.

4.1.2 Cryptography

Most Blockchain implementations rely on the cryptographically generated public and private keys to

operate

Usually, the user generates the private and public keys using software, such as the Blockchain client

software, or another available software. It has already been shown, that some programs are generating

keys that have been identified to be weak

weakened random number generators, from which a limited range of possible values can be produced.

Keys generated through these limited random number generators could be more easily brute forced

Popular security algorithms that are used for securing information through a complicated challenge (e.g.

RSA, ElGamal), may now be resolved in a shorter amounts of time through the use of quantum computing.

4.1.3 Privacy

In a permissionless ledger, all counterparties are able to download the ledger, which implies that they

might be able to explore the entire history of transactions, including those to which they were not

members of. The “right to be forgotten” where information needs to be removed from a ledger is

challenging to implement. Usually, many counterparties have the data from the ledger, and it would be

difficult to prove that all data has been deleted

Additionally, there is a challenge with smart contracts being able to access the data in order to process

transactions. Since this is possible, there is possibility that a smart contract might be able to leak

information on what is being processed

4.1.4 Code review

Whilst many skilled eyes may have reviewed the protocols, methods, and codebase of popular

implementations of distributed ledgers, it remains possible that unknown vulnerabilities exist.

The Distributed Ledger Specific Challenges

4.2.1 Consensus hijack

In decentralized, permissionless networks, where consensus is formed through majority, taking control of a

large enough portion of participating clients could allow an attacker to tamper the validation process

In the case of Bitcoin, this is referred to as a “51% attack9” where the majority (defined as the proportion

of all hashing power in the network) is compromised or controlled by the same entity or a coalition of

dishonest counterparties. An attacker would be able to produce new blocks faster than the rest of the

network (in proportion to their computing power) leading participants to consider that chain as valid.

The extent of a 51% attack will allow an attacker to refuse to process certain transactions as well as to

re-use an asset which has already been spen

There is possibility, that in a permissionless distributed ledger, the computational power required to hijack

the consensus might be cheap enough for a malicious attacker to buy (from a cloud provider for example)

Another consequence of such an attack is in the perspective of adoption. Any chain coming under attack

might see an outflow of participants, leading to the question of which chain should be considered as the

“main” one to follow as well as potentially crippling the value of that chain

Another challenge comes from consensus protocols that do not involve some way of penalty to the

participants. In this way for a malicious user would be easier to attack

4.2.2 Sidechains

sidechains are more at risk due to their more

specialised focus. Where a user has no interest in tracking the data and maintaining the operation of a

sidechain, they will not contribute the relevant mining power to secure that chain.

Another vulnerability of sidechains consists in the gateway used to transfer assets and messages between

chains. In the case of a Bitcoin sidechain, a user will “lock” Bitcoins in an address on the main Bitcoin

Blockchain and then issue proxy tokens for these on the sidechain. If users can also later exchange

sidechain tokens for the original token, this mechanism is called a 2-way peg. They can then transact with

others on that sidechain. If the initial “locking” transaction is later considered invalid, then subsequent

proxy-token transactions would also be affected. Additionally, owners of proxy tokens that had been

affected would not be able to convert these back to the original asset via the pegging mechanism

Fraudulent transactions or attacks on a sidechain do not affect the validity of data held on the parent

chain. However, in the event that a sidechain was to be put out of service, the parent chain might be

subjected to high stress levels as the sidechain users migrate their transaction volumes to the parent

chains

4.2.3 Exploiting Permissioned Blockchains

In a regulated, permissioned network, where consensus might be implemented under the regulator’s

direction, any exploitation of the regulator’s capabilities would be even more and immediately severe

All problems that had required hijacking of the majority consensus, a task that was a potentially

significant in undertaking, are now replaced by the hijacking of a single entity

4.2.4 Distributed Denial of Service

Distributed Denial of Service attacks coming out of the nature of the distribute ledger remain a concern.

For example, if rogue wallets decide to push large numbers of spam transactions to the network it could

create potentially a denial of service and increase the processing time, as the nodes will be checking the

validity of the fraudulent transactions.

Within a permissioned ledger, it would be possible for nodes to agree to ignore or even block the issuer of

such spam transactions. However, if an attacker is able to control a large number of clients, they might be

able to severely disrupt the network by pushing large volumes of irrelevant transactions

The distributed nature of Blockchain architecture introduces the prospect that it would be difficult to

shut down a malicious program

It would be possible to

store malicious data within the Blockchain network. Additionally, an attacker could reassign control of the

related smart contract at will, leveraging the trustless nature of the Blockchain to buy and sell malware

between anonymous cryptographic keys

4.2.5 Wallet Management

The wallet software would need to protect the keys from being accessed

without authorization, in both cases while stored, but also while in operation with the software.

Losing access to a given wallet might preclude a financial institution from authorising transactions or

moving assets. It might be difficult for an entity to be aware that a malicious user has access to the wallet,

because copying or stealing the keys might not leave any trace on a computer. By the time an entity

understands that the keys are compromised, because of a fraudulent transaction for example, it might be

too late for reversa

4.2.6 Scalability

Removing the need to reconcile counterparty data introduces a scalability problem. On one hand the

growth of the ledger size and on the other the speed at which transactions are processed.

The need to store all data pertaining to a specific distributed ledger, may grow to be unmanageable in

size for individual end-users

The speed at which a given transaction is processed, in some implementations of the ledger, may not be

sufficient or acceptable

Exposed to the high transaction volumes of financial institutions, a completely distributed ledger might

subject users to performance issues as their machines struggle to maintain an ever growing chain. The

transaction speed also depends on the consensus protocol.

The possibility that only specific transactions are to be verified by specific nodes (validators) is called

Sharding. Sharding could also introduce a significant fault (ie. reversion of subsequent transactions) if a

specific subset of validators were to wrongly validate transactions to which other members of that same

Blockchain refer to

The process of downloading block headers (which are a hashed version of past data) as well as the

underlying data for most recent blocks and then cross-reference this with other nodes (rather than

downloading the entire database) is called Blockchain pruning. Here, a challenge exists if an attacker were

to convince a user that the fraudulent block headers they verify, are genuine

4.2.7 Smart Contract Management

Smart contract management refers to the people, processes and technology used when creating a smart

contract.

Smart contracts are essentially programs that run on the distributed ledger. They are prone to any faults

associated with code

Generally, the function, and the security of smart contracts code depends on the author’s capabilities

4.2.8 Interoperability

Using different distributed ledgers will very likely bring the need of data sharing between them.

Exchanging data will require translation of formats and protocols, which currently are in very early

stages.

Key

challenges related to interoperability are:

 Who can transfer assets between distributed ledgers?

 Who can oppose to transferring assets?

 Should transfers allow for whole asset or just part of it?

 Should changes of ownership or asset (theft, loss) be also proliferated to the other chains?

https://www.enisa.europa.eu/publications/blockchain-security/@@download/fullReport

• Distributed ledgers require maximum protection – even if they appear to be secure by default

Blockchain technology is becoming an integral part of the business process in large companies. In its customized form for enterprises, commonly called Distributed Ledger Technology (DLT), it is used to verify transactions, control deliveries, monitor workplace operations and more.

https://www.kaspersky.com/enterprise-security/dlt-cybersecurity

• Overview nature of the risks and vulnerabilities

Distributed ledger technology (DLT) is a new type of

secure database or ledger that is replicated across

multiple sites, countries, or institutions with no

centralized controller. In essence, this is a new way

of keeping track, securely and reliably, of who owns a

financial, physical, or digital asset. The most popular

incarnation of DLT is called a blockchain, of which a

number of varieties have been developed

https://figi.itu.int/wp-content/uploads/2021/04/Security-Aspects-of-Distributed-Ledger-Technologies-1.pdf