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