รูปภาพ

ในบทความที่แล้ว เราได้อธิบายรายละเอียดวิธีการทำงานของช่องทางการชำระเงิน และวิธีต่างๆ เพื่อให้แน่ใจว่าการชำระเงินจะเกิดขึ้นอย่างปลอดภัย อย่างไรก็ตาม ฟังก์ชันเหล่านี้ไม่เพียงพอที่จะรองรับเครือข่ายช่องทางการชำระเงินที่ใช้งานได้ แม้ว่าเราจะแน่ใจว่าผู้เข้าร่วมทุกคนในแต่ละช่องทางมีความซื่อสัตย์และเชื่อถือได้ ก็ไม่มีการรับประกันว่าการชำระเงินผ่านหลายช่องทางจะปลอดภัยเช่นกัน นั่นเป็นเหตุผลที่เราต้องการสัญญาอัจฉริยะ "HTLC (Hash-Time Lock-Contract)" ในบทความนี้ เราจะอธิบายวิธีการทำงานของ HTLC และใช้ตัวอย่างเพื่อแสดงวิธีการใช้การชำระเงินแบบ multi-hop ในเครือข่าย Lightning

สัญญาล็อคเวลาแฮช (HTLC)

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

H = Hash(R)

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

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

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

1. ลองพิจารณาการทำธุรกรรมการชำระเงิน HLTC กับใครบางคน:

2. HASH160 EQUAL

3. IF    

4. # ตรวจสอบว่า R ที่ให้มานั้นเป็นพรีอิมเมจของ H หรือไม่

5.         CHECKSIG

6. ELSE    

7. # ตรวจสอบว่าบุคคลที่เปิดเผย R เป็นผู้รับดั้งเดิมของธุรกรรมหรือไม่

8.       CHECKLOCKTIMEVERIFY    

9. # ตรวจสอบว่า timelock หมดอายุหรือไม่

10.       CHECKSIG

11. ENDIF

หลังจากเปิดเผย R (ภาพก่อนหน้าของค่าแฮช H) ที่ถูกต้องแล้ว เราจะเข้าสู่กระบวนการ IF เพื่อตรวจสอบเพิ่มเติมว่าบุคคลที่ระบุ R เป็นวัตถุการชำระเงินในตอนเริ่มต้นของธุรกรรมการชำระเงินหรือไม่ เมื่อใช้เอาต์พุตนี้ ผู้รับเพียงแค่จัดเตรียมสคริปต์การปลดล็อกอย่างง่าย:

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

แน่นอนว่านี่เป็นเพียงการใช้งานขั้นพื้นฐานของ HTLC ซึ่งแสดงถึงการชำระเงินแบบล็อกเวลาตามปกติ คุณสามารถเพิ่มเงื่อนไขอื่นๆ ในสคริปต์ได้ไม่จำกัดจำนวน เช่น ลบการตรวจสอบคีย์สาธารณะในกระบวนการ IF เพื่อให้ใครก็ตามที่ทราบค่าลับ R สามารถใช้ผลลัพธ์นี้ได้ คุณยังสามารถเพิ่มข้อจำกัดหลายลายเซ็นเพื่อให้ สามารถปลดล็อกลายเซ็นของคีย์ส่วนตัวที่ตั้งไว้ล่วงหน้าหลายรายการได้CHECKLOCKTIMEVERIFYนอกจากนี้ ในกรณีนี้ opcode ที่เราใช้คือCHECKSEQUENCEVERIFYopcode นี้ใช้ค่าสัมบูรณ์เพื่อกำหนดการล็อกเวลา ซึ่งหมายถึง "ไม่สามารถแตะเอาต์พุตนี้ได้จนกว่าจะบล็อก #546212" ใน Lightning Network มีการใช้การล็อกเวลาแบบอื่น ซึ่งเป็นแบบ "ยืดหยุ่น" มากกว่า:

ซึ่งใช้ค่าสัมพัทธ์ซึ่งมีความหมายใกล้เคียงกับ: "เอาต์พุตนี้ใช้ไม่ได้สำหรับ 1,000 บล็อกหลังจากการทำธุรกรรมที่ใช้มันเป็นแบบออนไลน์" (หมายเหตุผู้แปล: ค่าต่อไปนี้เป็นตัวอย่าง การปฏิบัติของหลักสูตร ค่าอื่น ๆ สามารถ ใช้)

กรณีเครือข่ายสายฟ้า

รูปภาพ

คำอธิบายภาพ

รูปภาพ

คำอธิบายภาพ

1. - รายละเอียดทีละขั้นตอนของเส้นทางการชำระเงินในเครือข่าย Lightning -

2. เอริคสร้างค่าลับ R และส่งแฮชของมันให้อลิซ (เขาจะไม่เปิดเผย R ให้คนอื่นรู้)

3. อลิซใช้ค่าแฮชนี้เพื่อสร้าง HTLC และล็อคเวลาถูกตั้งค่าเป็น 10 บล็อกถัดไป และจำนวนเอาต์พุตคือ 1.003 btc 0.003 btc พิเศษนี้เป็นค่าธรรมเนียมสำหรับบุคคลกลางของห่วงโซ่ช่องทางการชำระเงิน ดังนั้น ตอนนี้อลิซล็อก 1.003 btc ด้วย HTLC และเงื่อนไขเฉพาะของ HTCL แสดงเป็นภาษาธรรมดาดังนี้: "อลิซจะจ่ายบ็อบ 1.003 btc ตราบเท่าที่เขาสามารถมอบมูลค่าลับ R ภายใน 10 บล็อก มิฉะนั้นเงิน จะกลับมาหาอลิซ" ความสมดุลของแชนเนลระหว่างพวกเขาจะเปลี่ยนไปเช่นกันเนื่องจากธุรกรรมที่มีข้อผูกมัดนี้ ตอนนี้ Bob มี 2 btc ในช่อง Alice มี 0.997 btc และ 1.003 btc ถูกล็อคใน HTLC

4. เมื่อ Bob มาที่นี่ เขาสามารถจัดการธุรกรรมข้อผูกมัดของ Alice ได้ตามต้องการ (ธุรกรรม HTLC นี้จะถูกส่งผ่านช่องทางระหว่างพวกเขา) เขาสร้างเอาต์พุต HTLC ในช่องระหว่างตัวเขากับแครอล จำนวนเงินคือ 1.002 ล็อคเวลาตั้งไว้ที่ 9 บล็อก และใช้ค่าแฮชที่อลิซให้มา Bob รู้ว่าหาก Carol ต้องการรับเงิน เขาต้องหาค่าลับ R เพื่อปลดล็อก HTLC นี้ และเมื่อเธอทำสำเร็จ เขาจะรู้ R นี้ ดังนั้นเขาจึงสามารถปลดล็อก HTLC ของ Alice และรับ 1.003 btc ได้ หากแครอลหาค่าลับ R นี้ไม่เจอ ทั้งบ็อบและอลิซสามารถรับเงินคืนได้หลังจากปลดล็อกเวลาแล้ว โปรดทราบว่าจำนวนเงินที่ Bob ส่งไปนั้นน้อยกว่าจำนวนเงินที่เขาจะได้รับ 0.001 btc ซึ่งเป็นจำนวนค่าธรรมเนียมที่เขาเรียกเก็บ ยอดคงเหลือของ Bob และ Carol ในช่องจะกลายเป็น: Carol เป็นเจ้าของ 2btc, Bob เป็นเจ้าของ 0.998 btc และ 1.002 btc ถูกล็อคใน HTLC

5. หลังจากที่ Carol ได้รับธุรกรรมการผูกมัดที่ Bob ส่งมา เธอก็ทำเช่นเดียวกันและสร้าง HTLC ในช่องกับ Diana โดยใช้ค่าแฮชเดียวกับที่ Bob ให้มา โดยตั้งค่าล็อกเวลาเป็น 8 บล็อก และจำนวนเงินคือ 1.001 btc หาก Diana สามารถเปิดเผยค่าความลับ R ได้ภายใน 8 ช่วงตึก เธอสามารถปลดล็อก HTLC และรับ 1.001 btc เช่นเดียวกัน แครอลก็จะรู้ค่าความลับเช่นกัน ปลดล็อก HTLC ที่ Bob มอบให้เธอ รับ 1.002 btc และรับ 0.001 btc ยอดคงเหลือในช่องของ Carol และ Diana กลายเป็น: Diana เป็นเจ้าของ 2btc, Carol เป็นเจ้าของ 0.999 btc และ 1.001 btc ถูกล็อคใน HTLC

6. สุดท้าย เมื่อ Diana ส่ง HTLC (โดยใช้ค่าแฮชเดียวกับการล็อก) ให้ Eric ผ่านช่องทาง เธอตั้งค่าเป็น 1 btc และล็อกเวลาเป็น 7 ช่วงตึก ยอดคงเหลือของช่องของ Diana และ Eric กลายเป็น: Eric เป็นเจ้าของ 2btc, Diana เป็นเจ้าของ 1 btc และ 1 btc ถูกล็อคใน HTLC

7. ตอนนี้เราได้มาถึงจุดสิ้นสุดของห่วงโซ่การชำระเงินนี้แล้ว Eric เป็นเจ้าของค่าลับ R นี้ และค่าแฮชของ R นี้ใช้ในธุรกรรมที่มีข้อผูกมัด HTLC ทั้งหมด Eric สามารถปลดล็อก HTLC ที่ Diana ส่งถึงเขาและรับ 1 btc และหลังจากที่ Eric ได้รับเงินคืน Diana ก็จะรู้ R นี้ด้วย ยอดคงเหลือของช่องระหว่าง Diana และ Eric จะกลายเป็น: Eric เป็นเจ้าของ 3 btc และ Diana เป็นเจ้าของ 1 btc

8. หลังจากที่ไดอาน่าได้รับความลับ เธอก็ใช้เพื่อปลดล็อก HTLC ที่แครอลส่งมาให้เธอ โดยได้รับ 1.001 btc และเปิดเผยมูลค่าความลับต่อแครอล ยอดคงเหลือในช่องของพวกเขากลายเป็น: Diana มี 3.001 btc และ Carol มี 0.999 btc

9. หลังจากที่ Carol ได้รับค่าลับ R แล้ว เธอก็ปลดล็อก 1.001 btc ที่ Bob ส่งมา ดังนั้น Bob จึงรู้ค่าความลับด้วย ยอดคงเหลือในช่องของพวกเขากลายเป็น: Carol มี 3.002 btc และ Bob มี 0.998 btc

ในท้ายที่สุด Bob ใช้ค่าลับ R เพื่อรับ 1.003 btc ในช่องกับอลิซ ดังนั้นยอดคงเหลือในช่องจึงกลายเป็น: Bob เป็นเจ้าของ 3.003 btc, Alice เป็นเจ้าของ 0.997

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

ล้างความผิด

ในตัวอย่างของเรา กระบวนการทั้งหมดเป็นไปอย่างราบรื่นและไร้ข้อจำกัด แต่ในชีวิตจริงก็เหมือนกับที่เรียกว่า "กฎของเมอร์ฟี" นั่นคือหากมีสิ่งเลวร้ายเกิดขึ้น สิ่งเลวร้ายนี้ก็จะเกิดขึ้น ดังนั้นเราต้องพิจารณากลไก "การป้องกัน" ของ Lightning Network

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

รูปภาพ

คำอธิบายภาพ

- ไม่สามารถส่งเงินได้เนื่องจากช่องทางถูกปิด -

เมื่อไดอาน่าได้รับมูลค่าลับ เธอก็ถอนเงินทันทีและเปิดเผยความลับต่อแครอล แครอลต้องการรับเงินคืนจาก HTLC ที่ส่งโดย Bob แต่ Bob ไม่ตอบสนอง เพื่อหลีกเลี่ยงความเสี่ยง เธอจึงปิดช่องและส่งธุรกรรมที่ผูกมัดครั้งสุดท้ายในมือของเธอ (นั่นคือ เอาต์พุต HTCL ที่ส่งโดย Bob ก่อนทำธุรกรรม) เผยแพร่ไปยังเครือข่าย Bitcoin และเนื่องจากเธอรู้มูลค่าที่เป็นความลับ เธอจึงสามารถรับเงินคืนได้ ณ จุดนี้ Bob ยังมีเวลาอีกสามวันในการคืนเงินของเขาจาก Alice (เนื่องจากธุรกรรมของ Carol เป็นแบบออนไลน์ ดังนั้น Bob จึงรู้ค่าของ R ได้อย่างง่ายดาย) มิฉะนั้น Alice สามารถถอนเงินได้ทันทีที่ล็อคเวลาถูกปลดล็อค

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

เปลี่ยนเส้นทาง

รูปภาพ

คำอธิบายภาพ

รูปภาพ

คำอธิบายภาพ

- อลิซถ้าใช้เส้นทางอื่น -

รูปภาพ

คำอธิบายภาพ

- อลิซ "ยกเลิก" การชำระเงินเก่า ขณะนี้สามารถส่งการชำระเงินใหม่ได้อย่างปลอดภัย -

จำนวนเงินที่ชำระ

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

โปรโตคอลการถ่ายโอน

คุณสมบัติที่สำคัญอีกอย่างของ Lightning Network: ข้อมูลทั้งหมดเกี่ยวกับเส้นทางนี้จะไม่ระบุชื่อโดยสมบูรณ์ หมายความว่าสำหรับผู้เข้าร่วมรายใด TA จะรู้เฉพาะส่วนที่เกี่ยวข้องกับตัวเองเท่านั้น ตัวอย่างเช่น สำหรับ Carol การจ่ายเงินเหมือนกับ Bob โอนเงินให้ Diana และเธอไม่รู้ว่า Bob จะโอนเงินจาก Alice ได้รับเงินแล้ว และไม่ทราบว่า Diana จะโอนเงินให้ Eric ต่อไป

Lightning Network ใช้โปรโตคอลการเข้ารหัสหลายตัวของสฟิงซ์ เมื่อใช้เครือข่าย Lightning อลิซจะใช้การเข้ารหัสหนึ่งชั้นกับทุกส่วนของเครือข่าย โดยเริ่มต้นที่จุดสิ้นสุดของเส้นทางการชำระเงิน เธอเข้ารหัสข้อความสำหรับเอริคโดยใช้กุญแจสาธารณะของเอริค ข้อความที่เข้ารหัสนี้จะฝังอยู่ในข้อความถึง Diana และข้อความทั้งหมดจะถูกเข้ารหัสอีกครั้งด้วยรหัสสาธารณะของ Diana จากนั้น ข้อความถึง Diana จะฝังอยู่ในข้อความถึง Carol และข้อความทั้งหมดจะถูกเข้ารหัสอีกครั้งด้วยรหัสสาธารณะของ Carol ทำอย่างนี้ซ้ำ ๆ เพื่อให้ได้ข่าวที่สามารถส่งต่อไปยังคนต่อไปได้ ด้วยวิธีนี้ Bob สามารถถอดรหัสได้เฉพาะชั้นนอกสุดของข้อความ รับเนื้อหาที่ต้องการสำหรับเขา จากนั้นส่งต่อข้อความไปยัง Carol ซึ่ง Carol ก็ทำเช่นเดียวกัน สำหรับผู้ผ่านแต่ละคนจะมีการเปิดเผยเฉพาะข้อมูลที่จำเป็นอย่างยิ่ง: จำนวนเงินที่จ่าย, จำนวนค่าคอมมิชชั่น, เนื้อหาของการล็อคเวลา ฯลฯ

เพื่อไม่ให้ผู้คนเดาความยาวของห่วงโซ่จากความยาวของข้อความ ความยาวของข้อความจะเท่ากันเสมอราวกับว่ามีคน 20 คนเข้าร่วมในห่วงโซ่ ทุกคนรวมถึงคนสุดท้ายได้ภาพขนาดเท่ากัน คิดว่ามีอีก 20 คนนอกจากตัวเอง

ประโยชน์และสถานการณ์การใช้งานของ Lightning Network

• แน่นอนว่าประโยชน์ของ Lightning Network ไม่ใช่แค่ความสามารถในการปรับขนาดอย่างที่หลายคนคิด ลองคิดถึงความเป็นไปได้ที่ Lightning Network นำมา

• การทำธุรกรรมทันที เมื่อใช้ Lightning Network การทำธุรกรรมแทบจะทันที ดังนั้นการซื้อกาแฟด้วย bitcoin จึงเป็นไปได้

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

• การชำระเงินขนาดเล็ก ค่าธรรมเนียม Bitcoin blockchain นั้นสูงเกินไปสำหรับการชำระเงินจำนวนเล็กน้อย ยากที่จะจินตนาการว่ามีใครยอมจ่าย 0.001 btc เพียงเพื่อโอนในจำนวนที่เท่ากันหรือน้อยกว่านั้น ด้วย Lightning Network คุณสามารถโอนเงินจำนวนเท่าใดก็ได้ในทันที เช่น คุณสามารถชำระค่าธรรมเนียมเครือข่ายเป็น MB

• สัญญาและการทำธุรกรรมทางการเงินที่ชาญฉลาด สัญญาทางการเงินมีความละเอียดอ่อนอย่างมากและมักต้องมีการคำนวณมากมาย การย้ายภาระส่วนใหญ่ออกจากบล็อกเชนทำให้เรามีโอกาสสร้างธุรกรรมและสัญญาที่ซับซ้อนมากโดยไม่ต้องบันทึกทั้งหมดบนบล็อกเชน

• ความเป็นส่วนตัว. ในเครือข่าย Lightning การทำธุรกรรมมีความเป็นส่วนตัวมากกว่าบนบล็อกเชน Bitcoin เนื่องจากผู้เข้าร่วมในห่วงโซ่การชำระเงินไม่ทราบต้นทางและปลายทางของการทำธุรกรรม

สรุปแล้ว

(เกิน)

ลิงค์

• Lightning network in depth, part 1: Payment channels

• “Mastering bitcoin” — Andreas M. Antonopoulos

• Lightning network whitepaper

• Segregated witness for dummies

(เกิน)

ลิงค์ต้นฉบับ:

https://medium.com/softblocks/lightning-network-in-depth-part-2-htlc-and-payment-routing-db46aea445a8

ผู้เขียน: Magomed Aliev

แปล: เจียน