Mechanising Blockchain Consensus George Pîrlea and Ilya Sergey Monday, 8 January 2018 CPP2018 1
Context • Hundreds of deployed public blockchains • $600 625 675 735 755 780 820 billion total market cap (7 day progression since Jan 1 st ) Monday, 8 January 2018 CPP2018 2
This work • Formalised a blockchain consensus protocol in Coq • Proved eventual consistency in a clique topology Monday, 8 January 2018 CPP2018 3
Motivation 1. Understand blockchain consensus • what it is • how it works: example • why it works: our formalisation 2. Lay foundation for verified practical implementation • verified Byzantine-tolerant consensus layer Future work • platform for verified smart contracts Monday, 8 January 2018 CPP2018 4
What it does Monday, 8 January 2018 CPP2018 5
transactions can • transforms a set of be anything consensus protocol transactions into a blockchain globally-agreed sequence • “distributed timestamp server” (Nakamoto2008) Monday, 8 January 2018 CPP2018 6
Monday, 8 January 2018 CPP2018 7
Monday, 8 January 2018 CPP2018 8
GB = genesis block Monday, 8 January 2018 CPP2018 9
How it works Monday, 8 January 2018 CPP2018 10
what everyone eventually agrees on • distributed • multiple nodes view of all participants’ state • all start with same GB Monday, 8 January 2018 CPP2018 11
• distributed • multiple nodes • message-passing over a network • all start with same GB Monday, 8 January 2018 CPP2018 12
• distributed • multiple nodes • message-passing over a network • all start with same GB • have a transaction pool Monday, 8 January 2018 CPP2018 13
• distributed • multiple nodes • message-passing over a network • all start with same GB • have a transaction pool • can mint blocks Monday, 8 January 2018 CPP2018 14
• distributed => concurrent • multiple nodes • message-passing over a network • multiple transactions can be issued and propagated concurrently Monday, 8 January 2018 CPP2018 15
• distributed => concurrent • multiple nodes • message-passing over a network • blocks can be minted without full knowledge of all transactions Monday, 8 January 2018 CPP2018 16
• chain fork has happened, but nodes don’t know Monday, 8 January 2018 CPP2018 17
• as block messages propagate, nodes become aware of the fork Monday, 8 January 2018 CPP2018 18
Problem: need to choose • blockchain “promise” = one globally-agreed chain • each node must choose one chain • nodes with the same information must choose the same chain Monday, 8 January 2018 CPP2018 19
Problem: need to choose • blockchain “promise” = one globally-agreed chain • each node must choose one chain • nodes with the same information must choose the same chain Monday, 8 January 2018 CPP2018 20
Problem: need to choose • blockchain “promise” = one globally-agreed chain • each node must choose one chain • nodes with the same information must choose the same chain Monday, 8 January 2018 CPP2018 21
Problem: need to choose • blockchain “promise” = one globally-agreed chain • each node must choose one chain • nodes with the same information must choose the same chain Monday, 8 January 2018 CPP2018 22
Solution: fork choice rule • Fork choice rule (FCR, >): • given two blockchains, says which one is “heavier” • imposes a strict total order on all possible blockchains • same FCR shared by all nodes • Nodes adopt “heaviest” chain they know Monday, 8 January 2018 CPP2018 23
FCR (>) … > [GB, A, C] > … > [GB, A, B] > … > [GB, A] > … > [GB] > … Bitcoin: FCR based on “most cumulative work” Monday, 8 January 2018 CPP2018 24
Quiescent consistency • distributed • multiple nodes • all start with GB • message-passing over a network • equipped with same FCR • quiescent consistency: when all block messages have been delivered, everyone agrees Monday, 8 January 2018 CPP2018 25
Why it works Monday, 8 January 2018 CPP2018 26
Definitions • blocks, chains, block forests Parameters and • hashes are collision-free • FCR imposes strict total order assumptions Invariant • local state + messages “in flight” = global Quiescent • when all block messages are delivered, consistency everyone agrees Monday, 8 January 2018 CPP2018 27
Blocks and chains links blocks together proof that this block proof-of-work was minted in accordance to the proof-of-stake rules of the protocol Monday, 8 January 2018 CPP2018 28
Minting and verifying try to generate a proof = “ask the protocol for permission” to mint validate a proof = ensure protocol rules were followed Monday, 8 January 2018 CPP2018 29
Resolving conflict Monday, 8 January 2018 CPP2018 30
Assumptions • Hash functions are collision-free • FCR imposes a strict total order on all blockchains Monday, 8 January 2018 CPP2018 31
Invariant: local state + “in - flight” = global global system step Monday, 8 January 2018 CPP2018 32
Invariant: local state + “in - flight” = global global system step Monday, 8 January 2018 CPP2018 32
Invariant is inductive invariant holds state 1 system step invariant holds state 2 state 3 system step invariant holds system step state 4 invariant holds system step invariant holds state 5 Monday, 8 January 2018 CPP2018 34
Invariant implies QC • QC: when all blocks delivered, everyone agrees How: • local state + “in - flight” = global • use FCR to extract “heaviest” chain out of local state • since everyone has same state & same FCR ➢ consensus Monday, 8 January 2018 CPP2018 35
Reusable components • Reference implementation of block forests • Per-node protocol logic • Network semantics • Clique invariant, QC property, various theorems https://github.com/certichain/toychain Monday, 8 January 2018 CPP2018 36
Future work • Network semantics with nodes joining/leaving at will • Improved invariants: • non-clique topologies • network partitions • Byzantine faults • Verified smart contracts platform Monday, 8 January 2018 CPP2018 37
Take away • Formalisation of a blockchain consensus protocol in Coq: • minimal set of required security primitives • per-node protocol logic & data structures • network semantics • global eventual consistency in a clique topology https://github.com/certichain/toychain Monday, 8 January 2018 CPP2018 38
Recommend
More recommend
