1. Blockchain == Crypto + Raft++
Jeff Chase
CPS 310
Spring 2019

4. Principles of Bitcoin / Ethereum
What is it?
A digital currency. It is money: you can buy it for USD$, spend it for goods and services, or cash it in for USD$.
A family of programs and protocols, running on IP-connected computers that form a P2P network to manage the currency.
[Ethereum] A programming platform for contract apps (dapps).
Who can join?
Anyone with an IP-connected computer: just run a program.
You can remain anonymous, but your IP address will be seen.
Who controls it?
Nobody and everybody. It is a public and trustless system with clever built-in incentives to maintain a balance of power, even when some participants (e.g., “miners”) are large and powerful.

5. The case against blockchain
Presumes Good > Evil.
Low throughput. Current throughput for Bitcoin is 7 transactions/sec. Fix: trust committee to pre-commit?
Wastes energy. Miners compute hashes all day in a race for money. Fix: Proof-of- Stake (Casper)?
Inherent in blockchain’s consensus protocol & design
Leader election
Block propagation takes time
forks
6 confirmations => 60 minutes
Nodes compute hash puzzles
energy wasted
Asynchronous probabilistic commit Past transactions/operations could revert (risk declines with time).
Long confirmation latency. Payee (or other observers) accept a transaction when the risk of it reverting falls below a threshold.
Can these challenges be fixed? Open research questions!

6. Blockchain hype and backlash

8. https://hackernoon.com/blockchain-for-students-101-the-basics-part-1-f39b8201a7d5
Signed
“ ”
(or leader)

9. [Image from Raft presentation]
Review: Replicated State Machine Consensus with a global log (“ledger”)
Client
shl
add
jmp
mov
shl
Log
Consensus Module
State Machine
add
jmp
mov
shl
Log
Consensus Module
State Machine
add
jmp
mov
shl
Log
Consensus Module
State Machine
Servers
(Replicas)
[Image from Raft presentation]
Deterministic application program with a service API.
Clients invoke service API: ops are recorded as log entries.
Every replica keeps a copy of the service state and the log.
RSM: replicas apply ops locally in same order  converge

10. Blockchain apps run as RSMs
Bitcoin runs one service with a simple API: transfer funds.
Ethereum platform/network runs many user-supplied programs.
Called smart contracts or chaincodes or dapps.
Executes a sequence of ops as a deterministic RSM.
add
jmp
mov
shl
Log
State Machine
Revert
Apply
API
ops
On a public blockchain, there is no commit: an op can always revert (e.g., to heal a partition or reconcile a “fork”). A replica must be able to revert completed ops to restore a previous state. Each replica rolls ops forward or back as many times as needed until the ledger stabilizes.

11. RSM consensus without trust
Consensus is much harder when some participants may lie, cheat, and steal: “Byzantine” consensus.
 Public (trustless) blockchains need crypto. + No trusted leader!
Classic blockchain loop:
Randomly choose replica to append a new block of log entries.
Each new block links securely to the previous block.
Adding a new block  signals approval of all previous blocks.
Broadcast the new block; receivers inspect and accept/reject.
Somehow reward faithful contributions and punish misbehavior.

12. Review: relevant crypto
Generate a keypair.
Keep one key private.
The other key is public.
Use either key to encrypt.
Use the other to decrypt.
crypt E D
crypt
Use an open asymmetric (public-key) crypt function (e.g., ECDSA, RSA).
Combine with hashing (e.g., SHA256) to form digital signatures. # X X #
SHA256
SHA256
Message
Hash function
64 byte
fingerprint
“Computationally infeasible”

14. Principals of Bitcoin (or Ethereum)
Q: How to name/identify “accounts” belonging to principal identities like Alice, Bob, etc.?
We need an account address that enables anonymous proof of ownership.
Anyone can make up an account/address.
Nobody knows who owns the account.
The owner (or the owner’s software) can prove on demand that it owns the account and the $$$.
If the owner transfers $$$ to another account, others in the network can verify the owner’s intent.
Ideas?

15. Bitcoin addresses

16. Bitcoin addresses
An address names a principal: an entity that can own bitcoin.
It is the hash of a public key.
The account owner is anyone with the matching private key.
The owner may spend bitcoin by publishing a signed statement (a “transaction”) to transfer it to another address. #

17. Bitcoin transactions (ops)
A record of a Bitcoin funds transfer is called a transaction.
It specifies (at least) a source and destination address, and an amount.
Each transaction has a globally unique ID.
Transactions are published to a global tamper-evident log (the “public ledger”).
They are public: anyone can see and validate the transaction.
Q: Privacy?

18. Bitcoin transactions

19. The P2P network: broadcast
Nodes cooperate to maintain a tamper-evident log block chain with a history (public ledger) of all operations (transactions).
There is no central repository for the log.
Many nodes keep copies. Anyone can query for it.
Nodes exchange pieces of the log (e.g., blocks of transactions) by passing them through the network in a peer-to-peer fashion.
A client joins the network by querying well-known nodes (DNS seeds) for the IP addresses of other randomly selected nodes.
Each node keeps a short list of randomly selected peers, and broadcasts the blocks and transactions it hears about to its peers.
Soon everyone hears about everything.
Nodes in the network play various roles ranging from simple clients (e.g., mobile) to large server clusters (miners) that build the log.

20. The Bitcoin network (illustration only)

21. Global consensus in a blockchain
In this case, global consensus means agreement over the last block link of the chain.
If we agree on the last link, then we agree on everything about the history that came before.
How to obtain consensus? Vote!
“Somebody” proposes a new block with a sequence of new transactions to append to the ledger/log/chain as they view it.
“Everybody” verifies for themselves that the new block is “valid”.
Each accepting receiver appends the block to its local replica.
Longest valid chain wins.
Note: concurrent data structure  needs synchronization (?)

22. Bitcoin: “Nakamoto consensus”
[NBFMG15]

23. How can global consensus work?
How to prevent attacker from “jamming” the blockchain?
Bitcoin solution: make it expensive to append a block.
Much more expensive than generating a new principal / sybil!
Generate a nonce (number used once) that solves an expensive puzzle, but is cheap/easy for others to to verify as a solution.
But then why would anyone be willing to validate transactions and append them to grow the history?
It’s too costly!
Bitcoin solution: pay them. Issue them new $$$.
Bitcoin has created a new industry (and a new driver for disrupting the climate): coin miners.

24. Coin miners
Miners are replicas that hear transactions, validate them, group them into blocks, and add them to the block chain.
They create/earn a bitcoin reward for each block published (“mined”).
A miner must invest a large amount of compute power to solve a puzzle in order to find and publish a block.
Miners race to solve the puzzle and obtain the reward: probabilistic proof of work
The reward is valid and spendable only if other nodes accept the published block.
Miners have an incentive to act faithfully and validate all transactions properly, so that other nodes “vote” to accept the block.
bitcoinminer.net
coincube.net

25. Proof of Work (Proof of Waste)
In Bitcoin, each block in the chain hashes to a value with a zero prefix. The creator of the block must find a number (nonce) to add to the block to yield a conforming hash. By presenting such a block, the creator proves that it has invested much computational power to produce the block.
Image:

26. The miner’s puzzle
The miner computes a secure hash over the block, and includes the hash in the block.
The puzzle: the miner must find a nonce value to include in the block, such that the block’s hash has a prefix of N zero bits.
N grows with time as computers get faster.
probabilistic proof of work
Finding a nonce such that the first hash bit is zero is like flipping a coin: the odds are 50% for any random trial.
Each added zero bit reduces odds by a factor of 2.
A miner’s win probability is proportional to its compute power. In this way, the next miner to publish is selected “randomly”.

28. Growing the log: adding a block
Anybody can be a miner.
Anybody can produce a block, add it to the chain, and broadcast it.
But it takes work.
When a miner links to a block B, it accepts B as the head of the valid chain. If others disagree, then the miner’s block is worthless ….so miners have an incentive to get it right!
Other peers check each block and “vote” on it.
If block A is posted “too late” (e.g., block B is added first), or if block A is invalid, then other miners ignore it and build the chain in another direction.
The longest chain wins.
In this way Bitcoin achieves consensus on the block chain and the global history of transactions.

29. Forks and healing
Forks result from faults, partitions, races, or attacks.
Over time, forks should resolve: one branch grows longer (attracts more “votes”) and so dominates.
Is it stable? If disagreements don’t resolve, what then?
Proposed new block N.
Links to history.
A and B accept N and each propose another new block. A N B C
C ignores/rejects A and “votes” for the B chain with a new block C. All replicas that hear of block C adopt the B chain, reverting A.

30. Clearing and confirming ops
A client requests an op (transaction) by broadcasting it to random other nodes, who pass it along by gossip.
Eventually the miners hear the request and include it in their blocks (if the request is valid).
Broadcast the new blocks in the same way.
Transmission is similar to “anti-entropy” or “gossip”.
Nodes exchange hashes for objects they have seen: the recipient requests/forwards the data if it has not seen it before.
A client considers its transaction confirmed when it appears in the blockchain with “enough” successor blocks.
Successor blocks act as confirming votes. But it could still revert! How many votes are enough?

31. Proof-of-Work as a sybil defense
A voting protocol is vulnerable to ballot stuffing. It is not sufficient to ignore “repeat votes” from a principal.
An attacker can appear to control many principals by minting new keypairs to vote with: a sybil attack.
PoW addresses this problem by picking a miner for the next block randomly, with probability weighted by the miner’s share of computational power in the replica pool.
Problems: massively wasteful; presumes that Good controls more computational power than Evil.
Vulnerable to 51% attack in which an attacker controls the majority of participating computational power.

32. On Saturday, the Coinbase security team noticed something troubling
On Saturday, the Coinbase security team noticed something troubling. Someone had made a deep reorganization in the distributed ledger for Ethereum Classic, a smaller spinoff from the Ethereum coin. The attackers had pulled off the cryptocurrency equivalent of writing a bad check.….
In the most basic terms, the attackers disrupted Ethereum Classic in order to spend the same money twice. They sold …coins for cash, then rewrote the blockchain so that they came away with both the cash and the coins. In a conventional payment system, it’s up to banks …to stop double spending, but there’s no such figure in cryptocurrency….
[I]f miners work together, there’s a way to write transactions out of the ledger. All they have to do is split the blockchain at the right moment, and only build on versions of the chain that don’t include the unwanted transaction. All they need is enough mining power to overwhelm the rest of the mining pool — hence, 51 percent.

33. Summary: how public blockchain differs from “vanilla” (e. g
Summary: how public blockchain differs from “vanilla” (e.g., Raft) RSM consensus
No fixed configuration: replica group is open+large.
Nobody trusts anybody. No leader! 51% evilfailure.
 No RPC: no trusted server to respond!
Log is public: public ledger. Anyone can read it.
Op confirmation appears in the log, so client and others see it.
*Replicas “take turns” as leader and check each other.
Leaders generate log entries in batches called blocks.
Leaders sign their blocks and chain hashes: no tampering.
Clients use keypairs to sign ops (entries, transactions).
No commit! Allows log forks! Repairrollback.
Not immutable! Risk of reverting “confirmed” op declines with time.

34. Review: open problems Presumes Good > Evil.
Low throughput. Current throughput for Bitcoin is 7 transactions/sec. Fix: trust committee to pre-commit?
Wastes energy. Miners compute PoW hashes all day long in a race for money Fix: Casper PoS?
Inherent in blockchain’s consensus protocol & design
Leader election
Block propagation takes time
forks
6 confirmations => 60 minutes
Nodes compute hash puzzles
energy wasted
Asynchronous probabilistic commit Past transactions/operations could revert (risk declines with time).
Long confirmation latency. Payee (or other observers) accept a transaction when risk that it reverts falls below a threshold.
Can these challenges be fixed? Open research questions!

35. Review: No log forks in RAFTC A P
In order to lead and serve client requests, a leader L1 must continually receive votes from a majority of the group (a quorum).
The quorum rule protects consistency (C) in a network partition: at most one subgroup commits to the log, so it does not diverge.
But it sacrifices availability (A). If a majority of replicas fail, it would be safe for the survivors to serve clients. But they must not, because this case is indistinguishable from a network partition.
L1 and F1 cannot commit log entries because they do not have a quorum. So they cannot serve clients  no Availability if the majority had merely failed.
L2 can gain a quorum from the other followers, so they can continue to serve requests together in close cooperation. L2 L1 F1
The quorum rule protects Consistency of the shared log in a partition. At most one side of a partition makes progress: there cannot be two disjoint majorities.

36. Review: questions about crypto-coin
How can we keep money safe in a network of anonymous participants?
How to reach consensus about who owns the money?
Every atomic currency unit (a “satoshi”) must be owned by exactly one participant at any time.
How to validate transactions to be sure that the spenders really own the money they are spending?
Where does the money come from? There is no central trusted authority to mint currency (unlike “real” money).
How to protect against attempts to counterfeit or steal money, tamper/rewrite history, or disrupt the network?

37. Looking for a good nonce (Bitcoin)
Hashcash algorithm
The transactions in a block are organized in a hash tree called a Merkle tree.
To try a new nonce, the miner rehashes the root of the tree (a fixed-size struct) with the candidate nonce.
The miner also must update one branch of the Merkle tree on each attempt—fixed cost (roughly).
So the cost to try a candidate nonce is fixed and independent of block size.
Block size is chosen to balance throughput (bigger is better) and fork probability (smaller is better).

38. Merkle tree [R. Merkle 1979]
From Narayanan et. al.: Bitcoin and Cryptocurrency Technologies

39. Block chain
From Narayanan et. al.: Bitcoin and Cryptocurrency Technologies

40. Block chain: tamper-evident log
From Narayanan et. al.: Bitcoin and Cryptocurrency Technologies