---
title: "สัญญาล็อกด้วยแฮชและเวลา (HTLC)"
description: "HTLC ทำให้ผู้รับใช้พรีอิมเมจรับเงินก่อนหมดอายุ และให้ผู้จ่ายใช้เส้นทางอีกแบบขอคืนหลังหมดอายุ เรียนรู้บทบาทในช่องทางการชำระเงินและอะตอมมิกสวอป รวมถึงความเสี่ยง"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

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

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

<a id="answer"></a>

## คำตอบโดยตรง

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

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

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

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

<a id="mechanism"></a>

## วิธีทำงาน

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 และเวลาหน่วง แผนภาพสองแขนงจึงไม่ใช่ช่องทางที่สมบูรณ์

<a id="example"></a>

## ตัวอย่าง

ตัวอย่างเพื่อการเรียนรู้ให้ 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 ค่าธรรมเนียม การเซ็นเซอร์ และความล่าช้าของทั้งสองระบบ ฝ่ายที่ทำทีหลังไม่ควรเดินหน้าจากคำว่า “ยืนยันแล้ว” บนหน้าจอเพียงอย่างเดียว

<a id="risks"></a>

## ความเสี่ยง

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

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

<a id="misconceptions"></a>

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

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

<a id="related"></a>

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

- [แฮชเชิงการเข้ารหัส](/th/crypto/cryptographic-hash/)
- [กระเป๋า MPC](/th/crypto/mpc-wallet/)
- [ความเสี่ยงของโมดูลหลายลายเซ็น](/th/crypto/multisig-module-risk/)
- [สัญญาอัจฉริยะ](/th/crypto/smart-contract/)
- [ช่องทางสถานะ](/th/crypto/state-channels/)

<a id="sources"></a>

## แหล่งข้อมูล

- [BIP 65: OP_CHECKLOCKTIMEVERIFY](https://bips.dev/65/) - Bitcoin Improvement Proposals (เข้าถึง: 2026-08-20)
- [BIP 112: CHECKSEQUENCEVERIFY](https://bips.dev/112/) - Bitcoin Improvement Proposals (เข้าถึง: 2026-08-20)
- [BOLT #2: โปรโตคอลเพียร์สำหรับช่องทาง](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md) - Lightning BOLTs (เข้าถึง: 2026-08-20)
- [BOLT #3: รูปแบบธุรกรรมและสคริปต์ Bitcoin](https://github.com/lightning/bolts/blob/master/03-transactions.md) - Lightning BOLTs (เข้าถึง: 2026-08-20)
- [BOLT #4: โปรโตคอลการกำหนดเส้นทางแบบ onion](https://github.com/lightning/bolts/blob/master/04-onion-routing.md) - Lightning BOLTs (เข้าถึง: 2026-08-20)

Source: https://wiki.fcontext.com/th/crypto/htlc/index.mdx