Page 159 - ITU-T Focus Group Digital Financial Services – Technology, innovation and competition
P. 159

ITU-T Focus Group Digital Financial Services
                                              Technology, Innovation and Competition



               itself.  Widespread adoption then is essential for the positive network effect of DLTs to be truly harnessed as
                    100
               a single entity using blockchain could be seen as analogous to a centralized database.  Although good and
                                                                                       101
               important work is being done by the various DLT consortia, this may yet lead to silo’ed – and incompatible –
               blockchain initiatives.
                                 102
               So-called ‘forking’ of existing DLTs may also introduce fragmentation and slow down transaction processing
               speeds.  There are a number of classifications of ‘forks,’ which include forks, hard forks, soft forks, software
                      103
               forks, or git forks. 104

               Although the various DLT initiatives may address different market sectors and thus require nuanced design
               and implementation, some level of consistency between at least similar implementations is desirable to avoid
               unnecessary fragmentation that would delay the emergence of industry ‘standards’ for a sector. Besides,
               interoperability required to connect these silos may introduce security and efficiency risks to the respective
               blockchain operations.


               5.5    Validity of records

               Although the data on a blockchain is said to be secure, and any data input authenticated, the DLT does not
               address the reliability or accuracy of the data itself. Blockchain thus only addresses a record’s authenticity
               by confirming the party or parties submitting a record, the time and date of its submission, and the contents
               of the record at the time of submission,  and not the reliability or accuracy of the records contained in the
                                                 105
               blockchain.
               If a document containing false information is hashed – added to the blockchain ‒ as part of a properly formatted
               transaction, the network will and must validate it.  That is, as long as the correct protocols are utilized, the data
                                                       106
               inputted will be accepted by the nodes on a blockchain. This is the DLT incarnation of the unfortunate mantra
               of ‘garbage data in, garbage data out’ which is usually characteristic of some databases in the non-DLT world.
               The possibility has also been raised  of an individual participant on a blockchain showing their users an altered
                                            107
               version of their data whilst simultaneously showing the unedited (genuine) version to the other participant
               nodes on the blockchain network.

               Others may only be able to trust the data on the blockchain if they can cross-validate data across multiple
               user nodes.



               100   Metcalfe's Law says that the value of a network is proportional to the number of connections in the network squared. Shapiro, C
                  and Varian, HR (1999) Information Rules. Similarly, per Paul Makin, the more people who have an identity on blockchain where
                  nodes can attest to the authenticity of the correct people being identified, the more entities will take the trouble to be part of
                  the acceptance network for that blockchain; that is, entities will join that blockchain to make use of the identity functionality it
                  provides.
               101   Credit Suisse (2016) ibid
               102   On the other hand, concentration of use in just one blockchain type could also possibly trigger competition-related issues.
               103   See Section 5.6 below. Upgrading of a blockchain may require multiple consensus steps. For example, to upgrade the blockchain
                  which Bitcoin uses requires a Bitcoin Improvement Proposal (BIP) design document for introducing new features since Bitcoin has
                  no formal structure. See Anceaume, E et al (2016) Safety Analysis of Bitcoin Improvement Proposals, available at https:// goo. gl/
                  MO3JBb .
               104   Although there is no consensus on terminology, the various types of ‘forks’ that are generally possible have been classified by the
                  Bitcoin community into forks, hard forks, soft forks, software fork or git fork. A hard fork, classified as a permanent divergence
                  in the blockchain, commonly occurs when non-upgraded nodes can’t validate blocks created by upgraded nodes that follow
                  newer consensus rules. A fork is a regular fork where all nodes follow the same consensus rules, so the fork is resolved once one
                  chain has more proof of work than another. A soft fork is a temporary divergence in the blockchain caused by non-upgraded
                  nodes not following new consensus rules. A software fork is when one or more developers permanently develops a codebase – a
                  collection of source code – separately from other developers. A git fork is when one or more developers temporarily develop a
                  codebase separately from other developers. See Bitcoin (2016) Hard Fork, Hard-Forking Change, available at https:// bitcoin. org/
                  en/ glossary/ hard- fork. However, other definitions may be used to describe the type of forks. For alternative classifications, and
                  solutions to the identified forks, see Blockchain (2016) A Brief History of Bitcoin Forks, available at https:// goo. gl/ o3XDmk .
               105   These records may in fact be encrypted.
               106   Vermont (2016) ibid
               107   Lewis (2017) ibid



                                                                                                       139
   154   155   156   157   158   159   160   161   162   163   164