Analysis of the Blockchain Protocol with Long Delays Pu Puwen We - PowerPoint PPT Presentation

Analysis of the Blockchain Protocol with Long Delays Pu Puwen We Wei 1 , Quan Yuan 1 , Yuliang Zheng 2 1. Shandong University Key Lab of Cryptologic T echnology and Information Security, Ministry of Education 2. University of Alabama at Birmingham

Nakamoto’s blockchain n Bitcoin introduced by Nakamoto in 2008 Ø Decentralized payment system l Ledger maintained by the public in a decentralized manner l Attractive properties Ø Decentralization, Pseudonymity, Robustness … 2

Nakamoto’s blockchain n Blockchain Ø Chain-structured ledger maintained by all the participants (miners) l Blocks can only be added to the end of the chain Ø Basic security requirement l All the miners maintain the same record l Achieve co consensus in the pe perm rmissionl nless setting B 2 B 3 B 1 permissionless anyone can join (or leave) B 2 B 1 B 3 the protocol execution B’ 2 B’ 3 B 1 3

Nakamoto’s blockchain n Proof of work (POW) H(h |𝑛 ? < 𝐸 Ø Solve a “cryptographic puzzle” l Integrity ： More difficult for the adversary to modify the chain l Synchronism ： help the distributed miners to synchronize Ø Slowdown the generation of blocks Ø Longest chain rule Bitcoin Backbone Protocol [GKL15] blockchain C=( 𝐶 " , 𝐶 $ , … , 𝐶 & ) block 𝐶 ( = (ℎ (,$ , 𝑛 ( , 𝑠 ( , ℎ ( ) ℎ ( = 𝐼(ℎ (,$ ||𝑛 ( | 𝑠 ( , s. t. ℎ ( <D 4/47

Nakamoto’s blockchain Common prefix Chain growth Chain quality n Security Ø Garay, Kiayias and Leonardos [GKL15] provide a rigorous analysis of blockchain protocol l Synchronous model Ø Pass, Seeman and shelat [PSS17] analyze the security in an asynchronous network with a-priori bounded delay l Asynchronous model Why consider the delay? 5

Blockchain protocol with delays n Bitcoin P2P network Ø Delays are inevitable New block n The propagation delay in the network is the primary cause for blockchain forks [DW13] 6

Blockchain protocol with delays n Adversary in [PSS17] ($,B)C $DCE ， where 𝑔 ≈ 𝑜𝑞 • Chain growth: Responsible for the all message delivery Ø • Consistency: 𝑈 with probability 1 − 𝑜𝑓𝑕𝑚(𝑈) • All the message can be delayed within Δ PQ($DCE) • Chain quality: 1 − (1 + 𝜗) C rounds Has certain factions of hash power Ø Limitation: 𝜠 ≪ 𝑷(𝟐/𝒐𝒒) • The proof holds for a relatively small delay only 𝑜 : the number of miners within △ rounds 𝑞 : the probability that a miner succeeds Adversary New block in mining a block at a round 𝜠 silence 𝜠 silence Corrupted miners unique success Convergence opportunity 7

Blockchain potocol with delays n In In th the r e rea eal w wor orld, lo long ng de dela lays, say ∆ ∆ ≥ 1 /n /np , , could be ca caused easily! “bad” asynchronous networks, equipment failure,… Ø Ø malicious attacks l eclipse attacks [HKZG15], which allow an adversary to control 32 IP addresses to monopolize all connections to and from a target bitcoin node with 85% probability Eclipse attacks [HKZG15] 8

Blockchain protocol with delays . Is the blockchain protocol based on POW still secure in the asynchronous network, where long delay, say Δ ≥ 1 /np , is allowed? 9

Our contribution n Focus on the effect of long delay, especially Δ ≥ 1 /np Ø Prove that the common prefix property and the chain growth property can still hold in our model when considering long delay l define chain growth and common prefix in a more subtle way l simplified proof method for POW based blockchain Within △ rounds with probability α New block Adversary Distribution 10

Our blockchain model α 1-α n The adversary A 0 1 Ø Deliver all messages sent by miners Ø Delay the target chains with pr proba babi bility α next round within Δ round hin Δ ro l Wit Within rounds Ø Do not have any hash power New block Adversary delayed New block 11

Our blockchain model n Modification to blockchain protocol Ø Consecutive blocks cannot be mined by the same miner (not the same mining pool) l a single miner Ø an independent communication node of the network Ø has a unit computational power Ø May lead to possible forks Ø In practice It is unlikely that a miner can mine two consecutive blocks l large number of miners n l small difficulty parameter p 12

Our blockchain model Too weak? n Honest miners setting Ø The adversary does not corrupt any miners (No hash power) Ø Our model captures a class of practical attacks in the real world n For the adversary in a large-scaled blockchain protocol Ø More difficult to control a sizable fraction of hashing power Ø Much easier to disrupt communications among miners Ø Present a concrete attack in which an adversary without any hash power may threaten the common prefix property 13

Security requirements n Ch Chain Growth Ø Previous work: the minimum length increase of all all ho hone nest m mine ners ’ chains during T rounds 3 3 3 1 3 Ø Our work: the length increase of the ma majority y of ho hone nest m mine ners ’ chains $ l majority 𝜇 ∈ ( T , 1] l Exclude the “bad” honest minority l Chain growth in [PSS17] is a special case of ours when λ = 1 14

Security requirements n Co Common Prefix Ø Previous work: Al All the honest miners have the sa same history (prefix) Ø Our work: Th The maj ajor orit ity of the honest miners have the sa same history l Allow so some miners’ chains to be inc incons nsis istent with the main chain $ l majority 𝜇 ∈ ( T , 1] 𝑼 B 2 B 3 B 1 B 4 B 5 B 6 B 2 B 3 B 6 B 1 B 4 B 5 15

Se Secur urit ity pr proof n How to capture the evolution of the main chains? 16

St State of of th the M e Main C Chain n Tree MC to capture the evolution of the main chains Ø Inspired by F tree model [PSS17], record all the branches (or forks) Ø Tree MC in our model l Only store the current state of the main chains l Delayed chains are not recorded in Tree MC l Basic operations: AddBlock, DeleteBlock 𝑛 " $ , 𝑛 $ $ ) 𝐷 $ = (𝑛 " , 𝑛 $ T , 𝑛 T T ) ($) (T) (W) 𝐷 T = (𝑛 " , 𝑛 $ 𝑛 $ 𝑛 $ 𝑛 $ W , 𝑛 T W ) 𝐷 W = (𝑛 " , 𝑛 $ W , 𝑛 T X ) 𝐷 X = (𝑛 " , 𝑛 $ ($) (T) (W) (X) 𝑛 T 𝑛 T 𝑛 T 𝑛 T 17

State of the St he Main ain Chain hain n AddBlock: $ , 𝑛 T $ , 𝑛 W $ ) and 𝐷 T = l When the adversary broadcasts 𝐷 $ = (𝑛 " , 𝑛 $ T , 𝑛 T T , 𝑛 W T ) (𝑛 " , 𝑛 $ 𝑛 " 𝑛 " ($) (T) (W) 𝑛 $ 𝑛 $ 𝑛 $ ($) (T) (W) 𝑛 $ 𝑛 $ 𝑛 $ ($) (T) 𝑛 T 𝑛 T (W) (X) 𝑛 T 𝑛 T ($) (T) (X) (W) 𝑛 T 𝑛 T 𝑛 T 𝑛 T ($) (T) 𝑛 W 𝑛 W 18

St State of the he Main ain Chain hain n DeleteBlock: l Remove the useless nodes 𝑛 " 𝑛 " ($) (T) (W) 𝑛 $ 𝑛 $ 𝑛 $ ($) (T) 𝑛 $ 𝑛 $ ($) (T) 𝑛 T 𝑛 T (W) (X) 𝑛 T 𝑛 T ($) (T) 𝑛 T 𝑛 T ($) (T) 𝑛 W 𝑛 W (T) ($) 𝑛 W 𝑛 W 19

Difference between Tree MC and the miners’ view n Each miner has their own view of the main chain, which may be different with Tree MC n In terms of chain growth and common prefix , the difference is negligible Ø Reduced to the security of Tree MC Ø Simple proof for Tree MC l Useful properties on the depth of Tree MC 20

Security proof n Ch Chain Gr Growth Main idea of proof 21

Security proof n Co Common Pr Prefix Main idea of proof The event converge • Only one miner succeeds in mining at round r ∗ . • C ∗ is delayable while there is no new block mined in following Δ rounds OR The chain C ∗ is undelayable Pr 𝐝𝐩𝐨𝐰𝐟𝐬𝐡𝐟 > 1 − 𝑜𝑞(1 + 𝛽Δ) For Tree MC with common prefix of depth d-T h 1 − 𝑜𝑞 1 + 𝛽Δ 22

Lo Long Delay y Attack k on Co Common Prefix n Concrete attack on the common prefix of Tree MC Ø when Δ and α are “too” large relative to a fixed T Ø Goal of attack: increase the length of the two branches by T 23

Lo Long Delay y Attack k on Co Common Prefix Ø With inappropriate parameters, adversaries without any hash power can threaten the common prefix property For α = 0 . 8 and T = 6, the success probability increases as Δ n gets larger. the success probability grows much faster when Δ > 60 (10 min). When Δ > 120 (20 min), the success probability can reach about 1%. 24

Future work n Stronger security model Ø Convert honest miner setting to regular miner setting n Robustness of blockchain for data storage Ø Provide reliable storage with provable robustness 25

School of Cyber Security Shandong University, Qingdao Welcome to visit! & Welcome to join us! pwei@sdu.edu.cn

Thanks! & Questions? 27