Embed Size (px)
Citation preview
© UZH 2019
Bruno Rodrigues, Eder Scheid, Burkhard StillerCommunication Systems Group CSG
Department of Informatics IfIUniversity of Zürich UZH, Switzerland
[rodrigues¦scheid¦stiller]@ifi.uzh.ch
IFIP/IEEE IM 2019 Tutorial, Washington, U.S.A., April 12, 2019
Information Management in the
Blockchain Era:
Challenges and Opportunities
© UZH 2019
Schedule
Part I – Blockchain Basics
9.00 – Basic Concepts
9.30 – Bitcoin, Ethereum, and Smart Contracts
Break
10.00
Part II – Information Management
10.15 – Management Aspects
10.45 – Challenges
11.15 – Discussion and Evaluation
12.00 End
2
© UZH 2019
Basic Concepts
© UZH 2019
Blockchain 1.0
4
Digital Currency
– Decentralized payment system
– Bitcoin as the father of digital currencies
• Still, not much awareness of (other) Blockchain capabilities
– Proof-of-Work (PoW)
2008
Bitcoin (BTC)
Whitepaper
Jan. 2009
BTC Genesis Block
May 2010Oct. 2009
‘‘BTC Network’’ goes live.
FX exchange for BTCs
Feb 2011
1 BTC = 1 USD
Nov. 2010 2011-2012 Jun 2012
Ripple is launched focusing
Banking systems integration
Sep 2012
Bitcoin Foundation
Mar 2013
Non-existent
Public Perception
Initial stage
BTC Market Cap
reaches 1M USD
BTC Market Cap
reaches 1B USD
Central stage
Digital wallets gain
popularity
Bitcoin forks (Litecoin,
Dodgecoin, etc)«Experimental» stage Discovery of
cryptocurrencies
Two slices of Pizza for
10’000 BTC
© UZH 2019
Blockchain 2.0
5
Dec 2013 Jan 2014 Jul 2014Feb 2014
Smart Contracts
– Ethereum unlocks the blockchain potential beyond
cryptocurrencies
– Blockchain is able to run computer programs in a transparent
and verifiable manner
2015 2015
Ethereum goes
live (Frontier) in
July.
Hyperledger is
released in
December.
Mar 2016 Jun 2016 Sep 2016
Public Perception
Ethereum is
announced
by Vitalik B.
Growth of Blockchain
crypto start-ups
«Blockchain can be used
beyond cryptocurrencies»
Continuous increase on the number of
cryptocurrencies
«Blockchain is definitely positive!»
Ethereum project is
launched. Investors
start to recognize
Ethereum’s potential
Investors joins Digital
Asset Holdings, which
represents Wall
Street’s embrace of
Blockchain. NASDAQ
also commits to
Blockchain
Attacks on
exchanges
makes MT.GOX
to collapse
DAO
(Decentralized
Autonomous
Organizatio) is
hacked, losses
estimated in
50M USD.
Workshop
Blockchain on
Healthcare
Awareness for vulnerabilities in
Smart Contracts
Ethereum goes
in production
(Homestead).
«Avoiding the pointless BC project»
Blockchain
Interoperability
V. Buterin
© UZH 2019
Blockchain 3.0
6
Decentralized Applications (DApps)
– Production stage:
• Large number of applications
– Scalability/Performance issues:
• Need for performance new consensus protocols
• Need for storage off-chain storage tools
2016 2017
Blockchain
in the
Supply-
chain
2017
Partnership
IBM &
Maersk
Supply-
chain
2017
Estonia uses
Blockchain
for
Governmen
tal Services
2017
ETH Market
Cap reaches
5B USD
2017
1 BTC =
17’900 USD
2017
Blockchain
Identity
2015~2017
Blockchain
IoT
Growing as of today
Public Perception
Switzerland
accepts tax
payments in
BTC!
2018
«Let’s decentralize
the world!»
BTC breaks
1’000 USD
BTC Bubble
Excessive number of
applications
© UZH 2019
Blockchain 4.0
7
Ecosystem and Industry Integration
– Making blockchain effective in industry
– Decentralized and disconnected blockchain networks
• Vendor-specific blockchain technology, interoperable chains
– Need for standardization
As of today
© UZH 2019
The Blockchain Evolution
8
The different “eras” are running in parallel
There are more than 2000 cryptocurrencies available
as of today.
– And the list is still growing
Countless Blockchain projects in many areas (supply-
chain, health-care, governmental, identity, cross-chain
interoperability, etc).
• Digital Currency
• Blockchain
• Proof-of-Work1.0
• Smart Contracts
• Virtual Machine
• PoS, DPoS, PBFT, PoA, PoT, PoB
2.0• Decentralized Applications
• Beyond FinTech
• Friendly Web Interfaces
3.0 • Industry Integration
• Cross-chain interoperability
4.0
© UZH 2019
Driving Questions
How and under which conditions to use blockchain?
– Creator or investor point-of-view
Is there a right or wrong? A roadmap
for blockchain usage, possibly.
– There is no simple answer …
Developer/
Creator
Investor
"What are application
requirements?"
"Which different types of
blockchain one can offer?"
Performance
Security
Scalability
9
© UZH 2019
Blockchain (BC) Basics
© UZH 2019
→ Distributed Ledger
Databases and Distributed Ledgers
11
Databases (DB)
– Access control for users and the “SysAdmin” (trusted root)
• Centralized, physical, and trusted servers are maintained
→ Potentially central point of failure, loss, or misuse
Distributed databases
– Every copy runs on a trusted node
Can data be stored fully decentralized and
handled reliably between non-trusted stakeholders?
– Unstructured/structured data stored across the world by anyone
– Access control by “all” w/o a central root
– No central point, redundant copies,
non-trusted participants, detectable misuse
© UZH 2019
Comparison to Traditional DBs
12
Properties Blockchain Traditional DBs
Operations Insert, Read Insert, Read, Delete,
Update
Replication Full replication Master-slave
Consensus Majority of peers agree on
an outcome of
transactions
Distributed transactions
Invariants Any peer can validate
transactions
Operations
Characteristic Advantage
Disintermediation Blockchain
Performance Traditional Databases
Reliability/Integrity Blockchain
Confidentiality Traditional Databases
Characteristics
© UZH 2019
Definition
A Blockchain (BC) or Distributed Ledger (DL) is a
decentralized and public digital ledger that
transparently and permanently record blocks of
transactions across computers based on a consensus
algorithm without modifying the subsequent blocks.
13
The genesis or the first
block define the settings of
the blockchain
A blockchain is similar to a
linked list except that Blocks
are added according to a
consensus protocol
© UZH 2019
Permissions and Transparency
14
PrivatePrivate read
Permissioned
Permissionless
Public read
Please, use a
traditional database!Supply-chain
E-government
IdentityCryptocurrencies
© UZH 2019
Key Ingredients (1)
15
Public key cryptography and hashes
– Asymmetric approach for arbitrary users
• Ensures validation and authentication
Internet
– Communications infrastructure for everyone
– Distributed system with arbitrary users and devices (nodes)
• Peer-to-peer (Overlay Network) communication paradigms
• Storage capabilities for medium-sized data volumes
• Supports authorization
Incentives
– Protocol to enable communications, supporting rewards for
participants’ tasks performed within overlay network
• Ensures participation
© UZH 2019
Key Ingredients (2)
16
SHA-256
“The quick brown fox did some crypto”
410312395834291203…
SHA-256
“The quick brown Fox did some crypto”
983249120432492340…
Based on Terence Spies:
Blockchain Mechanics
Cryptography determines the basis for BCs
– Many bad intuitions about what this can or cannot do arise
Hashes in detail
– A hash function (like SHA-256) takes a block of data in and
produces an effectively random fixed size integer
– Any change to the input randomizes it
• “Simple” input changes, e.g., one char, lead to “dramatic” result changes
© UZH 2019
Block
A block is a structure to store data (transactions)
– Header: information to identify the block.
– Data: set of stored transactions
17
The block hash is the identifier of all
transactions in the block AND the block
header
© UZH 2019
In practice, the Merkle Tree guarantees immutability
Merkle Tree
18
Imagine if one wants to remove/change a
transaction
The Merkle Root
will be different
resulting in a
different Block
Hash
Then, a parallel (forked)
chain is created
© UZH 2019
Transactions
19
Alice Bob
A transaction is not stored in
the blockchain straight away
Transaction pool (or mempool)
How are transactions stored in a block?
– Transaction pool or mempool
• Temporary storage structure (RAM) available on each full node
(Ethereum)
Each full node is connected to
this transaction pool, especially
minersEve Dave
Miners
Miner’s work is to gather
transactions from the
transaction pool in to a
“candidate block”
Eve and Dave needs to find a hash below the
target difficulty to create a new block
© UZH 2019
Blockchain Consensus
“Consensus is the process of agreeing on
one result among a group of participants”
© UZH 2019
Overview
21
Figure
1
2
3
4
© UZH 2019
Classic
Classical Consensus Models Crash failure models honest nodes failing
Byzantine failure model able to tolerate a portion of
malicious nodes
22
© UZH 2019
Byzantine Fault Tolerance (BFT)
23
Described as the capacity of a system to handle or
survive unreliable situations and (all kinds of) failures
Practical BFT (PBFT): assume a small fraction of
nodes as Byzantines (dishonest)
Other examples: XFT, HoneyBadger
1. A client sends a request to
invoke a service
2. The primary leader multicasts
the requests to the replicas
3. Replicas execute the request
and send a reply to the client
4. The client wats for F+1 replies
from different replicas with the
same result
PBFT property:
3 phase protocol
© UZH 2019
Elected Leader
Elected Leader Probabilistic elected leader in a lottery-like, competition or
probabilistic algorithm
24
© UZH 2019
Proof-of-Work (PoW)
25
Set of transactions becomes available, block is
created, by utilizing the following data
– Transaction(s), hash of previous block
– Nonce (arbitrary number, can only be used once)
– Other information (depending on BC)
Hash of new block is calculated
Checking performed once hash was computed
– Hash is above the target value → Another miner may have
found a suitable hash, block attached to local BC, but miner
lost the lottery, otherwise nonce will be incremented, retry
– Hash is below the target value → This miner won the lottery
and the new block’s hash determines the PoW result
© UZH 2019
Hash-based PoW (1)
26
Key: One cannot compute an input from an output
– To find a hash with N zeros at input start, requires 2*N
computations, which proves computational work performed
– Hashing an incrementing “nonce” as hash input, leads to zeros
Distributed game sets the difficulty N of the game
Players accumulate points by creating blocks
– Hashing the previous block, finding a hash of the new block
with enough zeros, and transmitting this block to everyone
in 3e-05 seconds, nonce = 0 yielded 0 zeros. value = 4c8f1205f49e70248939df9c7b704ace62c2245aba9e81641edf…
in 0.000138 seconds, nonce = 12 yielded 1 zeros. value = 05017256be77ad2985b36e75e486af325a620a9f29c54…
in 0.000482 seconds, nonce = 112 yielded 2 zeros. value = 00ae7e0956382f55567d0ed9311cfd41dd2cf5f0a7137…
in 0.014505 seconds, nonce = 3728 yielded 3 zeros. value = 000b5a6cfc0f076cd81ed3a60682063887cf055e47b…
in 0.595024 seconds, nonce = 181747 yielded 4 zeros. value = 0000af058b74703b55e27437b89b1ebcc46f45ce55d6….
in 3.491151 seconds, nonce = 1037701 yielded 5 zeros. value = 00000e55bd0d2027f3024c378e0cc511548c94fbeed0e….
in 32.006105 seconds, nonce = 9913520 yielded 6 zeros. value = 00000077a77854ee39dc0dc996dea72dad8852afbde6….
in 590.89462 seconds, nonce = 186867248 yielded 7 zeros. value = 0000000225060b16117b23dbea9ce6be86ac439d….
in 4686.171007 seconds, nonce = 1424462909 yielded 8 zeros. value = 000000002dd743724609a9f57260e2492908d….
© UZH 2019
Blocks are “mined” according to the amount of “tokens”
he or she holds
– The higher is the number of tokens (coins) at stake, the
higher is the “mining power”
– Nodes gets the block reward as incentive
Proof-of-Stake – PoS (1)
27
A
B
C
D
E
F
G
H
A H H H F ...
A mine block
H mine block
# Tokens
A, H high
B, C, G medium
D, E, F low
blo
ckchain
F mine block
© UZH 2019
Nothing at stake issue:
– Creating forks is “costless” when
someone is not burning an external
resource (e.g., mining power), PoS
alone is “unworkable”
Proof-of-Stake – PoS (2)
28
© UZH 2019
PoA is a modified form of PoS where instead of stake
a validator’s identity performs the role of stake
Authorities (nodes) are allowed to create news blocks
– Clique (practical implementation) of PoA
• Requires N/2+1 (more than 50%) of signers to be honest
• Authorities sign new blocks in a Round-robin (RR) fashion
Proof-of-Authority (PoA)
29
A
B
C
D
E
F
G
H
A D E H A ...
A, D, E, H are authorities
A sign block
D sign block
E sign block
H sign block
blo
ckchain
RR Turn
© UZH 2019
Hybrid Consensus Models Using a single consensus has many limitations
Combine different consensus mechanisms
e.g., Supply-chain e.g., Cryptocurrency
Ethereum EthereumA
B
D
G
E
F
PoA PoW
Hybrid Consensus
30
Hybrid
SingleC
© UZH 2019
HyperLedger
Hybrid Sharding
Hybrid Sharding System can be organized into shards (communities)
Cross-chain communications
31
Ethereum EthereumPoA PoW
Community A Community B
PBFT
Community C
A
B
D
C
G
E
F
H
Cross-chain
Communication
© UZH 2019
Summary of Key Characteristics
Permissions (write/read)
– Fully: everyone in the world can participate (W/R)
– Partially: selected public can participate (W/R)
Transparency
– Fully: all members access the history of transactions
– Partially: some members access the history of transactions
• Better a traditional DB.
Permanent storage, i.e., immutability
– Transactions cannot be removed
Level of decentralization
– Fully: consensus with elected leader
– Partially: consensus with selected leader(s)32
© UZH 2019
Blockchain Projects
© UZH 2019 34
CSG‘s Coinblesk Application
Real-time bitcoin payments (Android app)
– Use case: merchant/customer and
person/person with online Bitcoin payments
– Transaction time < 1 s (multi-sig, registered)
• Device build-in NFC and Bluetooth LE
– Merchant with regular trade-back to US$
(decreasing BTC volatility)
• Refund transaction for service disruptions
– Successful field tests at UZH cafeterias
• Started in 2014, presented in 2016 at CeBIT in Hannover, Germany
– Add work on reduction of transaction fees, adding clearing
Discontinued: https://play.google.com/store/apps/details?id=com.coinblesk.client&hl=en
© UZH 2019
CSG‘s SC-based Contracting
Applications
IoT-based pollution monitoring
– Blockchain-based automated measuring, storing, and
monitoring via sensors via the Ethereum Light Client
• SCs used since 2017 to define pollution thresholds
based on international specs
– CO, CO2, ph, turbidity
– Employs IoT protocols LoRaWAN (TTN)
• Reduced power consumption, range to 200 km
Flexible, light weight trading contracts
– Ethereum Light and Full Client applicable
– SCs used (since 2017) to set/get information
• Deposits, traded objects, contract parties’ ID
• Enhanced user privacy35
© UZH 2019
Further CSG BC Projects
– Blockchains for Coldchains (KTI Project) – running
– Smart Cow Paddock Journal – 2016/17
• Blockchain-based “Direktzahlungen”
– BLW: Foodchain Project – running
– Cryptocurrency Bazo from Scratch – running
• Proof-of-Stake, mobile light client, blockchain-based loyalty program
– Collaborative DDoS Mitigation Based on Blockchains – running
• Reputation and reward mechanisms
– Blockchain-based E-Voting – running
• Privacy, verifiability, and auditability
– Automated SLA Compensation
• SLAs described in Smart Contracts, faster/automated payments
– Steady support of startups: modum.io, sciencematters,
ICOnator36
© UZH 2019
Bitcoin
© UZH 2019
Bitcoin Characteristics (1)
Bitcoins are an experimental digital currency
– Bitcoin is fully peer-2-peer (no central entity)
– 1st Bitcoin issued on January 3, 2009
– Smallest unit: 0.00000001 BTC = 1 satoshi
Key characteristics
– Maximum of 21 million BTC
– Every transaction broadcast to all peers
• Every peers knows all transactions (~200 GByte as of today)
– Validation by proof-of-work (partial hash collision)
• Difficult to fake proof-of-work
• No double-spending
The initiator/inventor/developer is unknown so far38
© UZH 2019
Bitcoin Characteristics (2)
Not relying on trust, but on strong cryptography
Weak anonymity (pseudonimity)
– All peers know all transactions
– Clustering: e.g., if a transaction has multiple input addresses,
assume those addresses belong to the same wallet.
Not controlled by a single entity
– Development community, no central bank – Bitcoin Core’s
SegWit vs. BTU (Bitcoin Unlimited)
Creation of Bitcoins: reward for validation (partial hash
collision SHA-256) of payments
Bitcoins can be exchanged for real currencies
– Several companies allow to exchange BTC for Dollar, Euro39
© UZH 2019
Ethereum
© UZH 2019
Ethereum Characteristics (1)
Ethereum is a general purpose blockchain
– Support the execution of complex Smart Contracts (SC)
– Empowered the blockchain beyond financial applications
An Ethereum Virtual Machine (EVM) processes and
executes smart contracts.
– Abstraction layer: the EVM connects requests (transactions)
to and from the network
– SC operations requires Gas
• Mathematical operations, write data
• Table of EVM OP costs Hardware
EVM
ContractsCompile &
execute
Generate
bytecode
41
© UZH 2019
Ethereum Characteristics (2)
Ethereum uses the account-based model
– Keeps track of balance as a global state
• Balance should be larger or equal than spending amount
– Simpler than Bitcoin’s UTXO
Bitcoin:
• Balance is checked by summing up the amount of bills
(UTXO) in the wallet.
• When one wants to spend money, it is possible to use
one or more bills (UTXOs)
Ethereum:
• Simples
• Like a debit card, possible to spend while there is balance
42
© UZH 2019
An Ethereum node is a device/program that
communicates with the Ethereum network
– Nodes are known as clients e.g., Parity, Geth
Full node:
– EVM, verify transactions, execute operations, etc
– Archive nodes:
• Full nodes that preserve the whole blockchain history
Light node:
– Rely on a full node
– Do not verify transactions nor hold a copy of current
blockchain state
Ethereum Types of Nodes
geth
43
© UZH 2019
A transaction T is a single cryptographically-signed
instruction constructed by an actor externally to the
scope of Ethereum:
– nonce: keep track of the total number of transactions that
account has executed
– gasPrice: price per unit of gas
– gasLimit: maximum gas
– to: target address
– value: total of Ethers to send
– data: “Hello World”
Ethereum Transactions
44
© UZH 2019
EVM is a security-oriented virtual machine, designed to
permit untrusted code to be executed by a global
network of computers.
– Every computational step must be paid for up front, thereby
preventing Denial-of-Service attacks.
– Programs may only interact with each other by transmitting a
single arbitrary-length byte array.
– Program execution is sandboxed.
– Program execution is fully deterministic and produces
identical state transitions for any conforming implementation
beginning in an identical state.
Ethereum Virtual Machine
45
© UZH 2019
Smart Contracts (SC)
46
A SC is a piece of self-executing and self-enforcing
software.
tx: deploy contract
SC Address
‘‘0x950041c1599529a9f64cf2be59ffb...’’
ID
geth
© UZH 2019
Other Blockchain Projects
© UZH 2019
Account-based
Public
Market Cap. of 2.2 billion USD (March ‘19)
No Turing-complete SCs
Stellar Consensus Protocol (SCP) [1]
– Each validator list trusted validators → quorum slice
– Quorum slices overlap to form consensus
– Block time of 5 seconds
– Safety over Liveness
• Blockchain progress is halted until consensus is reached
Stellar
48
[1] https://pdfs.semanticscholar.org/3985/6a57fa0c6e7d646b7db88f48f17688693fe4.pdf
© UZH 2019
EOS
49
Account-based
Public
Market Cap. of 3+ billion USD (March ‘19)
Turing-complete SCs
Delegated Proof-of-Stake (dPoS)
– No fees for users
– 21 allowed block producers → centralization
– EOS holders vote for block producers
– EOS tokens for votes → buying votes [1]
– Block time of 500 ms
[1] https://www.newsbtc.com/2018/12/04/eos-centralization-woes-return-as-block-producer-offers-money-for-votes/
© UZH 2019
IOTA
50
Not a blockchain
Public Distributed Ledger
Market Cap. of 800+ million USD (March ‘19)
No support for SCs
IOTA Tangle → Directed Acyclic Graph (DAG)
– No fees for users
– Each new transaction verifies two previous transactions
– Block time of 60 seconds
– Single coordinator (IOTA Foundation) → Centralization
Blockchain
© UZH 2019
HyperLedger
51
No currency
Private
Umbrella Project
– Fabric: Platform for building blockchain-based products
– Composer: tools to build, test, and operate a blockchain
– Cello: allows Blockchain-as-a-Service (BaaS)
– Explorer: dashboard for blockchain monitoring
– Burrow: Ethereum Smart Contracts execution
– Sawtooth: modular enterprise-level blockchain
– Caliper: blockchain benchmarking tool
© UZH 2019
HyperLedger – Sawtooth
52
Intel endorsed project
Turing-complete SCs (chaincode)
Proof-of-Elapsed Time (PoET)
– Random selection of block creators
– Each creator waits n random period of time
– Intels Software Guard Extensions (SGX) isolation
– Permission to participate → Already trusted?
– Block time of ~20 seconds
© UZH 2019
Multichain
53
Open-source platform
UTXO based
Private or Public Deployment
Building Bitcoin-like blockchains
PoW or PoA consensus
– Customizable:
• Block time, e.g., 15 seconds
• Incentives, i.e., block reward
• Permissions to mine new blocks
• Block size
• Other parameters
© UZH 2019
Comparison
Blockchain Type Consensus Blocktime (seconds)
Bitcoin Public PoW 600
Ethereum Public PoW 15
Stellar Public SCP 5
EOS Public dPoS 0.5
IOTA Public IOTA 60
HyperLedger Private PoET 20
Multichain Private PoA 15
54
© UZH 2019
Thank You for Your Attention!
Questions?
55
15 min Break
© UZH 2019
Blockchain Management Aspects
© UZH 2019
Choosing a Blockchain
Not a trivial task– Over 2000 Cryptocurrencies available [1]
Myriad of Facets/Parameters– Marketcap
• Value to buy all shares at today’s market value
– Community involvement
• Telegram chats, discussion channels
– Full Node / Miners Geolocation
• Politics, possibility of centralization
– Technical concerns
• Transactions per second, implementation language, design choices
– Security
• Hashing algorithm, possible attack vectors [1] https://coinmarketcap.com/
57
© UZH 2019
Deployment Models
58
Public
Private
Permissioned
Permissionless
© UZH 2019
G. Greenspan (2015)
59
Key Points When to use BC Traditional DBs
Database Shared Centralized, Shared
Multiple writers Multiple writers Single or multiple
Absense of trust Database with multiple
non-trusting writers
Trust
Disintermediation No trusted intermediaries Trusted intermediary
Transaction interaction There is a dependency
between transactions
Trust the intermediary to
mediate interactions
Set the rules Clear rules applied to all
writers
Different rules based on
roles/groups of writers
*Pick your validators Trust in the validation scheme (single entity or
democratic)
*Back your assets Translation of digital assets into the real world
*Recommendations
© UZH 2019 60
Based on
K. Wüst, A. Gervais
K. Wüst, A. Gervais (2018)
© UZH 2019
K. Wüst, A. Gervais (2018) – Cont.
61
Performance and scalability requirements impacts of
alternative BC solutions and data bases in comparison
BFT: Byzantine Fault Tolerance
PBFT: Practical Byzantine Fault Tolerance
© UZH 2019
Application Trade-offs
62
Based on Blockchain characteristics:
– Distributed vs centralized control
• No central authority (PoW) or trusted nodes (PBFT)
– Performance vs Reliability
• BC offers slow throughput but more robustness than traditional DBs
– Privacy vs Transparency
• More transparency (trust) and less confidentiality
Limited storage
Unknown regulations
– Different countries, different regulations
Lack of standards
– Blockchain 4.0 target
© UZH 2019
Distributed vs. Centralized Control
Distributed control based on elected leader (e.g., PoW)
Partially based on selected leaders (e.g., PoA, PBFT)
Centralized Control based on trust (e.g., traditional
databases)
Multiple possibilities
– At the same time...
63
© UZH 2019
Reliability x Performance
Analysis case-by-case
64
© UZH 2019
Transparency vs. Privacy
Analysis case-by-case
– *Possible to store only checksums of information (integrity)
65
© UZH 2019
Mapping Tradeoffs to Blockchain Types
66
Public
PermissionlessPublic Permissioned
Private
Permissionless
Private
Permissioned
Tra
ns
pa
ren
cy
World
visibility
World
visibilityCommunity visibility Role-based visibility
Co
ntr
ol
Distributed due to the
election process
Distributed but
validators are defined
in a selection
process
Distributed but
validators are defined
in a selection
process
Centralized based on
trusted nodes
Reli
ab
ilit
y
Full replication (light
nodes always rely on
full nodes)
Full or partial
replication (possible
to define super nodes)
Full or partial
replication
(possible to define
super nodes)
Full or partial
replication (master-
slave)
Pe
rfo
rma
nc
e
Slow due the
consensus and
replication models
Intermediate
depending on
consensus and
replication models
Intermediate
depending on
consensus and
replication models
Fast because its
mostly centrally
managed
© UZH 2019
Challenges for Blockchain
Information Management
© UZH 2019
Overview of Key Dimensions
Scalability
Data Storage
Sustainability
Identity Management
Standardization
Trust
Economics and Regulations
68
© UZH 2019
Scalability
Scalability: BC throughput as a number of transactions per second and volume of data persisted in Mega (?) byte– E.g., BC sizes grow faster than the density of HDDs/SSDs
Block time directly linked to blockchain size– Bitcoin block time of 10 min → 200 GB size (March 2019)
– Ethereum block time of 14~15 s → 2 TB size (March 2019)
Possible Solution– Light clients → Block pruning and full block retrieval
– Full nodes still required!
69
© UZH 2019
Data Storage
Data in a transaction is limited
Possible Solution– Off-chain storage, e.g., IPFS
– Hashing of data, e.g., SHA-256
– Smart Contracts (still limited and costly)
Blokchain Maximum String Size in TX
Bitcoin 80 Byte
Ethereum 46 kByte
Stellar 28 Byte
EOS 256 Byte
IOTA 1300 Byte
HyperLedger 20 Byte
Multichain 80 Byte
70
© UZH 2019
Sustainability
Sustainability: Energy efficiency of consensus
mechanisms– Energy consumption for Bitcoin BC alone in 2019 ≈ Portugal
production
Proof-of-Work (PoW) do not produce social “beneficial”
output
Possible Solution
– Different Consensus Mechanisms
– Proof-of-Useful-Work
71
https://digiconomist.net/bitcoin-energy-consumption
© UZH 2019
Identity Management
Identity management and anonymity Data in public blockchains is visible to anyone Addresses are pseudo-anonymous
– Can be linked (with some effort) to physical persons or
companies
Possible Solution– Create new addresses for every new transactions
– Still pseudo-anonymous but harder to link!
– Use a private blockchain with know stakeholders
72
© UZH 2019
Standardization
Standardized APIs for switching BCs for BC applications– E.g., in contrast, databases from different vendors offer
“similar” APIs
Possible Solution– Interoperability
• Notary: single entity enabling the communication between blockchains
• Sidechain: parallel external blockchain
• Hash locking: lock transactions in both blockchains, release at the
same time
– Standards creation
• Consensus between implementations
73
© UZH 2019
Trust
Immutability of the data– Once included in a block, data cannot be changed
– E.g., verified transactions cannot be forged
Thus, blockchain → Trusted environment However, input data → Still untrusted
Possible Solution– Hardware isolation (Intel SGX)
– Physical Protection of sensors (IoT)
– Decentralized monitoring?
– No definitive solution at the moment
74
© UZH 2019
Economics and Regulations
Many economic effects of BC-based cryptocurrencies
unknown– Role of national “e”-currency for society, market of miners or
tokens
– Role, interrelationships of about 1600 cryptocurrencies
Legal & regulative aspects, societal & governmental acceptance
European GDPR (General Data Protection Guideline)– Requires option on data deletion → not possible in BCs
Possible Solution– Legal discussion
– Laws (?) and exceptions
75
© UZH 2019
Mapping Challenges (1)
Public
Permissionless
Public
Permissioned
Private
Permissionless
Private
Permissioned
Scalability
Public usage → size
growth hard to be
controlled
Only selected nodes
create blocks → more
control over size
Blockchain designed for
specific use case →
controlled size
Blockchain designed
for specific use case
→ controlled size
Data Storage
Not designed as DB
→ High fees, size is
limited
Know writers → No
fees, no size limit
Know participants →
Low fees, partial size
limit
Know writers → No
fees, no size limit
Sustainability
PoW →
computational power
has no “social
benefit”
PoA → Sustainable,
no significant
computations
PoS → Sustainable,
no significant
computations
PoA → Sustainable,
no significant
computations
Identity
Management
Pseudo-anonymity,
data visible → Hard to
link to physical user,
data encryption
Data is supposed to
be visible →
Ensuring integrity
Know participants →
Trusted environment
Know participants →
Trusted environment
76
© UZH 2019
Mapping Challenges (2)
Public
Permissionless
Public
Permissioned
Private
Permissionless
Private
Permissioned
Standardization
No standard →
Complex
Interoperability
No standard →
Complex
Interoperability
No standard →
Complex
Interoperability
No standard →
Complex
Interoperability
Trust
Data in the BC →
Trusted
Input data → Untrusted
Know writers →
Trusted
Know participants →
Trusted Environment
Know participants →
Trusted Environment
Economics and
Regulations
No clear regulations →
Gray area
No clear regulations
→ Gray area
Regulated by
participants → Defined
rules
Regulated by
participants → Defined
rules
77
© UZH 2019
Discussion and Evaluation
© UZH 2019
(Direct) Impact Factors
Influencing Factor Network Distributed System Remarks
Access: Public BC In principle
unaffected
Many nodes possible The real BC case,
partial anonymity
Access: Private BC Unaffected Typically “centralized” “No” BC
Cryptography - Compute load affected Mechanisms’ break?
BC size Larger throughput (Storage capabilities) -
Consensus
mechanisms
Availability
essential
PoW: high compute
load
Problem of energy
efficiency unsolved
Incentive/reward
mechanisms
Availability
necessary
Number of nodes in
BC network affected
-
Creation of blocks Load affected Compute load affected -
Block size Load affected Compute load affected -
Smart Contracts - Compute load affected -
Governance Affected Affected In multiple facets
Based on an incomplete survey, but originating from an investigation of those applications developed ourselves.
79
© UZH 2019
BC Opportunities and Drawbacks
Characteristics Opportunities Drawbacks Remarks
Distributed No central control,
no “master” needed
No central control,
no “master” exists
Censorship?
Unknown
stakeholders
Everyone can
participate
Lacking control of
participants’ “writes”
Application-specific
needs
Open,
transparent
No hiding possible Stakeholders’ activities
publicly viewable
Application-specific
needs
Immutable Once persisted,
persisted forever
Wrongly deployed
SC(s) not retractable
Realistic for “useful”
SCs? GDPR?
Append-only No deletions Growing in size GDPR compliance?
Traceable Proof of actions No hiding of actions Error handling?
Technical aspect Effective Efficiency, energy dem. Sustainability?
Economic aspect Cryptocurrency
(fully elect., decen.)
Impacts on economic
stability, currencies, …
Survivability of too ma-
ny “tokens” or “coins”?
Legal aspect Contracts without
intermediary
“Unknown” conflict
resolution instance(s)
No jurisdictional
borders, enforceability?
80
© UZH 2019
Blockchain Risks
BCs’ security and privacy
– Unknown attack vectors (& 51%), programming errors (SCs)
– Breaking of currently used security algorithms
• Long-term storage? Quantum Computing?
• Impacts due to alternative consensus mechanisms beyond PoW?
– Privacy: persisted data at stake?
• General Data Protection Regulation (GDPR)?
– The right to forget vs. immutability
– Transparency (public knowledge of BC) vs. privacy (private data)
Networking infrastructure’s reliability (critical infrastructures)
• Lacking Internet connectivity for a “longer” period of time?
Economic/legal risks (BC, cryptocurrency/tokens/coins)
• Fraudulent profitability projections, volatility, dispute resolutions (probs.)
81
© UZH 2019
Conclusions
1. Blockchains do show a logical evolution of linked lists,
however, they “exaggerate” processing demands– Especially Proof-of-Work (PoW), but this ensures immutability
2. The technical future of blockchains is based on
security ingredients of today’s technology, however,
long-term storage and security management is not
known by now– E.g., unknown impact of Quantum computing (on all IT!)
3. Blockchains are no revolution, but a typical Computer
Science (Abstract Data Type) evolution of linked lists– The “distribution” of consensus does not always make sense
– Any system as of the past has not been replaced fully by a
BC82
© UZH 2019
Thank you for your attention.
Any questions
left open?
