Page 149 - ITU-T Focus Group Digital Financial Services – Technology, innovation and competition

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

If the process is open to everyone ‒ such as with Bitcoin ‒ then the ledger is said to be ‘permissionless’, and
19
the DLT has no owner. If participants in that process are preselected, the ledger is said to be ‘permissioned.’
20
These may also be public or private.
21
1.3.2 Permissionless shared ledgers

In permissionless (public) ledgers such as Bitcoin, all participants – the nodes ‒ maintain the integrity of the
22
ledger by reaching a consensus about its state. These public decentralized ledgers are accessible to every
23
Internet user. This allows anyone to contribute data to the ledger and for everyone in possession of the ledger
to have identical copies, so that – theoretically ‒ no one actor can prevent a transaction from being added
to the ledger.
24
The public design goal ostensibly then is to avoid censorship (by a central authority), remove counterparty
exposure, and allow open, global membership. There is, however, an overarching issue of whether the correct
blocks are being added to the blockchain, possibly through competing proof of work (POW) or proof of stake
(POS) as the case may be. These competing blocks may arise because of fraud or because of latencies in
updating the entire blockchain across all distributed nodes, such that transactions can theoretically arrive in
a different order at different nodes.

This situation may then, at least for a temporary period, create what is known as a ‘fork’ in the blockchain.
This, in turn, creates one or more ‘subchains’ which may (all) exist at least until the entire blockchain assesses
the competing claims and decides which block addition (subchain) is correct and should be added to the
blockchain. Resolving these conflicts may take time.

This makes blockchains, at least for the present state of the art, possibly unsuitable for real-time transactions. 25

19 Some would argue that in practice Bitcoin is basically a closed network today since the only entity that validates a transaction is
effectively 1 in 20 semi-static pools. Further, the miners within those pools almost never individually generate the appropriate/
winning ‘hash’ towards finding a block. Rather, they each generate trillions of invalid hashes each week and are rewarded with
shares of a reward as the reward comes in.
20 Distinctions between permissioned and permissionless described here reflect the current state of the art. As DLTs mature, many
believe that there will be a full spectrum between permissioned and permissionless.
21 Public blockchains are said to be fully decentralized.
22 Bitcoin is not issued by a central authority and thus cannot be controlled, which from the reaction to Bitcoin by regulators around
the world, appears to pose policy challenges.
23 Validating nodes are different than mining nodes. Mining nodes can prevent ‘double spending,’ as well as what are called ‘Sybil’
attacks, named after the case study of a woman with multiple personality disorder. A Sybil attack then is a type of security threat
when a node in a peer-to-peer network (such as a blockchain) claims multiple identities. Most networks rely on assumptions
of identity, where each computer represents one identity. Fully validating nodes on a blockchain that anyone can run cannot
prevent Sybil attacks or double-spending. On Sybil attacks, see Douceur, J (2002) The Sybil Attack, available at https:// goo. gl/
KG4aWY. On its effect on DLTs, see Swanson, T (2015) Consensus-As-A-Service: A Brief Report on the Emergence of Permissioned,
Distributed Ledger Systems, available at https:// goo. gl/ 6tc1Y2 .
24 The public design goal ostensibly then is to avoid censorship (by a central authority), remove counterparty exposure, and
allow open, global membership. As proffered by BitFury and Wattenhofer, applying Consistency, Availability and Partition
(CAP)-tolerance theorem for distributed computation systems, DLTs are available so that every request receives a response, and
partition-tolerant in that the DLTs still perform, even if some nodes fail, but are not consistent. That, is a distributed system can
satisfy any two of these guarantees at the same time, but not all three. While the CAP theorem is subject to some debate in
between computer scientists, in all, this may create an overarching issue of whether the correct blocks are being added to the
blockchain, possibly through competing POWs or POSs, as the case may be. These competing blocks then, may arise because of
fraud or because latencies in updating the entire blockchain across all distributed nodes such that transactions can theoretically
arrive in a different order at different nodes. This situation may then, at least for a temporary period, create what is known as
a ‘fork’ in the blockchain. This, in turn, creates one or more ‘subchains’ which may (all) exist at least until the entire blockchain
assesses the competing claims and decides which block addition (subchain) is correct and should be added to the blockchain.
Resolving these conflicts may take time. This, in some thinking, makes blockchains, at least for the present state of the art, possi-
bly unsuitable for real-time transactions. See Bitfury (2015) ibid; Roger Wattenhofer (2013) Weak Consistency: Part 2, Chapter 3.
25 de Meijer, CRW (2016) Blockchain, Distributed and Shared Ledger, Permissionless and Permissioned: What's in a Name!!, avail-
able at https:// goo. gl/ VrhGev .

129