Page 18 - FIGI: Security Aspects of Distributed Ledger Technologies

Table 2: Typical participants in a blockchain-based Distributed Ledger and the security aspects of their roles� 46

Type Typical Role in Distributed Ledgers Security Aspects
Inventors First publisher of new DL technology 47 May not provide a method of collegial-
ly updating a DL, leading to multiple
forks.
Developers Independent parties who may improve on the May not agree amongst themselves,
initial DL technology leading to lapses in improvements
Miners/Validators Paid to add new data to blocks Those with 51% mining power may act
to unilaterally change the form and
data structure on a DL
Users Use data or value stored on a DL or exchange May not sufficiently secure their PINs
for wallets and exchanges.
Oracles Provide input/output data for use in SCs Usually insecure and may feed incor-
rect data into a DLT
Centralized Exchanges Exchange tokens, custodians of token creden- ‘Honey pot’ for hackers due to lack
tials/keys, facilitate ICOs, STOs and IEOs security implementations. May not
implement security controls; DDOS
attacks.
Nodes Hold copies of a DL May go offline and thus increase pos-
sibility that a DLT is compromised/
hacked
Auditors May test smart contracts for coding errors Could catch and fix vulnerabilities
and/or legal validity before exploitation
DLT Network Operators Define, create, manage and monitor a DLT May not implement security controls;
network. Each business in the network has a DDOS attacks.
blockchain operator. 48

typically available online, such as from a standard 4�4 Processing Costs of Distributed Applications
API from an information service provider. and Risk Components
• Hardware: Data resulting from the physical world, To execute transactions – such as smart contracts
such as tracking a package in the mail or an item – on a public blockchain, payment must be made
as a result of an RFID scan, which may use Trusted to those undertaking computing processes to add
Execution Environments (TEE) – reporting read- ‘blocks’ to the blockchain. An incentive for doing so
ings of hardware without compromising on data is required. In the case of the Ethereum blockchain
49
security. 45 – specifically its core Ethereum It’s worth mention-
• Incoming/Inbound: Provision of data inbound ing that in April the ETH mainnet got sooooo loaded
from an external source. that the gas required to write a block soared to ~230
• Outgoing: Sends outgoing messages or signals ETH (!), that is a major problem…since the more load
to an external source as a result of what occurs on an infra, the higher is the block cost, thus limiting
on the blockchain network, e.g. a locker may be throughput and lowering the usage. This is actually
opened after payment of Ether is confirmed on a game theory restriction that by-design keeps the
the Ethereum network. usage of the infra low (!) Virtual Machine (EVM) – the
• Consensus/Decentralized Oracles: A decentral- cost of this incentive to miners to add the blocks is
ized system which queries multiple oracle sourc- called ‘gas.’ The more complex the transaction steps
50
es with a consensus mechanism used to reach an to be performed, usually the higher the ‘gas’ fee.
52
51
acceptable outcome. While a decentralized oracle DDOS attacks on a DLT though can ‘scramble’ the
model could be used (see below), its feasibility block additions, requiring owners to expend ‘gas‘
53
may be challenged by (i) the need for a standard- fees on reverting the DLT to the same state pre the
ized data format across each oracle; and (ii) result DDOS attack. 54
in substantial additional fee costs to the providers As this can be infinite time - because of the ‘Tur-
of each oracle and data source. (But see solutions ing Complete’ nature of Ethereum - so and use up
55
providers below.) unlimited computational power, the developers of

16 Security Aspects of Distributed Ledger Technologies