Short version of BlockchainTech: Hash-linking and Consensus Protocols

Conceptual background for what a blockchain has to accomplish

What's needed for trust in anonymous deals?

Authority

Execution

Continuity

How should you think of a blockchain formally?

a blockchain is like an operating system
- acts as a “master program” to coordinate all apps/smart contracts
- provides a virtual machine to developers of applications

like the Internet, “decentralized” - the product of collaboration between many physical machines, no one owner/operator

Validators: physical machines running a blockchain protocol. a.k.a. “nodes” (e.g., 22 or 100, communicating via Internet)
Transaction: user-submitted action. e.g., make a payment or mint an NFT translates to snippet of low-level code to be executed in the virtual machine
Block: sequence of transactions (➔ sequence of VM instructions) for now, assume can be of unbounded size

Some vocabulary

Consensus: decide on a sequence (aka “chain”) of blocks.
- note: all validators must agree on this sequence
- blocks keeping getting added (one-by-one) as long as there are transactions to process
- not obvious how to do this, more details to come

Responsibility of the Blockchain PROTOCOL

Consensus: decide on a sequence (aka “chain”) of blocks.
- note: all validators must agree on this sequence
- blocks keeping getting added (one-by-one) as long as there are transactions to process
- not obvious how to do this, more details to come
Execution: keep state of the virtual machine up-to-date.
- new block added ➔ execute the corresponding snippets of code (do computations, update variable values, etc.)
- conceptually straightforward (but hard/interesting engineering)

Responsibility of the Blockchain PROTOCOL

Loosely:
- all validators perform same state transition (= database updates)
- "clients" submit transactions to validators
- each validator keeps append-only list of finalized transactions
Goal: a protocol that satisfies consistency and liveness

A blockchain aims to work like a single computer
= "State Machine Replication" (SMR)

What is (a) a protocol (b) consistency and (c) liveness?

Protocol = code run by each validator. Each time step:
- perform local computations
- receive messages from other validators and txs from clients
- send messages to other validators

Consistency:
- all validators agree on a transaction sequence.
- ok if some lag behind, but no disagreements allowed!
- $\to$ i.e., all validators’ local chains are prefixes of a single chain

Liveness:
- every valid transaction submitted by a client eventually added to validators’ local histories/chains.

Key Subproblem: Agreeing on a Block

Assume for now: fixed and known set of (say) 1000 validators.
First attempt: target 1 block per second (say).
1. validators take turns as “leader” (round-robin, one per second)
2. current leader decides on block (i.e., list of ≤ 100 transactions)
3. leader sends block to other 999 validators
Question: what could go wrong?

Issue: leader could crash or go offline.

Idea: if don’t receive a timely block proposal, retry with the next leader (according to the round-robin schedule).

Issue: unexpected network delays.

Issue: leader could propose different blocks to different validators.

Who are the validators?

Scenario #1: fixed set of known parties.
- “permissioned” or “proof of authority” blockchain protocol
Scenario #2: validator set has free entry/exit (“permissionless”).
- Issue: “sybils.” (One entity runs many validators w/different IDs.)
- would seem to making voting impossible

Solution: validator voting weight proportional to ownership of some scarce (and hence costly) resource.
- Proof-of-work: (Bitcoin, Ethereum 2015-22) voting weight proportional to computational power devoted to running protocol.
- Proof-of-stake: (Ethereum 2022-now, Solana, etc.) voting weight proportional to amount of money escrowed in a smart contract.

A deep dive into the "How?"

Workflow of a transaction

Security

B3

B1

B2

B4

B5

Contains transaction from Sue to Bob

Question: Can Sue rewrite history?

immutability

No! Because: Economics! (remember: scare resource)

Incentive to support longest (heaviest/most work) 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:

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$

One approach to reach consensus: re-broadcast proposer message and follow majority

$t$

$x$

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

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

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

sidebar: formally, the hash function can be converted to a number
for a block to be considered valid it must be true that \[H(\text{block}+\text{nonce})<\text{difficulty limit}.\]
leading zeros in a hash make $H(\cdot)$ small

consensus is reached if hash starts with right number of leading zeros

Blockchain BFT

= 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 from 2021

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

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

Blockchain finality rules

...

epoch$_t$

epoch$_{t+1}$

epoch$_{t-1}$

checkpoint

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

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

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

Security?

To sabotage block production or to censor transactions, an attacker generally needs at least 33% of the total stake (so no 2/3 majority can be reached)
To create your own blocks only you need the 2/3 majority

on Sept 8, 2025: 34M ETH x $4,300=$146B

How much is that?

Rewards and Punishments

What do we need from validators?

Participation
Honesty

if "lazy"

misses out on rewards

if dishonest

Concretely they need to

vote on checkpoints
attest in committees
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

Economics of Proof-of-Work and Proof-of-Stake

Effects of an attack

B3

B1

B2

B4

B5

the longer you wait to consider a tranaction "done", the harder it becomes to attack
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 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 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$

HashLinked Databases and Consensus via Proof-of-Work and Proof-of-Stake

What's needed for trust in anonymous deals?

Authority

Execution

Continuity

Security

B3

B1

B2

B4

B5

immutability

Incentive to support longest (heaviest/most work) Chain

B3

B1

B2

B4

B5

B6

Altering the past?

B3

B1

B2

B4

B5

B8

B7

B9

B10

B6

Blockchain protocols establish consensus

Byzantine Generals' Problem

Blockchain BFT

Back to Altering the past

B3

B1

B2

B4

B5

B8

B7

B9

B10

B6

Effects of an attack

B3

B1

B2

B4

B5

B8

B7

B9

B10

B6

SOme Insights for Proof of Work Economics

Short version of BlockchainTech: Hash-linking and Consensus Protocols

More from Andreas Park