Andreas Park PRO
Professor of Finance at UofT
HashLinked Databases and Consensus via Proof-of-Work and Proof-of-Stake
Instructors: Andreas Park & Zissis Poulos
Rotman – MBA
Motivation: Silos vs Common Infrastructures
Illustration of Infrastructure Frictions: money transfers
Version 1: They use the same bank
Change ledger entry locally
Version 2: They use different banks but the banks have a direct relationship
Sue's bank transfers from Sue's account to Bob's bank's account
Bob's bank transfers from its account to Bob's account
Version 3: They use different banks that have no direct relationship
Sue's bank transfers from Sue's account to its own account
Bob's bank transfers from its account to Bob's account
Central Bank
Central bank transfers from Sue's bank's account to Bob's bank's account
International transfers
Sue's bank transfers from Sue's account to its own account
Bob's bank transfers from its account to Bob's account
use the Swift network of correspondent banks
Bottom Line
very complex
many parties
lots of frictions and points of failure
very expensive
Crazy thought: Wouldn't it be nice if there was a single ledger?
Existing solutions
Problem:
power concentration/Monopoly
Distributed Ledger/Blockchain Technology
- A "joint, single system"
- Features:
- secure storage of information and transfer of value
- guaranteed execution of code
- Promise
- open platform
- global reach
- frictionless finance
How does it all work and why?
How do we establish trust in commerce?
trustworthy People
long-term Relationships
reputation
contract law
institutions
What's needed for trust in anonymous deals?
Authority
Execution
Continuity
Authority
Do you have the item?
Do you have power over it?
Tool: "key" cryptography
Execution
Can we agree that it happened?
Tool:
consensus algorithm
Security and Continuity
Are the records immutable?
restricted permissions
really difficult to hack
premise of blockchain
no trusted parties needed
everything
in code
open to
anyone
platform or network
commerce thrives
How?
A deep dive into the "How?"
Cryptography: only Sue can spend her money
Authority
Execution
Problem: double-spending
How can we trust that
- sale happened and
- $$ only spent once?
Execution
Security
B3
B1
B2
B4
B5
Contains transaction from Sue to Bob
Question: Can Sue rewrite history?
immutability
No! Because: Economics!
Incentive to support longest Chain
B3
B1
B2
B4
B5
B6
Where to add a new block B7?
- Add to B3?
- => people after still more likely to add to B6
- lose "coinbase" reward
Altering the past?
B3
B1
B2
B4
B5
- needs to be faster than anyone after who adds to B5 and build a longer chain
- or needs to be able to mine repeatedly
B8
B7
B9
B10
B6
Contains transaction from Sue to Bob
Sue wants to undo the transaction by rewriting history with B6
How do you agree though that something happened, or, what is consensus?
Problem statement:
- Who gets to propose changes to the distributed database?
- How do we agree on making a change so we all know that everyone makes the same change?
How can we reach consensus (of whether or not to make a change? The Byzantine Generals' problem
Blockchain protocols establish consensus
With more players, the problem is less severe
\(t\)
\(t\)
\(t\)
\(t\)
\(t\)
\(t\)
\(t\)
\(t\)
\(t\)
One approach to reach consensus: re-broadcast proposer message and follow majority
\(t\)
\(t\)
\(x\)
\(t\)
\(t\)
\(t\)
\(t\)
\(t\)
\(x\)
\(t,t,x\)
\(t,t,x\)
\(t,t,t\)
Reaching Consensus with a Rogue/Faulty Player?
\(x\)
\(y\)
\(z\)
\(y\)
\(x\)
\(z\)
\(y\)
\(x\)
\(z\)
\(x,y.z\)
\(x,y,z\)
\(x,y,z\)
Reaching Consensus with a Rogue/Faulty Proposer?
General result
- proposed messaging yields consensus
- as long as no more than 1/3 cheats/are faulty/compromised
Equilibrium
- generals pick majority message
- successful consensus as long as no more than 1/3 cheats
Blockchain requirement
- reach Byzantine Fault Tolerant consensus
- trick: messages are hard to forge
Byzantine Generals' Problem
Proof-of-Work
Proof of Work Protocol
Protocol does three things
1. selects the leader
3. creates randomness in the proposer selection
2. creates a message to coordinate on
Technical Process in Proof of Work
How do you find the NUMBER (NONCE) that works? You do not know which works, you need to try (=guess) many many times
This Hash starts with a pre-specified number of zeros!
Claim: Can be used for a Byzantine Fault Tolerant Algorithm
consensus is reached if hash starts with right number of leading zeros
Blockchain BFT
= 00000xd4we...
= 00000xd4we...
= 00000xd4we...
Back to Altering the past
B3
B1
B2
B4
B5
- to create a new reality, the cheater has to create blocks faster than the rest of the network
- has to make more guesses that the rest of the network combined
B8
B7
B9
B10
B6
Contains transaction from Sue to Bob
Sue wants to undo the transaction by rewriting history with B6
Sue's objective
- Wants to undo this trade and cheat Bob by building alternative chain from B6
What does it take?
- needs to be predictably able to add several blocks to the chain without interference, or
- needs to be faster than anyone after who adds to B5 and build a longer chain, or
- needs to ability to reject new blocks that are added to B5 .
How does Proof of Work prevent this?
- mining success is random subject to resources spend:
- computers/GPUs
- electricity
- you need faster/more computers than 51% of the network
- current network power: 150million tera-hashes per second (blockchain.info)
Back of the envelope calculation
- hashrate: 150,000,000 TH/s
- best hardware (ASIC) has 110TH/s per unit
- => need 150,000,000 / 110 x 0.5 = 682,000 ASICs
- 1 ASIC costs around $10,000 (conservative)
- =>Cost = $6,820,000,000
- But it doesn't end here...Power consumption at 4.5GW
- => enough to power 1M homes in the US
Proof-of-Stake
Proof of Stake (PoS) - What is the goal?
- Energy efficiency
- No need to commit extreme compute power to solve puzzles for leader election (PoW)
- Centralization Risk
- Can validate using simpler hardware -> more nodes can participate to validate network
- Economic cost of attacks
- Explicit penalties for misbehaviour (vs. PoW)
Validation and leader election
random
32 ETH
Validation and leader election
random
random
random
Committee 1
Committee 2
random
Block formation
Committee 1
Committee 2
...
Committee 32
attest
attest
Slot 1
Slot 2
Slot 32
...
12 seconds
Finality!
...
checkpoint
...
vote
vote
When final?
2/3 of stake has voted
Security
What do we need from validators?
- Participation
- Honesty
if "lazy"
misses out on rewards
if dishonest
Security
What is dishonest?
- Propose multiple blocks for single slot
- Contradictory attestations
TLDR
Performing a 51% attack still possible but "almost equivalent to having your entire mining farm burn down while you are doing it" -Zamfir
Other malicious behaviour
- Long-range attack
- Short range reorgs (can be bad for DeFi)
- etc.
What about forks??
Still possible
- Need agreement on what the canonical chain is
- Longest-chain rule not ideal. Why?
B3
B1
B2
B4
Protocol Rule
"The canonical chain is the one with greatest weight of attestations in its history"
Economics of Proof-of-Work and Proof-of-Stake
SOme Insights for Proof of Work Economics
Double spend attack prevention
- Validation rewards are taken as given, but they are crucial in
- determining incentives to participate,
- to support the chain, and
- to expense electricity and computing power
Basic idea of competitive equilibrium
aggregate mining cost = aggregate reward
Double spending attack
- expense resources but:
- win N block rewards until "confirmation" block
- ability to double-spend
condition that prevents it
(Chiu & Koeppl RFS 2018)
\text{mining reward} \times (N+1)N > \text{double spend amount}
PoS vs PoW
https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/
PoS vs PoW Economics
Basics:
validators receive:
- coinbase rewards
- "tips" = fees attached to transactions
- NB: since London fork fees have two parts:
- manatory (>0 needed for code processing) => gets burned
- tips => fees to validators
- coinbase rewards are inflationary/dillution
- shifts chain value from everyone to validator
PoS vs PoW Economics of Coinbase Rewards
-
PoW:
- coinbase reward go to outside party for performing a service
- proportional to resources committed
-
PoS:
- fees go to existing coin holders for "community service"
- proportional to stake
PoS Economics of Coinbase Rewards
Question: do the rich get richer?
- No
- same idea as in investment: wealth shares in the economy grow proportional to risk-taking
- Here: wealth shares are a Martingale
- convergence to distribution that mimics the initial distribution
- mathematical concept: Polya's Urn
Intution
- Two validators A, B with 20%/80% of coins
- Assume
- 1,000,000 at the begining of the year
- 1,000,000 issued during the year
- Ownership at the beginning of year
- A owns 200,000 coins
- B owns 800,000 coins
- A gets selected 20% of the time, B 80%
- => A earns ~200,000 coins
- => B earns ~800,000 coins
- Ownership at the beginning of year
- A owns 400,000 coins = 20%
- B owns 1,600,000 coins = 80%
PoS Coinbase Rewards: do the rich get richer?
stakes
20%
80%
rewards
PoS Coinbase Rewards: do the rich get richer?
stakes
20%
80%
PoS Coinbase Rewards: do the rich get richer?
stakes
20%
80%
- still have the same wealth share
- mathematically: wealth shares are a Martingale that converges to the initial distribution
PoS Other Questions
- Is PoS an equilibrium?
- Yes: Saleh RFS 2019
- Is verification an equilibrium?
- Tricky!
- Biais et al (WP 2022)
- If everyone verifies, there is no incentive to verify! => Why spend the resources?
- But: can construct a mechanism such that only valid blocks are produced.
- Requires making validators pivotal
- Are higher staking rewards always better?
- John, Rivera, Saleh (WP 2022): not necessarily, can make long-term investment less attractive
- Is scaling a problem?
- limited capacity: validators earn more fees
- increasing capacity
- under PoW: lowers fees and reduces incentives for miners => security \(\searrow\)
- under PoS: increases demand for blockchain => value of chain => security \(\nearrow\)
BlockchainTech: Hash-linking and Consensus Protocols
By Andreas Park
BlockchainTech: Hash-linking and Consensus Protocols
This deck introduces some tech concepts
