Systems Research Challenges Workshop, 16th-17th January

1. Blockchain Primer + Consensus Challenge • BC Primer – Tracking asset ownership transfers – Role of (Idealised) Scrooge in BC maintenance • E-Scrooge: Realization of Scrooge – Consensus through Incentives (Bitcoin) – Unstable – Consensus by a Collegium of hosts • Centralised (HyperLedger) – Termination issues? • Decentralised (randomised) – Performance? 1

2. Blockchain • Blockchain is an append-only ledger recording agreed asset transfers • G generates an asset • G then transfers the asset to Alice • Alice then transfers it to Bob • Register is immutable (even if G and Alice co-opt to undermine Bob) Asset Generation Evidence Declaration by G Tfr to Alice Tfr to Bob Declaration by Alice Declaration by G 2

3. Basics • Hash Function (SHA-256) • Hash Pointer, H(D) points to data D and also contains H(D) • Public-Key Cryptosystems U identified by her public key PK_U 3

4. Block Chain Linearity • G generates an asset (PK_G: pub key of G) • G then transfers asset to Alice (PK_A) • Alice then transfers it to Bob (PK_B) • Alice can record double-sell to Cindy (PK_C) Asset Generation Evidence Signed by G using SK_G Tfr to PK_A: H( ) Signed by G using SK_G Tfr to PK_B: H( ) Signed by Alice using SK_A Tfr to PK_C: H( ) Signed by Alice using SK_A X X Double-sell thwarted by Scrooge overseeing Blockchain growth 4

5. Scrooge • A dependable trusted party that – Receives asset-transfer notifications (transactions) – Puts a total (or linear) order on them – Validates ordered transactions – Groups validated transactions into a Block – Links a new block with the latest in Blockchain • multiple-sells – Concurrent transfers on a given asset – Get total ordered and all but the first invalidated 5

6. Blockchain Growth • Block-0 (Genesis) is known to all; so its Hash • Block-b consists of – Hash(Bb-1), timestamp, {transactions}, SigSc, H(Bb) Trans Prev_H() Genesis G owns Asset ….. Trans Timestamp; Sig of Scrooge Block 1 H(B1) Trans Prev_H() G Tfrs Asset to Alice ….. Trans Timestamp; Sig of Scrooge Block 2 H(B2) Trans Prev_H() Alice Tfrs to Bob ….. Trans Timestamp; Sig of Scrooge Block 3 H(B3) 6

7. E-Scrooge: implementing Scrooge • Scrooge replicated on multiple, autonomous agents that identically – order transactions – form blocks to be linked to Blockchain • Untrustworthy agents’ behaviour to be masked – A well-studied Byzantine fault tolerant, replication management problem – With new challenges of Scalability/Performance • JACM (1996): Equivalent are • Total (or linear) ordering • Reaching consensus, and • Atomic broadcast • JACM (1985): Impossible to design a deterministic solution that guarantees consensus in a bounded termination time – Randomized solutions guarantee eventual termination 7

8. Bitcoin Consensus • Of many anonymous miners, one is randomly chosen to form and link a new block, say, Block b • rewards himself with 25 BTC ( as a transaction) in b • And, importantly, does Proof of Work (PoW) 8 { "hash":"00000000000000f38...", "prev_block":"00000000000000c6d...", "time":1354114900, "difficulty":436527338, "nonce":282240624, "tx":[ {”hash":"5ca...", "in":[ {"prev_out": {"hash":"000...",}, ... ] } 14 Leading Zeros

9. PoW for Random Choice • PoW: discover a nonce such that – H(Block Data|nonce) has at least 14 leading zeros in hex – Brute force – Given Block Data (prev-hash, Transactions, etc) is fixed, expected number of attempts > 24X14 = 256 • Many miners may [un]knowingly be working on b to earn 25 BTC • One who finishes first is the chosen one 9

10. Forks and eventual linearity • What if two miners simultaneously finish building b, with distinct transactions? – a fork occurs. • Solution: – miner of (b+1) links his new block after • the longest valid ‘fork’ or a randomly selected one if all valid forks are of equal length – The probability of only one fork emerging as the longest increases exponentially with depth • eventually linear stability – A Block b in BC is ‘confirmed’ in Bitcoin if it is followed by at least 6 other blocks – If b with ‘Alice to Bob’ is followed by 6 blocks, then • the probability of b with ‘Alice to Cindy’ also being followed by 6 blocks, is very close to 0 • Bitcoin choice of 6 is heuristic (no finite number can guarantee fork elimination) – Minors of blocks in losing fork(s) get no reward despite their hard work 10 b-1 b b b+1 b+2 b+3 b+4 b+5A->B A->C

11. Bitcoin against adversaries Kroll, Davey & Felten: The Economics of Bitcoin Mining. Economics of Info. Security, 2013. • Bitcoin cannot be governance-free • Prone to mining cartels exploiting fork resolution – Goldfinger attack • Summary – Bitcoin consensus is unstable due to permitting and subsequent handling of forks 11

12. Consensus by Collegium of hosts • Hosts H1, H2, .. Hn implement Scrooge – All correct hosts maintain identical copies of BC – 1-copy abstraction • Say, latest Block is b-1 and a correct host Hj – collects a set TSj of transactions it sees, and – forms Bj as its candidate for Block b • Correct hosts agree which candidate B becomes b in BC • Fortuitous situation: all Hj are correct, collect identical TSj & compose identical Bj; 12

14. Fix Requires.. • At most f hosts to get malicious in interval T f < n/3 n=4, so f < 1.3, f = 1 • More than one consultation round • PoW equivalent: b with (n-f) host signatures • Ensuring f < n/3 beyond T requires proactive rejuvenation of hosts 14

15. Centralised Consensus • One host acts as the coordinator • +ve: three consultation rounds • -ve: high latencies if coordinator not correct or not be seen to be correct by other hosts – A network adversary can make it non-terminating • Canonical work: Practical Byzantine Fault Tolerant Consensus, Castro & Liskov, 2002 15

16. Decentralised/Randomized Consensus • Multiple rounds • At the start of each round, – honest host randomly picks a B from all known candidates – Let p = prob that all honest hosts choose the same B • Good eventually happens: (1-p)r = 0 as r  • -ve: more than 3 rounds possible for termination • +ve eventual termination guaranteed – resilient to network adversary 16

17. Selected Works • 1982: Lamport. Byzantine Generals Problem (TOPLAS) – Malicious hosts + well-defined network behaviour • 1983: Ben-Or. Randomized Consensus – Malicious Hosts, Adversarial Network, B is binary • 1985: N Lynch. FLP Impossibility (JACM) – No bounded termination for consensus on adversarial network even if hosts can only crash – Cannot escape eventual termination when adversary can delay network traffic • 1986: Ezhilchelvan. Early Terminating Consensus (SRDS) – Crash-only hosts, benign network. • 2001: Ezhilchelvan, Raynal. Randomized Consensus – Crash-only hosts, adversarial network. • 2002: Liskov. Deterministic Consensus. – Malicious Hosts, eventually cooperative network – Zookeeper its Crash-only versions • 2006: Ezhilchelvan. Consensus when n > 6 (max no of malicious hosts) – Bounded termination through fault-reduction, adversarial network • 2011: Ezhilchelvan. Randomised consensus on MANET – Crash-only wireless hosts, eventually partition-free network. • 2016: Raynal. Randomised Consensus (TPDS) – Malicious Hosts, adversarial network network 17

Systems Research Challenges Workshop, 16th-17th January

Systems Research Challenges Workshop, 16th-17th January

Recommended

More Related Content

Recently uploaded

Recently uploaded(20)

Featured

Featured(20)

Systems Research Challenges Workshop, 16th-17th January