This presentation examines the justifications for a decentralized currency system, looking at the main beneficiaries of such a system and comparing it to a centralized currency. Next, the Byzantine General’s Problem will be discussed from a game theoretical perspective. We will look at how various solutions such as mining protocols (such as proof of work and proof of stake like Bitcoin) and consensus protocols (like Ripple and Hyperledger), attempts to tackle the problem. The talk will conclude by comparing between the Ripple and Bitcoin systems, looking at the pros and cons, and the participation incentives of nodes.
2. THE MONEY MATRIX
Internet coupon
Mobile coupon
E-money
Legal
status
Not based on
cryptography
Decentralized
cryptocurrencies
Centralized virtual
currencies
Physical
commodity money
Local currencies
Decentralized N/A
Currency
Regulated
Banknotes and
coins
Commercial
bank money
(deposits)
The Money Matrix
Money format
Physical
Digital
Cryptocurrency
Unregulated
Centralized
Coupon
Virtual
Taken from: http://en.wikipedia.org/wiki/Virtual_currency
Reference: European Central Bank (October 2012). "1". Virtual Currency Schemes (PDF).
Frankfurt am Main: European Central Bank. p. 5. ISBN 978-92-899-0862-7.
N/A
N/A
3. WHAT IS A
DECENTRALIZED MARKET?
INVESTOPEDIA EXPLAINS 'DECENTRALIZED MARKET'
• The foreign exchange market is an example of a
decentralized market because there is no one
physical location where investors go to buy or sell
currencies. Forex traders can use the internet to
check the quotes of various currency pairs from
different dealers from around the world.
http://www.investopedia.com/terms/d/decentralizedmarket.asp
4. WHAT IS DECENTRALIZED
CURRENCY?
A decentralized currency was defined by the US
Department of Treasury as a currency
• That has no central repository and no single
administrator
• That persons may obtain by their own computing or
manufacturing effort
• Rather than relying on confidence in a central
authority, it depends instead on a distributed
system of trust.
6. WHY DECENTRALIZE?
Features
• Privacy – pseudo-anonymous
• Transparency – all transactions can be seen
• Trustless – doesn’t rely on trust
• Hard to shut down
• No chargebacks
• Ownership – users own their account
• Faster and cheaper than traditional international transfers
• Central government has no control
• Can’t print money to finance debts
• Non inflationary – there may be deflationary pressures
• Can’t take back uninsured deposits, eg. Cyprus
7. WHO MAY BENEFIT?
• The underbanked
• Overseas workers in need of international
remittance
• People looking for fast and cheap ways to pay over
the internet
• Citizens of countries facing risk of hyperinflation
• Libertarians – no government control and full
anonymity
8. HOW DO WE
“COUNT VOTES”?
• Decisions are made in decentralized systems by
participating “voters”
• It is necessary to ensure that protocol used to
validate all “votes” gives the desired results
• Unlike usual elections, votes are not counted by a
central authority
• There will be coordination problems in decision making
• The Byzantine General’s Problem is used to describes
such scenarios
9. THE BYZANTINE
GENERAL’S PROBLEM
• Byzantine generals
must decide
unanimously whether to
attack some enemy
army
• Each general’s army is
geographically
separated
• Must communicate by
sending messengers
• There is a presence of
traitors amongst the
generals
10. THE BYZANTINE
GENERAL’S PROBLEM
• Traitors can force decisions like
• Attacking when most generals do not wish to attack
• Confusing some generals to the point that they are
unable to make up their minds
• In a distributed/decentralized currency system,
each miner/validating node can be considered a
“general”
• Nodes need to agree upon the validity of a transaction
• Malicious nodes can work together to invalidate
legitimate transactions
• Or validate double spent transactions (by invalidating the first
transaction)
11. FORMULATING A SOLUTION
An algorithm need to guarantee that
A. All loyal generals decide upon the same plan of action
• The loyal generals will all do what the algorithm says they
should, but the traitors may do anything they wish
The algorithm must guarantee condition A regardless of what
the traitors do. We also want to insure that
B. A small number of traitors cannot cause the loyal generals
to adopt a bad plan
This ensures Byzantine Fault Tolerance
Pease, M.; Shostak, R.; Lamport, L. (April 1980). "Reaching Agreement in the
Presence of Faults". Journal of the ACM 27 (2): 228–
234. doi:10.1145/322186.322188
12. SOLUTIONS TO THE
BYZANTINE GENERAL’S
PROBLEM?
• Byzantine faults include:
• omission failures (e.g., crash failures, failing to receive a
request, or failing to send a response)
• commission failures (e.g., processing a request
incorrectly, corrupting local state, and/or sending an
incorrect or inconsistent response to a request).
• When a Byzantine failure has occurred, the system
may respond in any unpredictable way, unless it is
designed to have Byzantine fault tolerance
13. SOLUTIONS TO THE
BYZANTINE GENERAL’S
PROBLEM?
• The byzantine general’s problem has no solutions
unless
n ≥ 3t + 1
• where n is the number of processes in the system
and t is the number of traitors (faults)
• In other words, the algorithm can ensure correct
operation only if fewer than one third of the
processes are faulty
• If unforgeability of messages is possible, higher
fault tolerance is possible
14. UNDERSTANDING BYZANTINE
FAULT TOLERANCE WITH
GAME THEORY
• Abraham, Ittai, Lorenzo Alvisi, and Joseph Y.
Halpern. "Distributed computing meets game
theory: Combining insights from two fields." ACM
SIGACT News42.2 (2011): 69-76.
• To extend game theory to incorporate fault
tolerance, it is necessary to move beyond single
player deviations
• An equilibrium is k-resilient if no group of k players can
all do better by deviating
15. UNDERSTANDING BYZANTINE
FAULT TOLERANCE WITH
GAME THEORY
• We also need to consider non-rationality or
unanticipated behavior
• An equilibrium is t-immune if non-deviating players are
not made worse off by arbitrary deviations by up to t
players
• A Nash equilibrium has k=1 and t=0
• We get fault tolerance, we need an equilibrium
concept that is both k-resilient and t-immune
• One way to achieve that is by assuming altruistic or
obedient players
16. DECENTRALIZED CURRENCY AND THE
BYZANTINE GENERAL’S PROBLEM
• A number of Byzantine Generals each have a computer
and want to attack the King's computer system
• They must crack the password within a limited time to
break in and erase the logs, lest they be discovered
• They only have enough CPU power to crack it fast
enough if a majority of them attack at the same time
Adopted from:
https://bitcointalk.org/oldSiteFiles/byzantine.html
17. DECENTRALIZED CURRENCY AND THE
BYZANTINE GENERAL’S PROBLEM
• They don't particularly care when the attack will be,
just that they agree
• It has been decided that anyone who feels like it
will announce an attack time, whatever plan is
heard first will be the official plan
• The problem is that the network is not
instantaneous, and if two generals announce
different plans at close to the same time, some may
hear one first and others hear the other first.
Adopted from:
https://bitcointalk.org/oldSiteFiles/byzantine.html
18. MINING PROTOCOLS
• Mining protocols like bitcoin aims to achieve
byzantine agreement using a proof-of-work chain
• Once each general receives whatever plan he
hears first, he sets his computer to solve a difficult
hash-based proof-of-work problem that includes the
plan in its hash
• The proof-of-work is difficult enough that with all of
them working at once, it's expected to take 10
minutes before one of them finds a solution and
broadcasts it to the network
Bitcoin Primer
19. MINING PROTOCOLS
• Once received, everyone adjusts the hash in their
proof-of-work computation to include the first
solution, so that when they find the next proof-of-
work, it chains after the first one
• If anyone was working on a different plan, they
switch to this one, because its proof-of-work chain
is now longer
• After about two hours, the plan should be hashed
by a chain of 12 proofs-of-work
20. MINING PROTOCOLS
Plan A
Plan B
Plan A
hashed
Next Proof
of Work
Some computers starts solving
hashed based proof of work for plan A
Some computers starts solving
hashed based proof of work for plan B
Plan B is abandoned
The chain continues…
All computers move
to this chain
21. MINING PROTOCOLS
• Every general, just by verifying the difficulty of the
proof-of-work chain, can estimate how much
parallel CPU power per hour was expended on it
and see that it must have required the majority of
the computers to produce in the allotted time
• Difficulty = (Previous Difficulty) x
• Hash Rate = total amount of calculations the
network can make per second
Intended Time Taken
Actual Time Taken
22. MINING PROTOCOLS
• This would mean that most of them had to have
seen the plan, since the proof-of-work is proof that
they worked on it
• If the CPU power exhibited by the proof-of-work is
sufficient to crack the password, they can safely
attack at the agreed time
23. RIPPLE PRIMER
• Ripple Explained: Medieval Banking with a
Digital Twist, CoinDesk, May 11, 2014
• http://www.coindesk.com/ripple-medieval-banking-digital-twist/
• By Antony Lewis, ItBit
• Anthony uses the example of Hawala to explain
Ripple
• A traditional way of sending money in medieval Arabia which is
still practised today
24. RIPPLE PRIMER
• Alex wants to send money to Beth:
• Alex goes to his local hawala agent and gives him
some cash and a password, which he and Beth
share.
• The agent telephones Beth's local agent and
tells him to release funds to someone who can
provide the password.
• Beth walks in to her agent, says the password,
and receives cash
• Commissions can be taken from either or both
agents.
Based on: http://www.coindesk.com/ripple-medieval-banking-digital-twist/
25. RIPPLE PRIMER
• Money has been transmitted from Alex to Beth, but
the physical notes have not moved!
• Alex's agent owes Beth's agent money
• They can either settle the debt later, or hope that
there may be reverse transactions if other clients
want to move money in the opposite direction
Based on: http://www.coindesk.com/ripple-medieval-banking-digital-twist/
26. RIPPLE PRIMER
• Trust is involved
• In this scenario, there are three trust relationships:
• Alex has to trust that his agent will do the right
thing, as he is handing over cash
• Beth has to trust that her agent will do the right
thing, as she is expecting to receive cash
• The agents need to trust each other over the
repayment of the debt (IOUs)
Based on: http://www.coindesk.com/ripple-medieval-banking-digital-twist/
27. RIPPLE PRIMER
Moving to Ripple
• “Gateways” such as exchanges or banks perform
the function of agents
• IOUs can be communicated electronically over the
Ripple network
• Alex logs on to his preferred Ripple gateway,
deposits money to it
• Alex then transfer electronic funds to Beth
• Beth collects her funds via her gateway
Based on: http://www.coindesk.com/ripple-medieval-banking-digital-twist/
28. RIPPLE PRIMER
Moving to Ripple
• The system allows for trade between currencies
• Alex can deposit USD with his gateway but choose to
send EUR to Beth
• If the two gateways do not trust each other, we can
use a chain of trust
• eg, the two gateways operate on different currencies
• XRP, ripple’s native currency can be used
• XRP is irreversible and trustless
• Similar to bitcoin
Based on: http://www.coindesk.com/ripple-medieval-banking-digital-twist/
29. CONSENSUS
PROTOCOLS
• Each general has a unique node list (UNL)
• Have to be nodes not run by the same group or
individuals
• No need to trust UNL, just have to trust that <50% will
collude with each other
• Examples:
• General A and B hate each other
• General X and Y don’t speak the same language
• Each general can also choose nodes with a good
reputation or are non-anonymous
30. CONSENSUS
PROTOCOLS
• The plan/transaction is broadcasted into the
network
• Each node verifies the plan is sound and
broadcasts it into the network
• Verification is asynchronous, each round is timed
• In the first round, each node checks against their UNL
• If 50% agrees by the time limit, the node re-broadcasts the
message
• In the second round, 60% has to agree
• In the third round, 70% has to agree
• In the fourth round, 80% has to agree
31. CONSENSUS
PROTOCOLS
Plan X
General A
Round 1UNL
B
F
K
L
P
R
T
50%
reached
Plan X/ General A/ Round 1
Round 1 Broadcasts
ok
ok
ok
ok
Round 2
60%
reached
Plan X/ General A/ Round 2
ok
ok
ok
ok
ok
Round 2 Broadcasts
32. CONSENSUS
PROTOCOLS
• Consensus is reached at the end of the 4th round
• The message/transaction is applied to the last
closed ledger
• This is known as the Ripple Consensus Algorithm
• In reality, multiple messages are verified in each
“bundle”
• Messages that do not reach the target in either
round will be discarded and considered in the next
bundle
33. CONSENSUS
PROTOCOLS
• Consensus is reached at the end of the 4th round
• The message/transaction is applied to the last
closed ledger
• This is known as the Ripple Consensus Algorithm
• In reality, multiple messages are verified in each
“bundle”
• Messages that do not reach the target in either
round will be discarded and considered in the next
bundle
34. CONSENSUS
PROTOCOLS
• At 80%, the fault tolerance is
• t ≤ (n-1)/5
• Each general on the UNL may have different UNLs
from each other
• This makes the consensus decentralized
36. CONSENSUS
PROTOCOLS
• For nodes to reach agreement regardless of their
UNLs, certain amount of connectivity within the
network is required
• If a network is too cliquey, consensus could form within
cliques and forks can occur
37. DISCUSSION– MINING
• Miners are incentivize by rewards and transaction
fees
• As the system evolves over time, miners compete on
computational power
• This eventually led to the emergence of mining pools,
and less individual miners
• This causes the network to be less decentralized than
originally intended
• Mining protocols are “good enough” solutions to the
byzantine general’s problem
38. DISCUSSION– CONSENSUS
• No economic incentives to be validators
• Nodes would be gateways or exchanges
• Gateways may have more incentives to be validators in
order to ensure the health of the network
• The eco-system needs to be created by getting
gateways to join the network
• Consensus networks are faster as there is no
proof-of-work
40. SHORT
BITCOIN PRIMER
• Bitcoin is a decentralized encrypted digital currency
system
• Transactions are recorded on a decentralized
online ledger called the Blockchain
• Ledger entries called blocks are created every 10
minutes on average
• Each ledger entry is chained to the previous entry
making it almost impossible to change past
transactions
41. SHORT
BITCOIN PRIMER
• bitcoins are created via the ledger validation
process called mining
• Each ‘miner’ participates in solving a cryptographic
puzzle which takes approximately 10 mins to solve
• Difficulty level is adjusted based on computing power
available
• bitcoins are received as a reward by miners
• Another way to get bitcoins is to trade it with fiat
currencies via exchanges
• Prices are determined by demand and supply
Back