Lecture 3: Scaling Bitcoin Andrew Miller SJTU 2017 Winter School on Cryptocurrency and Blockchain Technologies - Jan 14, 2017
3.2 transactions per second
VISA: 2000 transactions/sec on average, (2015) peak rate of 56,000 transactions/sec Bitcoin: 3.2 transactions/sec on average (as of Jan. 2017) 3.3-7 transactions/sec max Can decentralized blockchains be scaled up to match the performance of a mainstream payment processor?
Bitcoin faces an imminent scaling hurdle 1.0MB (HARD LIMIT) Jan ‘17 Jan ‘16
Last updated: April 2016! (as of Jan 17)
Last updated: April 2016! (as of Jan 17)
Last updated: April 2016! (as of Jan 17)
Last updated: April 2016!
Goal of this lecture: understand the technical topics underlying the Bitcoin scaling controversy 1. Bitcoin’s underlying P2P communication network 2. Upgrade mechanisms “hard-fork” and “soft-fork” 3. “Off-chain” payment channels, e.g. “Lightning”
3.1: Bitcoin’s P2P Network
P2P Network consists of ~5500 nodes
P2P Network consists of ~5500 nodes Network nodes (aka reachable/full nodes): - bootstrap new nodes into the network - provide service to mobile clients - relay blocks and transactions - sound alarms if they see invalid blocks
Nodes communicate by sending messages PING PONG Respond within 60 seconds, or disconnected! Ping/Pong
Nodes communicate by sending messages (connect) VERSION VERSION VERACK VERACK / , 1 . 3 1 0 . : i h s o t a S / s k c o b l 4 2 9 7 4 4 Initial Handshake
Forming connections: 1. Learn about new nodes by connecting to hardcoded “Seeder” nodes $ dig seed.btc.petertodd.org 2. Form 8 outgoing connections 3. Accept up to 125 total connections (incoming and outgoing) 4. Propagate information about nodes to each other
Nodes communicate by sending messages GETADDR ADDR ADDR ADDR messages sent in Sampled from local response to GETADDR, “addrMan” also spontaneously database Propagate information about other peers
Nodes communicate by sending messages GETHEADERS HEADERS GETBLOCKS BLOCK BLOCK BLOCK BLOCK Blockchain Download
Nodes communicate by sending messages INV GETDATA BLOCK TX Only sends GETDATA if it doesn’t have it and hasn’t already asked Learn about new transactions
I found a block! ) h ( V N I INV(h)
) I found a block! h ( A T A D T E G ) h ( V N I INV(h) GETDATA(h)
) b ( K C O L B ) I found a block! h ( A T A D T E G ) h ( V N I INV(h) GETDATA(h) B L O C K ( b )
) b ( K C O L B INV(h) ) I found a block! h ( A T A D T E G ) h ( V N I INV(h) INV(h) GETDATA(h) B L O C K INV(h) ( b )
) b ( K C O L B INV(h) ) I found a block! h ( A T A D T E GETDATA(h) G ) h ( V N I INV(h) INV(h) GETDATA(h) B L O C K INV(h) ( b ) GETDATA(h)
) b ( K C O L B INV(h) ) I found a block! h ( A T A D T E GETDATA(h) G ) h ( V N I BLOCK(b) INV(h) INV(h) GETDATA(h) B L O C K INV(h) ( b ) GETDATA(h) B L O C K ( b )
) b ( K C O L B INV(h) ) I found a block! h ( A T A D T E GETDATA(h) G ) h ( V N I BLOCK(b) INV(h) INV(h) GETDATA(h) B L ) O h ( C V N I K INV(h) ( b ) GETDATA(h) B L O C K ( b )
Demonstration: Tiny Bitcoin Peer - Fun for a demo - connects immediately to a random Testnet node https://github.com/amiller/tinybitcoinpeer - Good starting point for exploring/experimenting with the network - For more info: https://en.bitcoin.it/wiki/Protocol_documentation https://bitcoin.org/en/developer-reference#p2p-network
Bitcoin faces an imminent scaling hurdle 1.0MB (HARD LIMIT) Jan ‘17 Jan ‘16
Why not just increase the limit?
Concern #1: Orphaned blocks → Decrease in power (caused by delay in propagation)
Counter argument: Many Bitcoin miners use alternative networks Examples: - Bitcoin Fibre http://bitcoinfibre.org/public-network.html - Falcon http://www.falcon-net.org/ Features: Optimized topology (not random) Compression / prediction Transmits and validates in a “pipelined” fashion
Miners are not the only nodes in the network. We also care about the full nodes. Let’s do science! Idea: use empirical measurements about the P2P network to determine an appropriate block size scaling limit
Measurement Study #1 Measuring the Bitcoin Peer-to-Peer Network I found a block! ) h ( V N I Measurement node: connects to all nodes, records messages & timestamps
Measurement Study #1 Measuring the Bitcoin Peer-to-Peer Network I found a block! INV(h) ) h ( V N I INV(h) INV(h) Measurement node: connects to all nodes, records messages & timestamps
Measurement Study #1 Measuring the Bitcoin Peer-to-Peer Network I found a block! INV(h) ) h ( V N I I N V ( h ) INV(h) INV(h) Measurement node: connects to all nodes, records messages & timestamps
Measurement results (Propagation rate vs block size)
4.1MB in 10 minutes, reaches 90% of the nodes Def’n: X% effective throughput (block size)/(X% block propagation delay)
Measurement Study #2 Physical Limits indicate 10-100x greater capacity
Caveats and limitations - Measurements pertain to the network as it exists today - Affected by protocol changes - Affected by participation and provisioning - Our measurements efforts could be easily attacked - Should we even care about the P2P network? - We’ve used # nodes as a proxy for decentralization. (Not an axiom!) - Why 90%? Do the most poorly provisioned nodes provide relevant service? - Miners already route around the P2P network (e.g., Bitcoin Relay Network)
A contentious scaling debate rages on Appropriate size: 1MB, 2MB, 4MB, 8MB? Change over time? No limit at all? Measuring consensus: what’s the threshold? Who is represented? Upgrade mechanism: Hard-fork or soft-fork? Failure modes: will the p2p network grow to match policy? Underlying values: decentralization? adoption? risk vs. urgency ………….
3.1: How to Upgrade Bitcoin with “Hard Forks” and “Soft Forks”
What ways would we want to change Bitcoin? - Increase the block size limit Let’s focus on this - Add support for a new signature type for now (Post-Quantum signatures?) - Reverse a transaction that was made by mistake - Add “encryption” to the P2P protocol
Hard forks - the obvious way New code deployed, with Activation day! (block time for everyone to switch number) OldTx OldTx OldTx OldTx OldTx OldTx Time
Hard forks - the obvious way New code deployed, with Activation day! (block time for everyone to switch number) OldTx OldTx NewTx NewTx NewTx OldTx OldTx NewTx NewTx NewTx OldTx OldTx NewTx NewTx NewTx Time
Un-upgraded nodes will view a weaker and smaller chain with old-style transactions <oldsig> | <pubkey> OP_CHECKSIGVERIFY Two conflicting blocks! <newsignature> | <pubkey> OP_CHECKSIGVERIFY What happens to nodes that fail to upgrade in time?
/Satoshi:0.11.2/ - Nov 12, 2015 https://bitnodes.21.co/nodes
Let’s accept (for now) the following premises: - Full nodes are important for maintaining the health and robustness of the Bitcoin network - Full nodes do not all “upgrade” quickly - Full nodes have limited bandwidth, CPU power, etc. - Non-upgraded full nodes must not be allowed to “fall off the main chain.” Otherwise, they will a) be vulnerable to attacks b) form a “split currency” which threatens the economic stability
How can we “Soft Fork” to add a new signature type? <oldsig> | <pubkey> OP_CHECKSIGVERIFY Occasional old-style blocks, This OpCode exists, but has no effect. get discarded In the old rules, anyone can spend this! OP_UNUSED1 <newsig> | <pubkey> OP_CHECKSIGVERIFY
To recap: Hard forks are a “loosening” of the rules - Un-upgraded full nodes view new blocks as “invalid”, find themselves on weaker/smaller divergent chain Soft forks are a “narrowing” of the rules, but a “loosening” of conventions - Un-upgraded nodes will still view the new chain as valid - Un-upgraded miners waste hashpower on invalid blocks - What happens if someone already uses “unused” opcode?
Measuring consensus with a “flag day” - Miners signal their “support” for an upgrade. Once this support reaches a threshold percentage, the upgrade is “committed”. If the threshold is not reached by a deadline, the upgrade is “canceled” - After the threshold is established, there is a delay (weeks? months?) to leave time for full nodes to upgrade as well.
SegWit (Segregated Witness): A soft-fork Bitcoin upgrade that introduces a new signature type - Improves transaction verification performance - Fixes “transaction malleability”, needed for future upgrades (Lightning Network) - Modest increase in transaction capacity (up to 1.7x, depending on wallet support) - Currently pending activation
Recommend
More recommend
