ข้ามไปยังเนื้อหา
Financial Context Wiki

สัญญาล็อกด้วยแฮชและเวลา (HTLC)

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

อัปเดต

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

คำตอบโดยตรง

สัญญาล็อกด้วยแฮชและเวลา (HTLC) คือการชำระเงินแบบมีเงื่อนไขที่มีเส้นทางใช้จ่ายสองทางแข่งขันกัน ก่อนหมดอายุ ผู้รับเปิดเผยค่า x ที่แฮชตรงกับค่าที่ผูกมัดไว้ h = H(x) และทำตามลายเซ็นหรือสิทธิ์ที่กำหนดเพื่อรับเงินได้ หลังหมดอายุ ผู้จ่ายใช้เส้นทางคืนเงินได้ ลำดับตรงขอบเขตขึ้นกับเชนและสัญญา ไม่ใช่เพียงคำว่า “ก่อน”

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

HTLC ไม่ได้ไร้ความไว้วางใจ เป็นอะตอมมิก เป็นส่วนตัว หรือทำงานเองโดยอัตโนมัติ ความปลอดภัยยังต้องอาศัยโค้ดถูกต้อง การเข้ารหัสที่เข้ากันได้ เวลาหมดอายุเหลื่อมกัน สมมติฐาน finality ค่าธรรมเนียม การเฝ้าดู และการยืนยันทันเวลา HTLC ของ Lightning เป็นแบบ Bitcoin ที่ระบุชัด ส่วนสัญญาบนเชนอื่นอาจมีความหมายต่างกัน

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

วิธีทำงาน

Bob เลือกพรีอิมเมจใหม่ที่คาดเดาไม่ได้ x คำนวณ h = H(x) แล้วส่ง h ให้ Alice จากนั้น Alice ล็อกเงินด้วยกฎที่ผูกมัด h ระบุผู้มีสิทธิ์ และกำหนดเวลาหมดอายุ T

  • Alice ตรวจอัลกอริทึม การเข้ารหัส จำนวนเงิน สินทรัพย์ ผู้รับ ปลายทางคืนเงิน เชน และเวลาหมดอายุก่อนให้ทุน
  • Bob ตรวจเอาต์พุตที่ได้รับเงินจริงหรือสัญญาที่ปรับใช้แล้ว ไม่เชื่อเพียงร่างธุรกรรมหรือหน้าจอ
  • หาก Bob รับผ่านแขนงสำเร็จ เขาส่ง x; ตรรกะตรวจ H(x) = h และสิทธิ์ที่ต้องใช้
  • การเผยแพร่หรือส่ง x อาจทำให้ Alice หรือตัวกลางชำระ HTLC อื่นที่ใช้แฮชการชำระเงินเดียวกันได้
  • หากไม่ใช้แขนงสำเร็จทันเวลา เส้นทางคืนเงินจะใช้ได้ที่ T; การใช้ได้ไม่ได้ทำให้มีการส่งหรือยืนยันเอง
  • ผู้ร่วมระบบยังต้องเตรียมหรือเก็บธุรกรรม จ่ายค่าธรรมเนียมพอ ส่งธุรกรรม เฝ้าการแทนที่และความขัดแย้ง และรับการยืนยัน
  • เมื่อเปิดเผย x ต่อคู่สัญญาหรือเชนสาธารณะ ให้ถือว่าเปิดเผยแล้วและอย่านำไปใช้กับเงื่อนไขอื่น

Bitcoin แยกการล็อกแบบสัมบูรณ์กับแบบสัมพัทธ์ OP_CHECKLOCKTIMEVERIFY ใน BIP 65 ห้ามใช้จ่ายจนถึงความสูงหรือเวลาบล็อกที่ระบุใน locktime ส่วน OP_CHECKSEQUENCEVERIFY ใน BIP 112 รอให้อินพุตมีอายุสัมพัทธ์เพียงพอ ฟิลด์ธุรกรรมต้องเข้ากันด้วย ไทม์ล็อกจึงเป็นกฎตรวจสอบ ไม่ใช่ตัวตั้งเวลา

ใน Lightning ข้อความ update_add_htlc มีจำนวนเงิน payment_hash และ cltv_expiry แต่ละฮอปตั้ง HTLC ขาออกให้หมดอายุก่อนขาเข้าที่คู่กัน เพื่อเหลือเวลารับพรีอิมเมจแล้วเรียกร้องทางต้นน้ำ BOLT 3 กำหนดเอาต์พุต commitment เส้นทาง HTLC-success กับ HTLC-timeout ลายเซ็น การเพิกถอน การตัด dust และเวลาหน่วง แผนภาพสองแขนงจึงไม่ใช่ช่องทางที่สมบูรณ์

ตัวอย่าง

ตัวอย่างเพื่อการเรียนรู้ให้ Alice แลก 1 BTC กับ 20 ETH ของ Bob ตัวอย่างนี้แสดงเพียงลำดับ ระบบจริงต้องใช้โค้ดเฉพาะเชนที่ผ่านการตรวจ และไม่ควรคัดลอกระยะเวลาสมมตินี้

  • Alice สร้าง x และ h = H(x) ใหม่ แล้วล็อก 1 BTC ให้ Bob รับด้วยพรีอิมเมจ และ Alice คืนเงินหลัง 48 hours
  • หลังตรวจธุรกรรม Bitcoin และนโยบายยืนยัน Bob ล็อก 20 ETH ด้วยแฮชและการเข้ารหัสที่เข้ากัน เส้นทางของ Alice สิ้นสุดหลัง 24 hours แล้วจึงเป็นเส้นทางคืนเงินของ Bob
  • ก่อนเปิดเผย x เพื่อรับ 20 ETH Alice ตรวจ ID ของ Ethereum ไบต์โค้ด ที่อยู่ สินทรัพย์ จำนวนเงิน คู่สัญญา h และทั้งสองเส้นทาง
  • Bob เรียนรู้ x จากการรับเงินหรือข้อความที่ตกลง แล้วพยายามใช้เส้นทางสำเร็จของ Bitcoin ก่อนกำหนดที่ช้ากว่า
  • หากสวอปหยุดก่อนเปิดเผย การคืนเงินแต่ละฝั่งใช้ได้ตามกฎของเชนนั้นเท่านั้น และต้องส่งพร้อมรอการยืนยัน

ส่วนต่างระหว่าง 48 hours กับ 24 hours คือเวลาสำรองตอบสนอง ไม่ใช่ค่าปลอดภัยสากล ต้องจำลองการ reorganization เวลาบล็อก finality การทำงาน relay mempool ค่าธรรมเนียม การเซ็นเซอร์ และความล่าช้าของทั้งสองระบบ ฝ่ายที่ทำทีหลังไม่ควรเดินหน้าจากคำว่า “ยืนยันแล้ว” บนหน้าจอเพียงอย่างเดียว

ความเสี่ยง

  • การผูกมัดผิด: อัลกอริทึม ความยาว หรือการเข้ารหัสต่างกัน ทำให้ x เดียวกันใช้ไม่ได้ทั้งสองฝั่ง
  • อาร์ติแฟกต์ผิด: เอาต์พุต ID เชน ที่อยู่ ไบต์โค้ด สินทรัพย์ จำนวน ผู้รับ หรือที่คืนเงินไม่ตรงกับหน้าจอ
  • ลำดับไม่ปลอดภัย: เวลาสิ้นสุดเท่ากันหรือใกล้เกินไป ทำให้เรียกร้องต้นน้ำไม่ได้หลังจ่ายปลายน้ำ
  • ขอบเขตผิด: ความสูงบล็อก เวลาบล็อก timestamp อายุสัมพัทธ์ และการเปรียบเทียบ < กับ <= ไม่เท่ากัน
  • ไม่คืนอัตโนมัติ: ครบกำหนดเพียงทำให้ใช้จ่ายได้ กระเป๋า โหนด ผู้ใช้ หรือผู้เฝ้าต้องลงมือ
  • ค่าธรรมเนียมและ dust: การเรียกร้องอาจไม่คุ้ม ถูกตัด ค้าง หรือทำไม่ได้หากไม่มีสินทรัพย์จ่ายค่าธรรมเนียม
  • การยืนยันและ reorganization: การเห็นธุรกรรมหรือพรีอิมเมจไม่ใช่การชำระที่ย้อนกลับไม่ได้
  • การแข่งขันและความแออัด: ความสำเร็จ timeout การแทนที่ ความขัดแย้ง หรือการหน่วงใช้เวลาสำรองจนหมด
  • การนำไปใช้: ข้อผิดพลาดในสคริปต์ สัญญา กระเป๋า ลายเซ็น nonce RPC หรือไคลเอนต์อาจทำลายเส้นทาง
  • การเฝ้าดู: ฝ่ายออฟไลน์อาจพลาดการเปิดเผย หมดอายุ ปิดบังคับ แทนที่ หรือเวลาส่งสุดท้าย
  • ความเป็นส่วนตัว: แฮชที่ใช้ซ้ำ พรีอิมเมจ จำนวน เวลา และเหตุการณ์ช่องทางอาจเชื่อมโยงการโอน
  • สิทธิ์เลือกและการรบกวน: ฝ่ายหนึ่งล็อกสภาพคล่องแล้วเลิกได้ จึงไม่รับประกันการเสร็จสิ้นหรือชดเชย

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

ความเข้าใจผิดที่พบบ่อย

  • “เงินจะกลับอัตโนมัติเมื่อหมดเวลา” โดยทั่วไปเพียงเปิดใช้เส้นทางคืนเงิน ยังต้องมีผู้ส่งและรอการยืนยัน
  • “แค่ H(x) = h ก็คือสัญญาทั้งหมด” ลายเซ็น แขนง ฟิลด์ กฎเชน การเพิกถอน และสิทธิ์ก็สำคัญ
  • “กำหนดเวลาเท่ากันทั้งสองฝั่งยุติธรรม” ตัวกลางหรือผู้ทำทีหลังต้องมีเวลาสำรองต้นน้ำหลังรู้ x
  • “เห็นพรีอิมเมจแล้วรับรองว่ามีเวลารับเงิน” การยืนยัน reorganization ความแออัด ค่าธรรมเนียม และการเซ็นเซอร์อาจใช้เวลาหมด
  • “อะตอมมิกหมายถึงสองเชนเปลี่ยนด้วยธุรกรรมเดียวที่แบ่งไม่ได้” ระบบประสานสถานะแยกกัน จึงยังมีการยกเลิก คืนเงิน และสถานะข้างเดียวชั่วคราว
  • “HTLC ไม่เปิดเผยตัวตนและตัดความไว้วางใจทั้งหมด” มันอาจรั่วสัญญาณและยังพึ่งโค้ด เชน กุญแจ การเฝ้าดู และการปฏิบัติการ

หัวข้อที่เกี่ยวข้อง

แหล่งข้อมูล

การนำทาง

ค้นหาในวิกิ...