Economics of Decentalized Currency Systems

41
Economics of Decentralized Currency Systems By Ernie Teo, Research Fellow, Sim Kee Boon Institute for Financial Economics

Transcript of Economics of Decentalized Currency Systems

Economics of Decentralized

Currency Systems By Ernie Teo, Research Fellow, Sim Kee

Boon Institute for Financial Economics

THE MONEY MATRIX

Internet couponMobile coupon

E-money

Legal status

Not based on cryptography

Decentralized cryptocurrencies

Centralized virtual currencies

Physical commodity money

Local currencies

Decentralized N/A

Currency

RegulatedBanknotes and

coinsCommercial bank money

(deposits)

The Money Matrix

Money format

PhysicalDigital

Cryptocurrency

UnregulatedCentralized

CouponVirtual

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

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

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.

GRAPHICALLY…

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

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

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

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

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)

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 TolerancePease, 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

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

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

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

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

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

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

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

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

MINING PROTOCOLS

Plan A

Plan B

Plan Ahashed

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

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 TakenActual Time Taken

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

RIPPLE PRIMER

• Ripple Explained: Medieval Banking with a Digital Twist, CoinDesk,  May 11, 2014• http://www.coindesk.com/ripple-medieval-banking-digita

l-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

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/

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/

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/

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/

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 bitcoinBased on: http

://www.coindesk.com/ripple-medieval-banking-digital-twist/

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

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

CONSENSUS PROTOCOLS

Plan X

General ARound 1UNL

BFKLPRT

50% reached

Plan X/ General A/ Round 1

Round 1 Broadcasts

ok

okok

ok

Round 2

60% reached

Plan X/ General A/ Round 2

okokok

okok

Round 2 Broadcasts

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

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

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

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

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

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

The End, Thanks!

Any Comments are Welcomed

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

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 supplyBack