Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Systems Research Challenges Workshop, 16th-17th January


Published on

Systems Research Challenges Workshop, 16th-17th January

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Systems Research Challenges Workshop, 16th-17th January

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  13. 13. Challenges • Say, n = 4, H3 and H4 are malicious • Correct hosts form non-identical B: B1 != B2 13 H1 H2 H4H3 B1|Sig_1 B2|Sig_2 B2|Sig_3 Bag = [B1, B2, B1, B1] B1|Sig_3 B1|Sig_4 B2|Sig_4 Bag = [B1, B2, B2, B2] Any deterministic Choice on Bag will differ for H1 and H2
  14. 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. 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. 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. 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