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?"

Workflow of a transaction

Cryptography: only Sue can spend her money

Authority

Execution

Problem: double-spending

How can we trust that

  1. sale happened and
  2. $$ only spent once?

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

Sidebar: this type of attack is also referred to as "selfish mining"

How do you agree though that something happened, or, what is consensus?

Problem statement:

  1. Who gets to propose changes to the distributed database?
  2. 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\)

consensus is reached!

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\)

consensus is reached (no attack)

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?

  1. needs to be predictably able to add several blocks to the chain without interference, or
  2. needs to be faster than anyone after who adds to B5 and build a longer chain, or
  3. 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

Blockchain organization

Slot 1

Slot 2

Slot 32

...

12 seconds

epoch\(_t\)

epoch\(_{t+1}\)

epoch\(_{t-1}\)

Block inclusion

Committee #1 of validators

Slot 1

Slot 2

Slot 32

...

proposer #1 assembles transactions in block and proposes to a committee

attests validity

Block inclusion

Committee #2 of validators

Slot 1

Slot 2

Slot 32

...

proposer #2 assembles transactions in block and proposes to a committee

attests validity

Block inclusion

Committee #32 of validators

Slot 1

Slot 2

Slot 32

...

proposer #32 assembles transactions in block and proposes to a committee

attests validity

Blockchain finality rules

Slot 1

Slot 2

Slot 32

...

12 seconds

epoch\(_t\)

epoch\(_{t+1}\)

epoch\(_{t-1}\)

checkpoint

checkpoint

checkpoint

checkpoint

Blockchain finality rules

...

epoch\(_t\)

epoch\(_{t+1}\)

epoch\(_{t-1}\)

checkpoint

checkpoint

checkpoint

checkpoint

all validators vote on validity

all validators vote on validity

all validators vote on validity

all validators vote on validity

(for clarity: checkpoint voting happens over time, by all validators)

Blockchain finality rules

...

epoch\(_t\)

epoch\(_{t+1}\)

epoch\(_{t-1}\)

checkpoint

checkpoint

checkpoint

checkpoint

valid?
\(\Rightarrow\) "justified"

last justified block becomes "final"

valid?
\(\Rightarrow\) "justified"

last justified block becomes "final"

  • a checkpoint is "justified" once \(\frac{2}{3}\) of all validators vote for validity
  • once a checkpoint is justified, the last justfied checkpoint becomes final

valid?
\(\Rightarrow\) "justified"

Validators, Committees, Proposers

ETH owners lock up funds (\(\ge32\)ETH) in a special smart contract

validators selected at random based on proportional ownership of total stake

Slot 1

proposer

Slot 2

proposer

Slot 32

proposer

Validators, Committees, Proposers

Slot 1

proposer

Slot 2

proposer

Slot 32

proposer

validation
committee

validation
committee

validation
committee

128 validators per committee (\(\Rightarrow\) 32 x 128) are selected at random based on proportional ownership of total stake

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

Rewards and Punishments

What do we need from validators?

  1. Participation
  2. Honesty

if "lazy"

misses out on rewards

if dishonest

Concretely they need to

  1. vote on checkpoints
  2. attest in committees
  3. propose valid blocks

What rewards?

proposer

  • coinbase
  • "tips"/fees
  • MEV

Committee

  • coinbase

 

What penalties?

offline

  • small penalty based on time offline

misbehavior

  • stake slashing (usually 1 ETH)
  • exclusion from validation
  • goes per node

Security

What is dishonest?

  1. Propose multiple blocks for single slot
  2. 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

  1. Long-range attack
  2. Short range reorgs (can be bad for DeFi)
  3. etc.

What about forks??

Still possible

  1. Need agreement on what the canonical chain is
  2. 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

Effects of an attack

B3

B1

B2

B4

B5

  1. the longer you wait to consider a tranaction "done", the harder it  becomes to attack
     
  2. BUT: the attacker earns a block reward for each selfishly-mined block!

B8

B7

B9

B10

B6

Goal: Attackers wants to create an alternative history

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\)