bolt Bitcoin Whitepaper — ต้นฉบับ

Bitcoin: ระบบเงินสดอิเล็กทรอนิกส์
แบบ Peer-to-Peer

Satoshi Nakamoto · [email protected] · www.bitcoin.org · 2008
บทคัดย่อ. ระบบเงินสดอิเล็กทรอนิกส์แบบ peer-to-peer ล้วนๆ จะช่วยให้การชำระเงินออนไลน์ถูกส่งโดยตรงจากฝ่ายหนึ่งไปยังอีกฝ่ายหนึ่งโดยไม่ต้องผ่านสถาบันการเงิน ลายเซ็นดิจิทัลเป็นส่วนหนึ่งของคำตอบ แต่ประโยชน์หลักจะสูญหายไปหากยังต้องมีบุคคลที่สามที่เชื่อถือได้เพื่อป้องกันการใช้จ่ายซ้ำ เรานำเสนอวิธีแก้ปัญหาการใช้จ่ายซ้ำโดยใช้เครือข่าย peer-to-peer เครือข่ายจะประทับเวลาให้กับธุรกรรมโดยการแฮชลงในห่วงโซ่ของ proof-of-work ที่อิงแฮชอย่างต่อเนื่อง ทำให้เกิดบันทึกที่ไม่สามารถเปลี่ยนแปลงได้โดยไม่ต้องทำ proof-of-work ใหม่ ห่วงโซ่ที่ยาวที่สุดไม่เพียงแต่เป็นหลักฐานของลำดับเหตุการณ์ที่เกิดขึ้น แต่ยังเป็นหลักฐานว่ามาจากกลุ่มพลัง CPU ที่ใหญ่ที่สุด ตราบใดที่พลัง CPU ส่วนใหญ่ถูกควบคุมโดยโหนดที่ไม่ร่วมมือกันโจมตีเครือข่าย พวกเขาจะสร้างห่วงโซ่ที่ยาวที่สุดและแซงหน้าผู้โจมตี เครือข่ายเองต้องการโครงสร้างน้อยที่สุด ข้อความถูกกระจายแบบ best effort และโหนดสามารถออกและกลับเข้าร่วมเครือข่ายได้ตามต้องการ โดยยอมรับห่วงโซ่ proof-of-work ที่ยาวที่สุดเป็นหลักฐานของสิ่งที่เกิดขึ้นในขณะที่พวกเขาออกไป

1.บทนำ

การพาณิชย์บนอินเทอร์เน็ตได้พึ่งพาสถาบันการเงินเป็นบุคคลที่สามที่เชื่อถือได้ในการประมวลผลการชำระเงินอิเล็กทรอนิกส์เกือบทั้งหมด แม้ว่าระบบจะทำงานได้ดีพอสำหรับธุรกรรมส่วนใหญ่ แต่ก็ยังประสบกับจุดอ่อนโดยธรรมชาติของโมเดลที่อิงความเชื่อถือ ธุรกรรมที่ไม่สามารถย้อนกลับได้อย่างสมบูรณ์ไม่สามารถทำได้จริง เนื่องจากสถาบันการเงินไม่สามารถหลีกเลี่ยงการไกล่เกลี่ยข้อพิพาทได้ ค่าใช้จ่ายในการไกล่เกลี่ยเพิ่มต้นทุนธุรกรรม จำกัดขนาดธุรกรรมขั้นต่ำที่ใช้งานได้จริง และตัดความเป็นไปได้สำหรับธุรกรรมเล็กๆ ทั่วไป และมีต้นทุนที่กว้างขึ้นในการสูญเสียความสามารถในการชำระเงินที่ไม่สามารถย้อนกลับสำหรับบริการที่ไม่สามารถย้อนกลับได้ ด้วยความเป็นไปได้ของการย้อนกลับ ความจำเป็นในการเชื่อถือจึงแพร่กระจาย ผู้ค้าต้องระวังลูกค้าของตน รบกวนขอข้อมูลมากกว่าที่จำเป็น อัตราการฉ้อโกงบางส่วนถูกยอมรับว่าเป็นสิ่งที่หลีกเลี่ยงไม่ได้ ต้นทุนและความไม่แน่นอนในการชำระเงินเหล่านี้สามารถหลีกเลี่ยงได้โดยใช้เงินสดทางกายภาพเมื่อพบหน้ากัน แต่ไม่มีกลไกใดที่จะชำระเงินผ่านช่องทางการสื่อสารโดยไม่มีบุคคลที่เชื่อถือได้

สิ่งที่จำเป็นคือระบบการชำระเงินอิเล็กทรอนิกส์ที่อิงการพิสูจน์เชิงเข้ารหัสแทนความเชื่อถือ ทำให้สองฝ่ายที่เต็มใจสามารถทำธุรกรรมโดยตรงต่อกันโดยไม่ต้องมีบุคคลที่สามที่เชื่อถือได้ ธุรกรรมที่ยากต่อการย้อนกลับในเชิงคำนวณจะปกป้องผู้ขายจากการฉ้อโกง และกลไก escrow ทั่วไปสามารถนำมาใช้เพื่อปกป้องผู้ซื้อได้ง่าย ในเอกสารนี้ เรานำเสนอวิธีแก้ปัญหาการใช้จ่ายซ้ำโดยใช้เซิร์ฟเวอร์ประทับเวลาแบบกระจาย peer-to-peer เพื่อสร้างการพิสูจน์เชิงคำนวณของลำดับเวลาของธุรกรรม ระบบจะปลอดภัยตราบใดที่โหนดที่ซื่อสัตย์ร่วมกันควบคุมพลัง CPU มากกว่ากลุ่มโหนดผู้โจมตีที่ร่วมมือกัน

2.ธุรกรรม

เรากำหนดเหรียญอิเล็กทรอนิกส์เป็นห่วงโซ่ของลายเซ็นดิจิทัล เจ้าของแต่ละคนโอนเหรียญไปยังคนถัดไปโดยการเซ็นแฮชของธุรกรรมก่อนหน้าและคีย์สาธารณะของเจ้าของถัดไปแบบดิจิทัล และเพิ่มสิ่งเหล่านี้ที่ท้ายเหรียญ ผู้รับชำระเงินสามารถตรวจสอบลายเซ็นเพื่อยืนยันห่วงโซ่ความเป็นเจ้าของ

ปัญหาคือผู้รับชำระเงินไม่สามารถตรวจสอบได้ว่าเจ้าของคนใดคนหนึ่งไม่ได้ใช้จ่ายซ้ำกับเหรียญ วิธีแก้ปัญหาทั่วไปคือการแนะนำหน่วยงานกลางที่เชื่อถือได้ หรือโรงกษาปณ์ ที่ตรวจสอบทุกธุรกรรมเพื่อหาการใช้จ่ายซ้ำ หลังจากแต่ละธุรกรรม เหรียญต้องถูกส่งคืนให้โรงกษาปณ์เพื่อออกเหรียญใหม่ และเฉพาะเหรียญที่ออกโดยตรงจากโรงกษาปณ์เท่านั้นที่เชื่อถือได้ว่าไม่ถูกใช้จ่ายซ้ำ ปัญหาของวิธีนี้คือชะตากรรมของระบบเงินทั้งหมดขึ้นอยู่กับบริษัทที่ดำเนินการโรงกษาปณ์ โดยทุกธุรกรรมต้องผ่านพวกเขา เหมือนกับธนาคาร

เราต้องการวิธีให้ผู้รับชำระเงินรู้ว่าเจ้าของก่อนหน้าไม่ได้เซ็นธุรกรรมก่อนหน้านี้ สำหรับวัตถุประสงค์ของเรา ธุรกรรมแรกสุดคือธุรกรรมที่นับ ดังนั้นเราไม่สนใจความพยายามใช้จ่ายซ้ำในภายหลัง วิธีเดียวที่จะยืนยันว่าไม่มีธุรกรรมคือการรู้จักธุรกรรมทั้งหมด ในโมเดลที่อิงโรงกษาปณ์ โรงกษาปณ์รู้จักธุรกรรมทั้งหมดและตัดสินใจว่าธุรกรรมใดมาถึงก่อน เพื่อให้สำเร็จโดยไม่มีบุคคลที่เชื่อถือได้ ธุรกรรมต้องถูกประกาศต่อสาธารณะ [1] และเราต้องการระบบให้ผู้เข้าร่วมตกลงกันในประวัติศาสตร์เดียวของลำดับที่ได้รับ ผู้รับชำระเงินต้องการหลักฐานว่าในเวลาของแต่ละธุรกรรม โหนดส่วนใหญ่เห็นพ้องว่ามันเป็นธุรกรรมแรกที่ได้รับ

3.เซิร์ฟเวอร์ประทับเวลา

วิธีแก้ที่เราเสนอเริ่มต้นด้วยเซิร์ฟเวอร์ประทับเวลา เซิร์ฟเวอร์ประทับเวลาทำงานโดยการแฮชบล็อกของรายการที่จะประทับเวลาและเผยแพร่แฮชอย่างกว้างขวาง เช่น ในหนังสือพิมพ์หรือโพสต์ Usenet [2-5] การประทับเวลาพิสูจน์ว่าข้อมูลต้องมีอยู่แล้วในเวลานั้น อย่างชัดเจน เพื่อที่จะเข้าไปในแฮช การประทับเวลาแต่ละครั้งรวมการประทับเวลาก่อนหน้าในแฮชของมัน ทำให้เกิดห่วงโซ่ โดยการประทับเวลาเพิ่มเติมแต่ละครั้งเสริมความแข็งแกร่งให้กับอันก่อนหน้า

4.Proof-of-Work

เพื่อใช้เซิร์ฟเวอร์ประทับเวลาแบบกระจายบนพื้นฐาน peer-to-peer เราจะต้องใช้ระบบ proof-of-work คล้ายกับ Hashcash ของ Adam Back [6] แทนโพสต์หนังสือพิมพ์หรือ Usenet proof-of-work เกี่ยวข้องกับการสแกนหาค่าที่เมื่อแฮช เช่น ด้วย SHA-256 แฮชเริ่มต้นด้วยจำนวนบิตศูนย์ งานเฉลี่ยที่ต้องใช้เป็นเลขชี้กำลังตามจำนวนบิตศูนย์ที่ต้องการ และสามารถตรวจสอบได้โดยการรันแฮชเดียว

สำหรับเครือข่ายประทับเวลาของเรา เราดำเนินการ proof-of-work โดยการเพิ่ม nonce ในบล็อกจนกว่าจะพบค่าที่ทำให้แฮชของบล็อกมีบิตศูนย์ตามที่ต้องการ เมื่อใช้พลัง CPU เพื่อทำให้เป็นไปตาม proof-of-work แล้ว บล็อกไม่สามารถเปลี่ยนแปลงได้โดยไม่ต้องทำงานใหม่ เมื่อบล็อกถัดไปถูกเชื่อมต่อตามหลัง การทำงานเพื่อเปลี่ยนบล็อกจะรวมถึงการทำงานใหม่ทั้งหมดของบล็อกที่ตามมา

proof-of-work ยังแก้ปัญหาการกำหนดตัวแทนในการตัดสินใจเสียงส่วนใหญ่ หากเสียงส่วนใหญ่อิงหนึ่ง-IP-หนึ่งเสียง มันสามารถถูกทำลายโดยใครก็ตามที่สามารถจัดสรร IP จำนวนมากได้ proof-of-work โดยพื้นฐานคือหนึ่ง-CPU-หนึ่งเสียง การตัดสินใจเสียงส่วนใหญ่แสดงโดยห่วงโซ่ที่ยาวที่สุด ซึ่งมีงาน proof-of-work มากที่สุดลงทุนอยู่ หากพลัง CPU ส่วนใหญ่ถูกควบคุมโดยโหนดที่ซื่อสัตย์ ห่วงโซ่ที่ซื่อสัตย์จะเติบโตเร็วที่สุดและแซงหน้าห่วงโซ่ที่แข่งขันใดๆ เพื่อแก้ไขบล็อกในอดีต ผู้โจมตีต้องทำ proof-of-work ของบล็อกนั้นและบล็อกทั้งหมดที่ตามมาใหม่ แล้วตามให้ทันและแซงงานของโหนดที่ซื่อสัตย์ เราจะแสดงในภายหลังว่าความน่าจะเป็นที่ผู้โจมตีที่ช้ากว่าจะตามทันลดลงแบบเลขชี้กำลังเมื่อมีการเพิ่มบล็อกถัดไป

เพื่อชดเชยความเร็วฮาร์ดแวร์ที่เพิ่มขึ้นและความสนใจที่แตกต่างกันในการรันโหนดเมื่อเวลาผ่านไป ความยากของ proof-of-work ถูกกำหนดโดยค่าเฉลี่ยเคลื่อนที่ที่กำหนดเป้าหมายจำนวนบล็อกเฉลี่ยต่อชั่วโมง หากสร้างเร็วเกินไป ความยากจะเพิ่มขึ้น

5.เครือข่าย

ขั้นตอนในการรันเครือข่ายมีดังนี้:

  1. ธุรกรรมใหม่ถูกกระจายไปยังทุกโหนด
  2. แต่ละโหนดรวบรวมธุรกรรมใหม่เป็นบล็อก
  3. แต่ละโหนดทำงานเพื่อค้นหา proof-of-work ที่ยากสำหรับบล็อกของตน
  4. เมื่อโหนดพบ proof-of-work มันกระจายบล็อกไปยังทุกโหนด
  5. โหนดยอมรับบล็อกเฉพาะเมื่อธุรกรรมทั้งหมดในนั้นถูกต้องและยังไม่ถูกใช้จ่าย
  6. โหนดแสดงการยอมรับบล็อกโดยทำงานเพื่อสร้างบล็อกถัดไปในห่วงโซ่ โดยใช้แฮชของบล็อกที่ยอมรับเป็นแฮชก่อนหน้า

โหนดพิจารณาห่วงโซ่ที่ยาวที่สุดเป็นห่วงโซ่ที่ถูกต้องเสมอและจะทำงานเพื่อขยายมันต่อไป หากสองโหนดกระจายบล็อกถัดไปเวอร์ชันต่างกันพร้อมกัน บางโหนดอาจได้รับอันใดอันหนึ่งก่อน ในกรณีนั้น พวกเขาทำงานกับอันแรกที่ได้รับ แต่บันทึกสาขาอื่นไว้ในกรณีที่มันยาวขึ้น การเสมอกันจะถูกทำลายเมื่อพบ proof-of-work ถัดไปและสาขาหนึ่งยาวขึ้น โหนดที่ทำงานกับสาขาอื่นจะสลับไปยังสาขาที่ยาวกว่า

การกระจายธุรกรรมใหม่ไม่จำเป็นต้องถึงทุกโหนด ตราบใดที่มันถึงหลายโหนด พวกมันจะเข้าไปในบล็อกในไม่ช้า การกระจายบล็อกยังทนต่อข้อความที่หาย หากโหนดไม่ได้รับบล็อก มันจะขอเมื่อได้รับบล็อกถัดไปและรู้ว่าพลาดไปหนึ่งบล็อก

6.แรงจูงใจ

ตามธรรมเนียม ธุรกรรมแรกในบล็อกเป็นธุรกรรมพิเศษที่เริ่มเหรียญใหม่ซึ่งเป็นเจ้าของโดยผู้สร้างบล็อก สิ่งนี้เพิ่มแรงจูงใจให้โหนดสนับสนุนเครือข่าย และให้วิธีกระจายเหรียญเริ่มต้นเข้าสู่การหมุนเวียน เนื่องจากไม่มีหน่วยงานกลางในการออกเหรียญ การเพิ่มเหรียญใหม่จำนวนคงที่อย่างต่อเนื่องเปรียบเสมือนนักขุดทองที่ใช้ทรัพยากรเพื่อเพิ่มทองเข้าสู่การหมุนเวียน ในกรณีของเรา มันคือเวลา CPU และไฟฟ้าที่ใช้ไป

แรงจูงใจยังสามารถได้รับทุนจากค่าธรรมเนียมธุรกรรม หากมูลค่าผลลัพธ์ของธุรกรรมน้อยกว่ามูลค่าอินพุต ความแตกต่างคือค่าธรรมเนียมธุรกรรมที่เพิ่มเข้าไปในมูลค่าแรงจูงใจของบล็อกที่มีธุรกรรมนั้น เมื่อจำนวนเหรียญที่กำหนดไว้ล่วงหน้าเข้าสู่การหมุนเวียน แรงจูงใจสามารถเปลี่ยนเป็นค่าธรรมเนียมธุรกรรมทั้งหมดและไม่มีอัตราเงินเฟ้อโดยสิ้นเชิง

แรงจูงใจอาจช่วยส่งเสริมให้โหนดซื่อสัตย์ หากผู้โจมตีที่โลภสามารถรวบรวมพลัง CPU มากกว่าโหนดที่ซื่อสัตย์ทั้งหมด เขาจะต้องเลือกระหว่างใช้มันเพื่อฉ้อโกงผู้คนโดยการขโมยการชำระเงินคืน หรือใช้มันเพื่อสร้างเหรียญใหม่ เขาควรพบว่าการเล่นตามกฎมีกำไรมากกว่า กฎที่เอื้อประโยชน์ให้เขาได้รับเหรียญใหม่มากกว่าคนอื่นรวมกัน มากกว่าการทำลายระบบและความถูกต้องของความมั่งคั่งของเขาเอง

7.การเรียกคืนพื้นที่ดิสก์

เมื่อธุรกรรมล่าสุดในเหรียญถูกฝังใต้บล็อกเพียงพอ ธุรกรรมที่ใช้แล้วก่อนหน้านั้นสามารถทิ้งเพื่อประหยัดพื้นที่ดิสก์ เพื่ออำนวยความสะดวกนี้โดยไม่ทำลายแฮชของบล็อก ธุรกรรมถูกแฮชใน Merkle Tree [7][2][5] โดยมีเพียงรากที่รวมอยู่ในแฮชของบล็อก บล็อกเก่าสามารถถูกบีบอัดโดยการตัดกิ่งของต้นไม้ แฮชภายในไม่จำเป็นต้องเก็บ

ส่วนหัวบล็อกที่ไม่มีธุรกรรมจะประมาณ 80 ไบต์ หากเราสมมติว่าบล็อกถูกสร้างทุก 10 นาที 80 ไบต์ × 6 × 24 × 365 = 4.2MB ต่อปี ด้วยระบบคอมพิวเตอร์ที่มักขายพร้อม RAM 2GB ในปี 2008 และกฎของ Moore ทำนายการเติบโตปัจจุบัน 1.2GB ต่อปี พื้นที่จัดเก็บไม่ควรเป็นปัญหาแม้ว่าต้องเก็บส่วนหัวบล็อกในหน่วยความจำ

8.การตรวจสอบการชำระเงินแบบง่าย

เป็นไปได้ที่จะตรวจสอบการชำระเงินโดยไม่ต้องรันโหนดเครือข่ายเต็มรูปแบบ ผู้ใช้เพียงต้องเก็บสำเนาส่วนหัวบล็อกของห่วงโซ่ proof-of-work ที่ยาวที่สุด ซึ่งเขาสามารถได้รับโดยการสอบถามโหนดเครือข่ายจนกว่าเขาจะมั่นใจว่าเขามีห่วงโซ่ที่ยาวที่สุด และได้รับสาขา Merkle ที่เชื่อมโยงธุรกรรมกับบล็อกที่มันถูกประทับเวลา เขาไม่สามารถตรวจสอบธุรกรรมด้วยตัวเอง แต่โดยการเชื่อมโยงมันกับตำแหน่งในห่วงโซ่ เขาสามารถเห็นว่าโหนดเครือข่ายยอมรับมัน และบล็อกที่เพิ่มตามหลังยืนยันเพิ่มเติมว่าเครือข่ายยอมรับมัน

ดังนั้น การตรวจสอบเชื่อถือได้ตราบใดที่โหนดที่ซื่อสัตย์ควบคุมเครือข่าย แต่เสี่ยงมากขึ้นหากเครือข่ายถูกครอบงำโดยผู้โจมตี ในขณะที่โหนดเครือข่ายสามารถตรวจสอบธุรกรรมด้วยตัวเอง วิธีแบบง่ายสามารถถูกหลอกโดยธุรกรรมปลอมของผู้โจมตีตราบเท่าที่ผู้โจมตีสามารถครอบงำเครือข่ายต่อไป กลยุทธ์หนึ่งในการป้องกันคือการยอมรับการแจ้งเตือนจากโหนดเครือข่ายเมื่อพวกเขาตรวจจับบล็อกที่ไม่ถูกต้อง กระตุ้นให้ซอฟต์แวร์ของผู้ใช้ดาวน์โหลดบล็อกเต็มและธุรกรรมที่ถูกแจ้งเตือนเพื่อยืนยันความไม่สอดคล้อง ธุรกิจที่ได้รับการชำระเงินบ่อยครั้งอาจยังต้องการรันโหนดของตัวเองเพื่อความปลอดภัยอิสระและการตรวจสอบที่เร็วกว่า

9.การรวมและแยกมูลค่า

แม้ว่าจะเป็นไปได้ที่จะจัดการเหรียญทีละเหรียญ แต่ก็ยุ่งยากที่จะทำธุรกรรมแยกสำหรับทุกเซ็นต์ในการโอน เพื่อให้มูลค่าสามารถแยกและรวมได้ ธุรกรรมมีอินพุตและเอาต์พุตหลายรายการ โดยปกติจะมีอินพุตเดียวจากธุรกรรมก่อนหน้าที่ใหญ่กว่าหรือหลายอินพุตรวมจำนวนเล็กน้อย และอย่างมากสองเอาต์พุต: หนึ่งสำหรับการชำระเงิน และหนึ่งสำหรับเงินทอน หากมี กลับไปยังผู้ส่ง

ควรสังเกตว่า fan-out ซึ่งธุรกรรมขึ้นอยู่กับหลายธุรกรรม และธุรกรรมเหล่านั้นขึ้นอยู่กับอีกหลายรายการ ไม่ใช่ปัญหาที่นี่ ไม่มีความจำเป็นต้องแยกสำเนาประวัติธุรกรรมที่สมบูรณ์แบบสแตนด์อโลน

10.ความเป็นส่วนตัว

โมเดลธนาคารแบบดั้งเดิมบรรลุระดับความเป็นส่วนตัวโดยการจำกัดการเข้าถึงข้อมูลเฉพาะฝ่ายที่เกี่ยวข้องและบุคคลที่สามที่เชื่อถือได้ ความจำเป็นในการประกาศธุรกรรมทั้งหมดต่อสาธารณะตัดวิธีการนี้ แต่ความเป็นส่วนตัวยังคงรักษาได้โดยการทำลายการไหลของข้อมูลในอีกที่หนึ่ง: โดยการทำให้คีย์สาธารณะไม่เปิดเผยตัวตน สาธารณะสามารถเห็นว่ามีคนส่งจำนวนเงินให้คนอื่น แต่ไม่มีข้อมูลเชื่อมโยงธุรกรรมกับใคร นี่คล้ายกับระดับข้อมูลที่เผยแพร่โดยตลาดหลักทรัพย์ ซึ่งเวลาและขนาดของการซื้อขายรายบุคคล "เทป" ถูกเปิดเผยต่อสาธารณะ แต่ไม่บอกว่าฝ่ายใดเป็นใคร

เป็นไฟร์วอลล์เพิ่มเติม ควรใช้คู่คีย์ใหม่สำหรับแต่ละธุรกรรมเพื่อป้องกันไม่ให้เชื่อมโยงกับเจ้าของร่วม การเชื่อมโยงบางอย่างยังหลีกเลี่ยงไม่ได้กับธุรกรรมหลายอินพุต ซึ่งจำเป็นต้องเปิดเผยว่าอินพุตของพวกเขาเป็นของเจ้าของเดียวกัน ความเสี่ยงคือหากเจ้าของคีย์ถูกเปิดเผย การเชื่อมโยงอาจเปิดเผยธุรกรรมอื่นที่เป็นของเจ้าของเดียวกัน

11.การคำนวณ

เราพิจารณาสถานการณ์ของผู้โจมตีที่พยายามสร้างห่วงโซ่ทางเลือกเร็วกว่าห่วงโซ่ที่ซื่อสัตย์ แม้ว่าจะสำเร็จ มันไม่ได้เปิดระบบให้เปลี่ยนแปลงตามอำเภอใจ เช่น การสร้างมูลค่าจากอากาศหรือการเอาเงินที่ไม่เคยเป็นของผู้โจมตี โหนดจะไม่ยอมรับธุรกรรมที่ไม่ถูกต้องเป็นการชำระเงิน และโหนดที่ซื่อสัตย์จะไม่ยอมรับบล็อกที่มีธุรกรรมเหล่านั้น ผู้โจมตีสามารถพยายามเปลี่ยนธุรกรรมของตัวเองหนึ่งรายการเพื่อเอาเงินที่เขาเพิ่งใช้ไปคืน

การแข่งขันระหว่างห่วงโซ่ที่ซื่อสัตย์และห่วงโซ่ผู้โจมตีสามารถอธิบายเป็น Binomial Random Walk เหตุการณ์ความสำเร็จคือห่วงโซ่ที่ซื่อสัตย์ถูกขยายหนึ่งบล็อก เพิ่มนำหน้า +1 และเหตุการณ์ความล้มเหลวคือห่วงโซ่ของผู้โจมตีถูกขยายหนึ่งบล็อก ลดช่องว่าง −1

ความน่าจะเป็นที่ผู้โจมตีตามทันจากการขาดดุลที่กำหนดเปรียบเสมือนปัญหา Gambler's Ruin สมมติว่านักพนันที่มีเครดิตไม่จำกัดเริ่มต้นที่การขาดดุลและเล่นการทดลองจำนวนไม่จำกัดเพื่อพยายามถึงจุดคุ้มทุน เราสามารถคำนวณความน่าจะเป็นที่เขาเคยถึงจุดคุ้มทุน หรือที่ผู้โจมตีเคยตามทันห่วงโซ่ที่ซื่อสัตย์ ได้ดังนี้ [8]:

p  = ความน่าจะเป็นที่โหนดที่ซื่อสัตย์พบบล็อกถัดไป
q  = ความน่าจะเป็นที่ผู้โจมตีพบบล็อกถัดไป
qz = ความน่าจะเป็นที่ผู้โจมตีจะตามทันจาก z บล็อกที่ตามหลัง

         ⎧  1          ถ้า p ≤ q
qz =     ⎨
         ⎩ (q/p)^z    ถ้า p > q

จากสมมติฐานที่ว่า p > q ความน่าจะเป็นลดลงแบบเลขชี้กำลังเมื่อจำนวนบล็อกที่ผู้โจมตีต้องตามเพิ่มขึ้น ด้วยอัตราต่อรองที่ต่อต้านเขา หากเขาไม่พุ่งโชคดีไปข้างหน้าในช่วงต้น โอกาสของเขาจะเล็กมากเมื่อเขาตกตามหลังมากขึ้น

ตอนนี้เราพิจารณาว่าผู้รับธุรกรรมใหม่ต้องรอนานเท่าใดก่อนที่จะมั่นใจเพียงพอว่าผู้ส่งไม่สามารถเปลี่ยนธุรกรรมได้ เราสมมติว่าผู้ส่งเป็นผู้โจมตีที่ต้องการให้ผู้รับเชื่อว่าเขาจ่ายเงินให้ชั่วขณะหนึ่ง จากนั้นเปลี่ยนเป็นการจ่ายคืนให้ตัวเองหลังจากเวลาผ่านไป ผู้รับจะถูกแจ้งเตือนเมื่อสิ่งนั้นเกิดขึ้น แต่ผู้ส่งหวังว่ามันจะสายเกินไป

ผู้รับสร้างคู่คีย์ใหม่และให้คีย์สาธารณะแก่ผู้ส่งก่อนการลงนามไม่นาน ซึ่งป้องกันไม่ให้ผู้ส่งเตรียมห่วงโซ่บล็อกล่วงหน้าโดยทำงานต่อเนื่องจนกว่าเขาจะโชคดีพอที่จะนำหน้าได้มากพอ แล้วจึงทำธุรกรรมในขณะนั้น เมื่อธุรกรรมถูกส่งแล้ว ผู้ส่งที่ไม่ซื่อสัตย์จะเริ่มทำงานอย่างลับๆ บนห่วงโซ่คู่ขนานที่มีธุรกรรมเวอร์ชันอื่นของเขา

ผู้รับรอจนกว่าธุรกรรมจะถูกเพิ่มในบล็อกและมีบล็อก z บล็อกเชื่อมต่อตามหลัง เขาไม่ทราบจำนวนความคืบหน้าที่แน่นอนที่ผู้โจมตีทำได้ แต่สมมติว่าบล็อกที่ซื่อสัตย์ใช้เวลาเฉลี่ยตามที่คาดไว้ต่อบล็อก ความคืบหน้าที่เป็นไปได้ของผู้โจมตีจะเป็นการแจกแจงแบบปัวซงที่มีค่าคาดหวัง:

λ = z (q/p)

เพื่อหาความน่าจะเป็นที่ผู้โจมตียังสามารถตามทันได้ในตอนนี้ เราคูณความหนาแน่นปัวซงสำหรับแต่ละจำนวนความคืบหน้าที่เขาอาจทำได้ด้วยความน่าจะเป็นที่เขาจะตามทันจากจุดนั้น:

      ∞
      Σ   (λ^k e^−λ / k!) · (q/p)^(z−k)      if k ≤ z
     k=0

แปลงเป็นโค้ด C...

#include <math.h>
double AttackerSuccessProbability(double q, int z)
{
    double p = 1.0 - q;
    double lambda = z * (q / p);
    double sum = 1.0;
    int i, k;
    for (k = 0; k <= z; k++)
    {
        double poisson = exp(-lambda);
        for (i = 1; i <= k; i++)
            poisson *= lambda / i;
        sum -= poisson * (1 - pow(q / p, z - k));
    }
    return sum;
}

เมื่อรันผลลัพธ์บางส่วน เราจะเห็นว่าความน่าจะเป็นลดลงแบบเอกซ์โพเนนเชียลตามค่า z

q=0.1
z=0  P=1.0000000    z=5  P=0.0009137
z=1  P=0.2045873    z=6  P=0.0002428
z=2  P=0.0509779    z=7  P=0.0000647
z=3  P=0.0131722    z=8  P=0.0000173
z=4  P=0.0034552    z=9  P=0.0000046
                    z=10 P=0.0000012

q=0.3
z=0  P=1.0000000
z=5  P=0.1773523    z=30 P=0.0001522
z=10 P=0.0416605    z=35 P=0.0000379
z=15 P=0.0101008    z=40 P=0.0000095
z=20 P=0.0024804    z=45 P=0.0000024
z=25 P=0.0006132    z=50 P=0.0000006

แก้หา P น้อยกว่า 0.1%...
P < 0.001
q=0.10  z=5
q=0.15  z=8
q=0.20  z=11
q=0.25  z=15
q=0.30  z=24
q=0.35  z=41
q=0.40  z=89
q=0.45  z=340

12.บทสรุป

เราได้เสนอระบบสำหรับธุรกรรมอิเล็กทรอนิกส์โดยไม่ต้องพึ่งพาความเชื่อใจ เราเริ่มต้นด้วยกรอบปกติของเหรียญที่สร้างจากลายเซ็นดิจิทัล ซึ่งให้การควบคุมความเป็นเจ้าของที่แข็งแกร่ง แต่ไม่สมบูรณ์หากไม่มีวิธีป้องกันการใช้จ่ายซ้ำ เพื่อแก้ปัญหานี้ เราเสนอเครือข่ายแบบ peer-to-peer ที่ใช้ proof-of-work เพื่อบันทึกประวัติธุรกรรมสาธารณะ ซึ่งจะกลายเป็นเรื่องที่ computationally ไม่สามารถทำได้ในทางปฏิบัติสำหรับผู้โจมตีที่จะเปลี่ยนแปลง หากโหนดที่ซื่อสัตย์ควบคุมพลัง CPU ส่วนใหญ่ เครือข่ายมีความแข็งแกร่งในความเรียบง่ายที่ไม่เป็นระเบียบ โหนดทำงานพร้อมกันโดยมีการประสานงานน้อย พวกเขาไม่จำเป็นต้องถูกระบุตัวตน เนื่องจากข้อความไม่ได้ถูกส่งไปยังสถานที่เฉพาะ และเพียงต้องถูกส่งด้วยความพยายามที่ดีที่สุด โหนดสามารถออกและกลับเข้าร่วมเครือข่ายได้ตามต้องการ โดยยอมรับห่วงโซ่ proof-of-work เป็นหลักฐานของสิ่งที่เกิดขึ้นในขณะที่พวกเขาออกไป พวกเขาลงคะแนนด้วยพลัง CPU ของตน แสดงการยอมรับบล็อกที่ถูกต้องโดยทำงานเพื่อขยายมัน และปฏิเสธบล็อกที่ไม่ถูกต้องโดยไม่ทำงานกับมัน กฎและแรงจูงใจที่จำเป็นใดๆ สามารถบังคับใช้ได้ด้วยกลไกฉันทามตินี้

เอกสารอ้างอิง

[1] W. Dai, "b-money," http://www.weidai.com/bmoney.txt, 1998.

[2] H. Massias, X.S. Avila, and J.-J. Quisquater, "Design of a secure timestamping service with minimal trust requirements," In 20th Symposium on Information Theory in the Benelux, May 1999.

[3] S. Haber, W.S. Stornetta, "How to time-stamp a digital document," In Journal of Cryptology, vol 3, no 2, pages 99-111, 1991.

[4] D. Bayer, S. Haber, W.S. Stornetta, "Improving the efficiency and reliability of digital time-stamping," In Sequences II: Methods in Communication, Security and Computer Science, pages 329-334, 1993.

[5] S. Haber, W.S. Stornetta, "Secure names for bit-strings," In Proceedings of the 4th ACM Conference on Computer and Communications Security, pages 28-35, April 1997.

[6] A. Back, "Hashcash - a denial of service counter-measure," http://www.hashcash.org/papers/hashcash.pdf, 2002.

[7] R.C. Merkle, "Protocols for public key cryptosystems," In Proc. 1980 Symposium on Security and Privacy, IEEE Computer Society, pages 122-133, April 1980.

[8] W. Feller, "An introduction to probability theory and its applications," 1957.

Bitcoin whitepaper ต้นฉบับโดย Satoshi Nakamoto (2008) — จัดแสดงเพื่อการศึกษาโดย Lightning BTC
ดาวน์โหลด PDF ต้นฉบับ (bitcoin.org)