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
   12   13   14   15   16   17   18   19   20   21   22