ระบบเงินอิเล็กทรอนิกส์แบบ peer-to-peer
ระบบเงินอิเล็กทรอนิกส์แบบ peer-to-peer นั้นจะช่วยให้เราสามารถชำระเงินผ่านทางออนไลน์ได้โดยตรงจากฝ่ายหนึ่งไปยังอีกฝ่ายหนึ่งโดยไม่ต้องผ่านตัวกลางอย่างพวกสถาบันการเงิน โดยใช้ digital signature เป็นส่วนหนึ่งในการแก้ปัญหานี้ แต่มันจะไม่มีประโยชน์ใด ๆ เลยหากยังคงต้องอาศัยตัวกลางที่เชื่อถือได้มาแก้ปัญหา double spending เราขอเสนอวิธีแก้ปัญหา double spending โดยใช้เครือข่ายแบบ peer-to-peer ให้เครือข่ายคอยประทับเวลาธุรกรรมต่าง ๆ ในระบบและนำมาเรียงร้อยกันเป็นเส้นสายของ proof-of-work ที่ใช้ hash เพื่อสร้างธุรกรรมที่ไม่สามารถเปลี่ยนแปลงได้ โดยไม่ต้องทำ proof-of-work ใหม่ โดยให้เส้นสายที่ยาวที่สุดนั้น ไม่เพียงแต่ทำหน้าที่เป็นลำดับของธุรกรรมที่เกิดขึ้นเท่านั้น แต่ยังเป็นสิ่งที่พิสูจน์ได้ว่ามาจากกำลังประมวลผล CPU ที่มากที่สุด และตราบใดที่ nodes ส่วนใหญ่ไม่ได้ร่วมมือกันโจมตีเครือข่ายและยังคงควบคุมกำลังประมวลผลส่วนใหญ่ในระบบไว้ พวกเขาก็จะสร้างเส้นสายที่ยาวที่สุดและสามารถเอาชนะผู้ประสงค์ร้ายที่จะโจมตีระบบได้ ตัวเครือข่ายเองไม่ได้ต้องมีโครงสร้างอะไรที่ซับซ้อน ข้อมูลต่าง ๆ ในเครือข่ายจะถูกกระจายส่งต่อโดยไม่ต้องสนใจว่าผู้รับจะได้รับหรือไม่ และ nodes ต่าง ๆ เองก็สามารถที่จะออกจากเครือข่ายและกลับเข้าร่วมใหม่ได้ตามที่ต้องการ โดยยอมรับเส้น proof-of-work ที่ยาวที่สุด เป็นหลักฐานของสิ่งที่เกิดขึ้นในขณะที่ node นั้น ๆ ไม่ได้อยู่ในเครือข่าย
1.บทนำ (Introduction)
ไม่ว่าใครจะใคร่ซื้อใคร่ขายอะไรใด ๆ บนอินเตอร์เน็ตนั้น ก็จำเป็นต้องพึ่งพาสถาบันการเงินในฐานะของบุคคลที่สามเพื่อดำเนินการชำระเงินทางอิเล็กทรอนิกส์เสมอ ๆ ซึ่งถึงแม้ว่าระบบนี้มันจะทำงานได้ดีสำหรับธุรกรรมส่วนใหญ่ ๆ แต่ระบบก็ก็มีจุดอ่อนอยู่ที่ยังต้องอาศัยความไว้เนื้อเชื่อใจ (trust) ในระบบนี้การทำธุรกรรมที่ไม่สามารถย้อนกลับได้อย่างสมบูรณ์นั้นมันแทบจะเป็นไปไม่ได้เลย เนื่องจากสถาบันการเงินไม่สามารถหลีกเลี่ยงการเป็นตัวกลางในการไกล่เกลี่ยข้อพิพาทต่าง ๆ ที่อาจเกิดขึ้นได้ มิหนำซ้ำต้นทุนในการไกล่เกลี่ยยังทำให้ต้นทุนการทำธุรกรรมเพิ่มสูงขึ้น และเมื่อต้นทุนสูงขึ้นขนาดของธุรกรรมที่สามารถใช้งานได้จริงก็สูงขึ้นตามไปด้วย ธุรกรรมเล็ก ๆ น้อย ๆ ก็ไม่สามารถเกิดขึ้นได้ เมื่อมีความเป็นไปได้ที่ธุรกรรมจะเกิดการย้อนกลับ ความจำเป็นในการสร้างความไว้วางใจก็ยิ่งทวีคูณมากขึ้น ผู้ค้าก็จำเป็นต้องระมัดระวังลูกค้า ต้องเรียกร้องข้อมูลมากกว่าที่จำเป็น การฉ้อโกงกลายเป็นเรื่องที่หลีกเลี่ยงไม่ได้เพราะต้นทุนและความไม่แน่นอนในทำธุรกรรมเหล่านี้ แน่นอนว่าเราสามารถหลีกเลี่ยงมันได้โดยการใช้เงินสด แต่ก็ไม่มีกลไกใดที่ทำให้สามารถใช้เงินสดผ่านช่องทางการสื่อสาร (เอาให้เข้าใจง่ายก็อินเตอร์เน็ต)ได้ โดยไม่ต้องมีตัวกลาง ;-;
แปลว่าสิ่งที่จำเป็นสำหรับการแก้ไขปัญหานี้คือระบบการชำระเงินทางอิเล็กทรอนิกส์ ที่อยู่บนพื้นฐานของการพิสูจน์ด้วยการเข้ารหัสแทนที่จะเป็นความไว้วางใจ ซึ่งจะทำให้คู่สัญญาสองฝ่ายที่ยินยอมสามารถทำธุรกรรมร่วมกันได้โดยตรง โดยไม่จำเป็นต้องมีบุคคลที่สามมาคอยเป็นตัวกลาง ธุรกรรมที่ยากต่อการย้อนกลับจะช่วยปกป้องผู้ขายจากการฉ้อโกง และสามารถใช้กลไก escrow เพื่อปกป้องผู้ซื้อได้อีกด้วย ในเอกสารชุดนี้ เราขอเสนอวิธีแก้ปัญหาการใช้จ่ายซ้ำซ้อนโดยใช้เซิร์ฟเวอร์ timestamp กระจายศูนย์แบบ peer-to-peer เพื่อสร้างหลักฐานการคำนวณลำดับเวลาของธุรกรรม โดยระบบนี้จะปลอดภัยตราบใดที่กลุ่มของ node ที่ซื่อสัตย์ ยังคงมีกำลังประมวลผลที่มากกว่ากลุ่มที่ประสงค์ร้ายกับระบบ
2.ธุรกรรม (Transactions)
นิยามของเหรียญอิเล็กทรอนิกส์ในที่นี้ คือห่วงโซ่ที่คล้องเกี่ยวกันของ digital signature โดยที่เจ้าของเหรียญอิเล็กทรอนิกส์จะโอนเหรียญไปยังเจ้าของคนถัดไป ด้วยการลง digital signature บน hash ของธุรกรรมก่อนหน้ารวมถึงกุญแจสาธารณะของเจ้าของคนถัดไป และผนวกมันไว้ที่ส่วนท้ายของธุรกรรม และผู้รับเงินเองก็สามารถตรวจสอบลายเซ็นเพื่อยืนยันความเป็นเจ้าของได้
https://image.nostr.build/a467896797a9fb9f98c3c234f0adb4df2376f2c3d9a7cc9d8672d7a9f5aa9efa.png
แน่นอนว่าปัญหาก็คือผู้รับเงินไม่สามารถตรวจสอบได้ว่าเจ้าของคนใดคนหนึ่งก่อนหน้าเขาได้ใช้เหรียญดังกล่าวซ้ำซ้อนมากกว่าหนึ่งครั้งหรือไม่ และวิธีการแก้ไขปัญหานี้โดยทั่วไปก็คงเป็นการกำหนดตัวกลางที่มีความน่าเชื่อถือมาเป็นคนตรวจสอบทุกธุรกรรมเพื่อป้องกันการใช้จ่ายซ้ำซ้อน และหลังจากการทำธุรกรรมแต่ละครั้ง เหรียญจะต้องถูกส่งกลับไปยังตัวกลางเพื่อออกเหรียญใหม่ และจะมีเพียงเหรียญที่ออกจากตัวกลางโดยตรงเท่านั้นที่จะเชื่อถือได้ว่าจะไม่ถูกใช้จ่ายซ้ำซ้อน แต่ปัญหาก็คือ ชะตากรรมของระบบเงินทั้งหมดจะขึ้นอยู่กับตัวกลางตัวนี้ เพราะทุกธุรกรรมจำเป็นจะต้องผ่านพวกเขา ซึ่งก็ไม่ต่างอะไรกับธนาคาร
เราจึงต้องการวิธีการที่ทำให้ผู้รับเงินทราบได้ว่าเจ้าของคนก่อน ๆ ไม่ได้ลงนามในธุรกรรมใด ๆ มาก่อน เพื่อให้บรรลุวัตถุประสงค์นี้ เราจะทำการนับว่าธุรกรรมที่เกิดขึ้นก่อนเป็นธุรกรรมที่ถูกต้อง และจะไม่สนใจความพยายามใด ๆ ในการที่จะใช้เหรียญนั้น ๆ ซ้ำอีก และวิธีเดียวที่ทำแบบนี้ได้ คือการรับรู้ถึงธุรกรรมทั้งหมด เช่นเดียวกับโมเดลที่ได้กล่าวข้างต้น ที่ตัวกลางจะรับรู้ถึงธุรกรรมทั้งหมดและตัดสินว่าธุรกรรมใดมาก่อนมาหลัง เพื่อให้บรรลุเป้าหมายนี้โดยไม่ต้องมีบุคคลที่สามที่เชื่อถือได้ ธุรกรรมทั้งหมดจะต้องถูกประกาศต่อสาธารณะ [1] และเราต้องการระบบที่ผู้เข้าร่วมเห็นพ้องในประวัติธุรกรรมชุดเดียวกันตามลำดับที่ได้รับ ส่วนผู้รับเงินก็จำเป็นจะต้องมีหลักฐานว่า ในขณะที่ทำธุรกรรม “โหนด” ส่วนใหญ่ในระบบเห็นพ้องต้องกันว่าธุรกรรมนั้นได้รับเป็นลำดับแรก(ไม่มีธุรกรรมที่ใช้เหรียญพวกนี้มาก่อน)
3.ระบบบันทึกเวลา (Timestamp Server)
สำหรับแนวทางการแก้ปัญหาในครั้งนี้ เราจะใช้ประโยชน์จาก timestamp server ที่จะทำหน้าที่บันทึก hash ของบล๊อกที่ต้องการให้มีการบันทึกเวลา และจากนั้นจะทำการเผยแพร่ hash ดังกล่าว เหมือนกับหนังสือพิมพ์หรือโพสต์ใน Usenet 2-5 การบันทึกเวลานี้จะพิสูจน์ได้ว่าข้อมูลที่ถูก hash นั้นจะต้องมีอยู่จริงในเวลานั้นเพื่อให้ได้มาซึ่ง hash ดังกล่าว แต่ละการบันทึกเวลาจะรวมการบันทึกเวลาของหน้านี้ไว้ใน hash ของมันเพื่อสร้างเป็น chain โดยการบันทึกเวลาแต่ละครั้งจะยืนยันความถูกต้องของการบันทึกก่อนหน้าได้อีกด้วยด้วย
https://image.nostr.build/ddf92417c45dbb6e25da0af80a10d4cdbc3e725d047d65f54a3e3bfcf358c4d6.png
4.พรูฟ-ออฟ-เวิร์ค (Proof-of-Work)
ในการสร้าง Timestamp Server แบบกระจายศูนย์บนพื้นฐานแบบ peer to peer เราจำเป็นต้องใช้ระบบ Proof-of-Work (PoW) ที่คล้ายกับ Hashcash ของ Adam Back [6] แทนที่จะใช้วิธีการแบบเดิม ๆ อย่างการประกาศในหนังสือพิมพ์หรือ Usenet โดย PoW ใช้ในการตรวจสอบค่าที่มาจากกระบวนการ hash เช่น SHA-256 แล้ว ผลลัพธ์ที่ได้ (Hash) จะขึ้นต้นด้วยเลขศูนย์จำนวนหนึ่ง โดยที่ work (ประมาณว่าพลังประมวลผล) ที่ต้องใช้จะเพิ่มขึ้นแบบทวีคูณตามจำนวนเลขศูนย์ที่ต้องการ และสามารถตรวจสอบได้โดยการรัน Hash เพียงครั้งเดียว
ซึ่งสำหรับ timestamp network ของเรานั้น เราใช้ PoW โดยการเพิ่มค่า Nonce ในบล็อกไปเรื่อย ๆ จนกว่าจะพบค่าที่ทำให้ Hash ของบล็อกนั้นมีเลขศูนย์ตามที่กำหนด และเมื่อใช้กำลังประมวลผลของ CPU ไปกับการทำ PoW จนสำเร็จแล้ว บล็อกจะไม่สามารถเปลี่ยนแปลงได้ หากไม่มีการทำงานซ้ำใหม่ เนื่องจากบล็อกที่สร้างขึ้นภายหลังจะเชื่อมโยงกับบล็อกก่อนหน้า การเปลี่ยนแปลงบล็อกใด ๆ จะต้องทำ PoW ของบล็อกนั้นและบล็อกที่ตามมาใหม่ทั้งหมด
https://image.nostr.build/c039ef4ca6833cb1ecee65ac5991df2406be9b7e490b86b3b19f94f267767182.png
นอกจากนี้ PoW ยังช่วยแก้ปัญหาของเสียงส่วนมากที่มาตัดสินใจในระบบนี้ เพราะหากเสียงข้างมากอ้างอิงจากหลักการหนึ่ง IP หนึ่งเสียง ใครก็ตามที่สามารถสร้าง IP ได้จำนวนมากก็จะสามารถควบคุมระบบได้ จึงใช้หลักการหนึ่ง CPU หนึ่งเสียงแทน การตัดสินใจของเสียงข้างมากจะแสดงด้วย Chain ที่ยาวที่สุด ซึ่งบ่งบอกถึงความพยายามในการคำนวณ (Proof-of-Work) ที่มากที่สุด หาก Node ที่ซื่อสัตย์ (Honest nodes) มีกำลังประมวลผลของ CPU ส่วนใหญ่อยู่ในการควบคุม Honest Chain ก็จะเติบโตเร็วที่สุดและแซงหน้า Chain อื่น ๆ ได้ ผู้โจมตีที่ต้องการแก้ไขบล็อกในอดีตจะต้องทำ Proof-of-Work ของบล็อกนั้นและบล็อกที่ตามมาใหม่ทั้งหมด และต้องทำงานให้เร็วกว่า Honest Node ด้วย ซึ่งโอกาสที่ผู้โจมตีจะตามทันนั้นจะลดลงแบบทวีคูณเมื่อมีการเพิ่มบล็อกมากขึ้น
เพื่อชดเชยความเร็วของฮาร์ดแวร์ที่เพิ่มขึ้นและความสนใจในการรัน Node ที่ผันผวน ระดับความยากของ Proof-of-Work จะถูกกำหนดโดยค่าเฉลี่ย โดยตั้งเป้าไว้ที่จำนวนบล็อกเฉลี่ยต่อชั่วโมง หากสร้างบล็อกได้เร็วเกินไป ระดับความยากก็จะเพิ่มขึ้น
5.เครือข่าย (Network)
เครือข่ายนั้นมีการทำงาน ดังนี้
- การประกาศธุรกรรมใหม่: ธุรกรรมใหม่จะถูกประกาศ (broadcast) ไปยังทุก node ในเครือข่าย
- การรวบรวมธุรกรรม: แต่ละ node จะรวบรวมธุรกรรมใหม่ ๆ เหล่านี้ ไว้ในบล็อก
- การค้นหา Proof-of-Work: แต่ละ node จะทำการคำนวณ เพื่อค้นหา Proof-of-Work ตามค่า difficulty สำหรับบล็อกนั้น ๆ
- การประกาศบล็อก: เมื่อ node ใดค้นหา Proof-of-Work ได้แล้ว node นั้นจะทำการประกาศบล็อกไปยังทุก node ในเครือข่าย
- การตรวจสอบและยอมรับบล็อก: node อื่น ๆ จะทำการตรวจสอบและยอมรับบล็อกนั้น เฉพาะเมื่อธุรกรรมทั้งหมดภายในบล็อกนั้นถูกต้องและยังไม่ถูกใช้มาก่อน
- การสร้างบล็อกถัดไป: node ต่าง ๆ แสดงการยอมรับบล็อกโดยการเริ่มต้นสร้างบล็อกถัดไปใน chain ด้วย hash ของบล็อกที่ยอมรับ เป็น hash ก่อนหน้าในโครงสร้างของบล๊อกใหม่ที่กำลังสร้าง
node ต่าง ๆ จะถือว่า chain ที่ยาวที่สุดเป็น chain ที่ถูกต้องและจะทำงานเพื่อขยาย chain นั้นต่อไป หากมีสอง node ที่ได้ประกาศบล็อกเวอร์ชันที่แตกต่างกันในเวลาพร้อมกัน node บาง node อาจได้รับบล็อกหนึ่งก่อน อีกบล็อกหนึ่ง ในกรณีนี้ node เหล่านั้น จะทำงานบนบล็อกที่ได้รับก่อน แต่จะเก็บสำเนาของบล็อกอีกอันหนึ่งไว้ ในกรณีที่บล็อกนั้น กลายเป็นบล็อกที่อยู่ใน chain ที่ยาวกว่าปัญหาข้อโต้แย้งนี้ก็จะได้รับการแก้ไข เมื่อพบ Proof-of-Work อันถัดไปและ chain ใด chain หนึ่งยาวขึ้น node ที่กำลังทำงานอยู่บน chain ที่สั้นกว่าก็จะเปลี่ยนไปทำงานบน chain ที่ยาวกว่าแทน
การประกาศธุรกรรมใหม่ ไม่จำเป็นต้องไปถึงทุก node ในเครือข่าย ตราบใดที่พวกเขายังไปถึง node ส่วนใหญ่ในระบบได้ ธุรกรรมเหล่านั้นก็จะถูกบรรจุอยู่ในบล็อกในไม่ช้า นอกจากนี้การประกาศบล็อกยังไม่ต้องกังวลเรื่องจะมีบล๊อกที่สูญหาย เนื่องจากหากว่า node ไม่ได้รับบล็อกใด ๆ node ก็จะตระหนักได้ว่าพลาดบล็อกก่อนหน้าไปเมื่อได้รับบล๊อกใหม่มา และ node จะทำการร้องขอ block ที่ขาดไปจากเครือข่าย
6.แรงจูงใจ(Incentive)
โดยปกติแล้ว ธุรกรรมแรกของแต่ละบล๊อกนั้นจะเป็นธุรกรรมพิเศษที่จะขุดเหรียญที่สร้างขึ้นใหม่ซึ่งเป็นกรรมสิทธิ์ของผู้สร้างบล็อกนั้น ๆ ซึ่งจะเป็นการเพิ่มแรงจูงใจให้กับ node ต่าง ๆ ในการสนับสนุนเครือข่าย และเป็นวิธีการกระจายเหรียญให้หมุนเวียน เนื่องจากไม่มีหน่วยงานส่วนกลางที่ทำหน้าที่ในการออกเหรียญ การเพิ่มเหรียญใหม่ในปริมาณคงที่อย่างต่อเนื่องนั้นคล้ายคลึงกับการที่คนงานเหมืองทองคำใช้แรง และ เวลา เพื่อเพิ่มทองคำให้หมุนเวียน ในกรณีนี้ คือ เวลา กำลังประมวลผล และไฟฟ้าที่ถูกใช้ไป
นอกจากนี้แรงจูงใจจะมาจากค่าธรรมเนียมการทำธุรกรรม หากมูลค่าผลลัพธ์ของธุรกรรมน้อยกว่ามูลค่าที่ใส่เข้ามา ส่วนต่างนั้นก็คือค่าธรรมเนียมการทำธุรกรรมที่จะเพิ่มเข้าไปในมูลค่าแรงจูงใจของบล็อกที่มีธุรกรรมนั้น เมื่อเหรียญทั้งหมดในระบบมีจำนวนเท่ากับที่กำหนดไว้แล้ว แรงจูงใจหลักก็จะถูกเปลี่ยนมาเป็นค่าธรรมเนียมการทำธุรกรรม และปราศจากภาวะเงินเฟ้อโดยสิ้นเชิง
แรงจูงใจอาจช่วยกระตุ้นให้ node ต่าง ๆ ยังคงซื่อสัตย์ หากผู้โจมตีที่ละโมบสามารถรวบรวมกำลังประมวลผล ได้มากกว่า node ที่ซื่อสัตย์ทั้งหมด เขาจะต้องเลือกระหว่างการใช้มันเพื่อฉ้อโกงผู้อื่นโดยการใช้จ่ายซ้ำซ้อน หรือใช้มันเพื่อสร้างเหรียญใหม่ พวกเขาจะพบว่าการเล่นตามกฎ กฎที่เอื้อประโยชน์ให้กับเขาด้วยเหรียญใหม่มากกว่าคนอื่น ๆ รวมกันนั้นทำกำไรได้มากกว่าการบ่อนทำลายระบบและความถูกต้องของทรัพย์สินของเขาเอง
7.การจัดการพื้นที่ดิสก์(Reclaiming Disk Space)
เมื่อธุรกรรมถูกบรรจุลงในบล๊อกแล้ว สามารถกำจัดธุรกรรมที่ใช้ไปแล้วก่อนหน้านั้นออกได้เพื่อประหยัดพื้นที่ดิสก์ แต่การจะทำอย่างนี้ได้โดยไม่ให้เลข hash ของบล๊อกมีการเปลี่ยนแปลงนั้น ธุรกรรมจึงจำเป็นต้องถูก hash ในรูปแบบของ Merkle Tree [7][2][5] โดยมีแค่ root node ของ tree เท่านั้นที่จะรวมอยู่ใน hash ของบล๊อก นี่เป็นวิธีที่ทำให้สามารถบีบอัดข้อมูลในบล๊อกเก่า ๆ ได้โดยการตัดพวก hash ส่วนอื่น ๆ ของ tree ที่ไม่ใช่ root node ออก (ไม่จำเป็นต้องเก็บ hash ในชั้นอื่น ๆ ของ tree)
https://image.nostr.build/3ed95334891d91baca3f3f6f624a7ae22620be4ebfe0db5eb652cfce11255b9a.png
โดยในส่วน header ของบล็อกที่ไม่มีธุรกรรมจะมีขนาดประมาณ 80 ไบต์ หากเราสมมติว่าบล็อกถูกสร้างขึ้นทุก ๆ 10 นาที 80 ไบต์ * 6 * 24 * 365 = 4.2MB ต่อปี โดยที่ระบบคอมพิวเตอร์ทั่วไปที่วางขายในปี 2551 มี RAM 2GB และกฎของมัวร์ทำนายการเติบโตในปัจจุบันที่ 1.2GB ต่อปี การจัดเก็บข้อมูลไม่น่าจะเป็นปัญหาแม้ว่าส่วนหัวของบล็อกจะต้องถูกเก็บไว้ในหน่วยความจำก็ตาม
8.การตรวจสอบธุรกรรม (Simplified Payment Verification)
การที่จะยืนยันการชำระเงินโดยไม่จำเป็นต้องรัน full node ได้นั้น ผู้ใช้เพียงแค่เก็บสำเนาของส่วนหัวบล็อก (block header) ของสายบล็อก (chain) ที่ยาวที่สุด ซึ่งสามารถรับได้โดยการสอบถามจาก node อื่น ๆ ในเครือข่ายจนมั่นใจว่าได้รับสายที่ยาวที่สุด และรับ Merkle branch ที่เชื่อมโยงธุรกรรมกับบล็อกที่มีการประทับเวลา (Timestamp) อยู่ ถึงแม้ผู้ใช้จะไม่สามารถตรวจสอบธุรกรรมด้วยตัวเองได้ แต่การเชื่อมโยงธุรกรรมกับตำแหน่งในสายบล็อกจะทำให้เห็นว่า node ในเครือข่ายยอมรับแล้ว และบล็อกที่เพิ่มเข้ามาหลังจากนั้นเป็นการยืนยันเพิ่มเติมว่าเครือข่ายยอมรับธุรกรรมนี้แล้ว
https://i.imgur.com/VXtLpRF.png
การตรวจสอบดังกล่าวจะเชื่อถือได้ตราบใดที่ node ที่ซื่อสัตย์ยังคงควบคุมเครือข่าย แต่จะมีความเสี่ยงมากขึ้นหากเครือข่ายถูกโจมตีและถูกควบคุม ในขณะที่ node ในเครือข่ายสามารถตรวจสอบธุรกรรมได้ด้วยตัวเอง แต่วิธีการแบบง่ายนี้อาจถูกหลอกลวงโดยการใช้ธุรกรรมปลอมของผู้โจมตี ตราบใดที่ผู้โจมตียังคงสามารถควบคุมเครือข่ายได้ กลยุทธ์หนึ่งในการป้องกันปัญหานี้คือ การรับการแจ้งเตือนจาก node อื่น ๆ ในเครือข่ายเมื่อตรวจพบบล็อกที่ไม่ถูกต้อง ซึ่งจะแจ้งให้ซอฟต์แวร์ของผู้ใช้ดาวน์โหลดบล็อกแบบเต็มและธุรกรรมที่แจ้งเตือน เพื่อยืนยันความไม่สอดคล้องกัน ธุรกิจที่ได้รับการชำระเงินบ่อยครั้งอาจยังคงต้องการรัน node ของตนเอง เพื่อความปลอดภัยที่เป็นอิสระและการตรวจสอบที่รวดเร็วยิ่งขึ้น
9.การควบรวมและแบ่งย่อยมูลค่า(Combining and Splitting Value)
แม้ว่าการจัดการเหรียญหลาย ๆ เหรียญจะเป็นสิ่งที่สามารถทำได้ แต่การจัดการธุรกรรมแยกต่างหากสำหรับแต่ละเหรียญในการโอนก็คงเป็นเรื่องที่น่าปวดหัวอยู่ดี ฉะนั้นแล้วเพื่อให้สามารถแยกและรวมมูลค่ากันได้ ธุรกรรมจึงสามารถมี input และ output ได้หลายรายการ ซึ่งโดยปกติแล้วจะมี input เดียวจากธุรกรรมก่อนหน้าที่มีขนาดใหญ่กว่า หรือ input จำนวนเล็ก ๆ หลาย ๆ รายการ และ output ไม่เกินสองรายการ คือ รายการหนึ่งสำหรับการชำระเงิน และอีกหนึ่งรายการสำหรับการส่งเงินทอน หากมีกลับไปยังผู้ส่ง
https://image.nostr.build/9c6d3ce0e9f08c5b3fa3b82c2088ac6235603e5c0df3469060e6c9f74bce32fc.png
ควรสังเกตว่า fan-out (กระจายของธุรกรรม) ซึ่งเป็นกรณีที่ธุรกรรม ธุรกรรมหนึ่งนั้นขึ้นอยู่กับหลายธุรกรรม และธุรกรรมเหล่านั้นเองก็ขึ้นอยู่กับอีกหลายธุรกรรม แต่ไม่ใช่ปัญหาในที่นี้ เพราะไม่มีความจำเป็นในการดึงประวัติการทำธุรกรรมทั้งหมดออกมาเป็นสำเนา
10.ความเป็นส่วนตัว(Privacy)
ในรูปแบบธนาคารแบบดั้งเดิมนั้น ความเป็นส่วนตัวเกิดขึ้นได้ด้วยการจำกัดการเข้าถึงข้อมูล โดยให้เฉพาะผู้ที่เกี่ยวข้องและบุคคลที่สามที่ได้รับความไว้วางใจเท่านั้น แต่เนื่องจากในระบบนี้เรามีความจำเป็นในการประกาศธุรกรรมทั้งหมดต่อสาธารณะ ทำให้ไม่สามารถใช้วิธีนี้ได้ แต่ยังจำเป็นต้องคงความเป็นส่วนตัวไว้ โดยการแบ่งการไหลของข้อมูล ด้วยการไม่เปิดเผยตัวตนของเจ้าของ public key คนทั่วไปสามารถเห็นว่ามีคนกำลังส่งเงินจำนวนหนึ่งให้กับคนอื่น แต่จะไม่ทราบข้อมูลที่เชื่อมโยงธุรกรรมนั้นกับบุคคลใด ๆ ซึ่งคล้ายกับระดับข้อมูลที่เปิดเผยโดยตลาดหลักทรัพย์ ซึ่งมีการเปิดเผยเวลาและขนาดของการซื้อขายแต่ละครั้งต่อสาธารณะ แต่ไม่ได้ระบุว่าคู่สัญญาคือใคร
https://image.nostr.build/6ec3c84c7878dbd4558d2045518384daf5a341e86f4194cf367cc8426c2d72a7.png
เพื่อเสริมในเรื่องของความปลอดภัย ควรใช้ key pair ใหม่สำหรับการทำธุรกรรมในแต่ละครั้ง เพื่อป้องกันไม่ให้เชื่อมโยงกับเจ้าของคนเดียวกันได้ อย่างไรก็ตาม การเชื่อมโยงบางอย่างยังคงหลีกเลี่ยงไม่ได้ ในธุรกรรมที่มี input หลายรายการ ซึ่งจำเป็นต้องเปิดเผยว่า input เหล่านั้นเป็นของเจ้าของคนเดียวกัน ความเสี่ยงก็คือ หากมีการเปิดเผยตัวตนของเจ้าของคีย์ การเชื่อมโยงอาจเปิดเผยธุรกรรมอื่น ๆ ที่เป็นของเจ้าของรายเดียวกันได้
11.การคำนวณ(Calculations)
หากลองพิจารณาสถานการณ์ที่ผู้โจมตีพยายามสร้าง chain ปลอมให้เร็วกว่า chain จริง แม้ว่าจะทำได้สำเร็จ แต่มันก็ไม่สามารถทำให้ระบบเปิดรับการเปลี่ยนแปลงตามอำเภอใจได้อยู่ดี เช่น การสร้างมูลค่าจากอากาศธาตุ หรือการรับเงินที่ไม่เคยเป็นของผู้โจมตีมาก่อน Node ต่าง ๆ จะไม่ยอมรับธุรกรรมที่ไม่ถูกต้องเป็นการชำระเงิน และ Node ที่สุจริตก็จะไม่ยอมรับบล็อกที่มีธุรกรรมเหล่านั้นอย่างแน่นอน ผู้โจมตีทำได้เพียงพยายามเปลี่ยนแปลงธุรกรรมของตนเอง เพื่อนำเงินที่ใช้ไปแล้วกลับคืนมาเท่านั้น
การแข่งขันระหว่าง chain สุจริตกับ chain ของผู้โจมตี สามารถอธิบายได้ด้วยแบบจำลองการเดินสุ่มทวินาม (Binomial Random Walk) โดยเหตุการณ์ที่สำเร็จ หมายถึง chain ที่สุจริตถูกขยายออกไปอีกหนึ่งบล็อก เพิ่มความยาวนำหน้าไป +1 และเหตุการณ์ที่ล้มเหลว หมายถึง chain ของผู้โจมตีถูกขยายออกไปหนึ่งบล็อก ลดช่องว่างลง -1
ความน่าจะเป็นที่ผู้โจมตีจะไล่ตามทันจากช่องว่างที่กำหนด สามารถเปรียบเทียบด้วย Gambler’s Ruin problem โดยสมมติว่านักพนันที่มีเครดิตไม่จำกัด เริ่มต้นด้วยการขาดทุน และเล่นพนันไปเรื่อย ๆ เพื่อให้ถึงจุดคุ้มทุน เราสามารถคำนวณความน่าจะเป็นที่เขาจะกลับมาถึงจุดคุ้มทุนได้ หรือความน่าจะเป็นที่ผู้โจมตีจะไล่ทัน chain ที่สุจริตได้ ดังนี้ [8]:
p = ความน่าจะเป็นที่ Node ที่สุจริตจะพบบล็อกถัดไป q = ความน่าจะเป็นที่ผู้โจมตีจะพบบล็อกถัดไป qz = ความน่าจะเป็นที่ผู้โจมตีจะไล่ทัน จากที่ตามหลังอยู่ z บล็อก
https://i.imgur.com/vePe255.png
จากสมมติฐานที่ว่า p > q ความน่าจะเป็นจะลดลงแบบเอกซ์โพเนนเชียล เมื่อจำนวนบล็อกที่ผู้โจมตีต้องไล่ตามทันเพิ่มขึ้น หากเขาไม่สามารถพุ่งขึ้นนำได้อย่างรวดเร็วตั้งแต่แรก โอกาสของเขาก็จะลดลงจนน้อยมาก ๆ เมื่อเขาตามหลังมากขึ้นเรื่อย ๆ
ทีนี้ลองพิจารณาว่า ผู้รับธุรกรรมใหม่ต้องรอเป็นเวลานานเท่าใด จึงจะแน่ใจได้ว่าผู้ส่งไม่สามารถเปลี่ยนแปลงธุรกรรมได้แล้ว เราสมมติว่าผู้ส่งเป็นผู้โจมตี ที่ต้องการให้ผู้รับเชื่อว่าเขาได้รับเงินไปแล้ว จากนั้นจึงเปลี่ยนให้เงินกลับเข้าหาตัวเองหลังจากเวลาผ่านไประยะหนึ่ง ผู้รับจะได้รับแจ้งเมื่อเกิดเหตุการณ์นี้ขึ้น แต่ผู้ส่งหวังว่ามันจะสายเกินไปแล้ว
ผู้รับจะสร้างคู่กุญแจใหม่ และให้กุญแจสาธารณะแก่ผู้ส่งไม่นานก่อนที่จะลงนาม ซึ่งจะป้องกันไม่ให้ผู้ส่งเตรียมบล็อกเชนปลอมไว้ล่วงหน้า โดยการทำงานอย่างต่อเนื่องจนกว่าเขาจะมีโอกาสได้บล็อกที่ยาวพอ จากนั้นจึงดำเนินธุรกรรมในทันที เมื่อส่งธุรกรรมแล้ว ผู้ส่งที่ไม่สุจริตจะเริ่มทำงานอย่างลับ ๆ บนบล็อกเชนคู่ขนาน ที่มีธุรกรรมในเวอร์ชันของเขาเองอยู่
ผู้รับจะรอจนกว่าธุรกรรมจะถูกเพิ่มลงในบล็อก และมีบล็อกที่ถูกเชื่อมต่อตามหลังมาอีก z บล็อก เขาไม่ทราบจำนวนความคืบหน้าที่แน่นอนที่ผู้โจมตีได้ทำไปแล้ว แต่สมมติว่าบล็อกที่สุจริตใช้เวลาเฉลี่ยต่อบล็อกตามที่คาดไว้ ความคืบหน้าที่อาจเกิดขึ้นได้ของผู้โจมตีจะเป็นการแจกแจงแบบปัวซง (Poisson distribution) ซึ่งมีค่าคาดหวังดังนี้:
https://i.imgur.com/mYsb48i.png
เพื่อให้ได้ความน่าจะเป็นที่ผู้โจมตียังคงสามารถไล่ทันได้ เราจะคูณความหนาแน่นของปัวซง สำหรับความคืบหน้าแต่ละระดับที่เขาสามารถทำได้ ด้วยความน่าจะเป็นที่เขาสามารถไล่ทันจากจุดนั้น:
https://i.imgur.com/jQGkQ8r.png
จัดเรียงใหม่เพื่อหลีกเลี่ยง infinite tail ของการแจกแจง
https://i.imgur.com/OOO6Gm9.png
แปลงมันให้เป็น C code
#include 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=1 P=0.2045873 z=2 P=0.0509779 z=3 P=0.0131722 z=4 P=0.0034552 z=5 P=0.0009137 z=6 P=0.0002428 z=7 P=0.0000647 z=8 P=0.0000173 z=9 P=0.0000046 z=10 P=0.0000012 q=0.3 z=0 P=1.0000000 z=5 P=0.1773523 z=10 P=0.0416605 z=15 P=0.0101008 z=20 P=0.0024804 z=25 P=0.0006132 z=30 P=0.0001522 z=35 P=0.0000379 z=40 P=0.0000095 z=45 P=0.0000024 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.สรุป(Conclusion)
เราได้นำเสนอระบบธุรกรรมอิเล็กทรอนิกส์ที่ไม่ต้องพึ่งพาความไว้วางใจ เริ่มต้นจากกรอบแนวคิดของเหรียญที่สร้างจากลายเซ็นดิจิทัล ซึ่งช่วยควบคุมความเป็นเจ้าของได้อย่างดีแต่ก็ยังไม่สมบูรณ์ หากปราศจากวิธีการป้องกันการใช้จ่ายซ้ำซ้อน เพื่อแก้ปัญหานี้ เราจึงเสนอเครือข่ายแบบเพียร์ทูเพียร์ที่ใช้ proof-of-work ในการบันทึกประวัติธุรกรรมสาธารณะ ซึ่งจะกลายเป็นเรื่องยากอย่างมากสำหรับผู้โจมตีที่จะเปลี่ยนแปลง หาก node ที่ซื่อสัตย์ควบคุมพลังประมวลผล CPU ส่วนใหญ่ เครือข่ายนี้มีความแข็งแกร่งในความเรียบง่ายที่ไม่มีโครงสร้างใด ๆ ที่ซับซ้อน node ต่าง ๆ ทำงานพร้อมกันโดยประสานงานกันเพียงเล็กน้อย ไม่จำเป็นต้องระบุตัวตน เนื่องจากข้อความไม่ได้ถูกส่งไปยังสถานที่ใดสถานที่หนึ่งโดยเฉพาะ และเพียงแค่ต้องส่งมอบให้ถึงมือผู้รับอย่างดีที่สุด node สามารถออกจากและเข้าร่วมเครือข่ายได้ตามต้องการ โดยยอมรับ chain ที่มี 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.