Page 17 - FIGI: Security Aspects of Distributed Ledger Technologies
P. 17
ficient stress testing, often introduce new security DLT ecosystem also offers a rich attack source
challenges. for directly stealing token value from ‘wallets,’ which
Another DLT type gaining in popularity is Directed are often stored in insecure crypto-exchanges or
Acylic Graph (DAG), often termed Blockchain 3.0, online systems that use basic security unrelated to
31
but actually an entirely new technology using a graph the more robust DLT that spawned the tokens. There
data structure that uses a topological ordering, and is also concerns about the longevity of the security
which does not uses blocks or chains. At their core of DLT-based data due to the emergence of ‘quan-
DAGs have the same properties as a blockchain in tum computing’ technologies and apparent ability to
so far as they are still distributed databases based compromise the encryption used in many DLTs.
on a peer-to-peer network and a validation mech- All these security-related issues are detailed fur-
anism for distributed decision making. Examples ther below, with Annex D providing a useful snap-
of the still-evolving DAG technology are the IOTA shot of the taxonomy of prevalent issues.
Tangle and Hedera Hashgraph. IOTA’s Tangle DLT
32
is designed to run Internet of Things (IoT) devices. 4�3 Typical Actors and Components in a Distribut-
It’s been noted that attempts such as the Lightning ed Ledger Environment
Network or Sharding – as well as DAGs - suggest that Typical actors and constituent components in DLT/
scaling can be improved if using the design principle blockchain ecosystems include:
that not all participants – or network nodes – need
to know all the information at all times to keep a DL • Authenticators: Miners – also known as validators,
network in sync. forgers - who provide operational ‘mining’ and
33
There are also ‘privacy’ DLTs,’ such as Monero and validation services;
Zcash and their next evolution such as the BEAM • Developers who program and maintain the core
crypto-currency based on Mimblewimble protocol, DLT protocol; and
or qEDIT for enterprise DLTs. These zero-knowledge- • Operators of a particular DLT
proof DLTs may help solve the governance issues in • Users who own, invest and otherwise use tokens
the trilemma since the private information can still be and engage in activities on the system.
37
governed by centralized licensed entities while the • Oracles as third party data input/output providers.
transactions are on the DLT.
These innovations however prompt further chal- Different levels governance exist for each of these
lenges related to their implementation, including the domains. At the transactional level, miners and
38
nascent (and often not yet properly stress-tested) validators operate the system in exchange for incen-
nature of the technologies used; uncertain legal and tives and govern which blocks are accepted into a
regulatory status; privacy and confidentiality issues; blockchain according to the rules set forth in the
cultural changes in requiring users to have ‘trust’ in system and its consensus mechanism. At the proto-
often anonymous counterparties; implications for col or development level, programmers - who may
lawful interception capabilities as data is not eas- be voluntary and not employees or contractors of a
ily extractable from privacy DLTs; scalability of the centralized organization - contribute and evaluate
DLTs for mainstream use comparable to and exceed- code. At the organizational level is where resource
39
ing existing non-DLTs performing similar functional management and general business operations tradi-
tasks; and the ability to link different DLTs togeth- tionally occur and who may control and govern this
35
34
er, where required. But as discussed later, due to the process varies and can be unclear. 40
36
vast differences in DLT protocols, many DLTs are not Oracles are third party services which are not part
interoperable with others, leading to a balkanization of the blockchain consensus mechanism, and are
of incompatible DLTs. effectively ‘off-chain’ and thus considered insecure
Indeed, it is thought that due to this fragmenta- in relation to the DL itself. The accuracy of data
41
tion, many of the especially more exotic DLT incar- inputs and outputs by oracles are key as it is near
nations may not survive in so far as further devel- impossible to roll back transactions once executed
opment and integration, leading to concerns about on a DL. Oracle types include but are not limited to
42
the data therein. Attempts at interoperability are the following: 4344
underway, but may introduce security risks as the
data to be transferred between DLT may be – in cur- • Software: Provision of data from software driv-
rent attempts - via insecure ‘off-chain’ methods. The en sources (such as apps, web servers) which are
nascent
Security Aspects of Distributed Ledger Technologies 15