SATS.VN – Bitcoin Layer 2 & Tokenization Research ₿ Về trang chủ SATS.VN
HTLC · Hashlock · Timelock · Lightning Network · Atomic Payment

HTLC
LÀ GÌ?

Hash Time-Locked Contract – Nền Tảng Trustless Của Lightning Network
₿ SATS.VN – Knowledge Base ₿ Chủ đề: Lightning Network ₿ Nội dung: Kỹ thuật chuyên sâu – Trung lập

Tóm tắt

HTLC (Hash Time-Locked Contract) là cơ chế cryptographic cho phép Lightning Network định tuyến thanh toán qua nhiều node trung gian một cách trustless — không ai trong route có thể giữ tiền mà không chuyển tiếp. Kết hợp hai primitive: hashlock (chỉ người biết preimage mới unlock được) và timelock (tự động refund sau T block nếu không claim). HTLC đảm bảo tính atomic: hoặc cả route thanh toán thành công, hoặc không ai mất tiền. Đây là lý do Lightning Network có thể hoạt động trustless qua hàng chục hop mà không cần biết hay tin tưởng các node trung gian.

1Vấn Đề Cần Giải Quyết

Hãy tưởng tượng: Alice muốn gửi 10.000 sat cho Dave qua route Alice → Bob → Carol → Dave. Alice không biết Bob và Carol — họ chỉ là các node trên Lightning Network. Làm thế nào để:

  • Alice chắc chắn tiền đến được Dave (không bị Bob hay Carol giữ lại)
  • Bob và Carol chắc chắn được trả phí routing nếu họ chuyển tiếp đúng
  • Nếu Carol không chuyển tiếp, Alice không mất tiền
  • Không cần Alice tin tưởng Bob, Carol, hay Dave

Đây là bài toán trustless multi-hop payment routing — và HTLC là giải pháp. Không có HTLC, Lightning Network không thể tồn tại theo cách trustless.

2HTLC Là Gì? Hai Thành Phần Cốt Lõi

HTLC là một dạng smart contract đặc biệt trong Bitcoin Script, kết hợp hai cơ chế khóa bổ sung nhau:

🔐 Hashlock

  • Payment hash H = SHA256(preimage)
  • Chỉ người biết preimage (giá trị gốc tạo ra H) mới unlock được
  • Preimage do Dave tạo ra và chỉ Dave biết ban đầu
  • Khi Dave reveal preimage → tiền giải phóng

⏰ Timelock

  • Nếu không có ai claim trong vòng T block → tiền tự động refund về sender
  • Mỗi hop trong route có timelock ngắn hơn hop trước
  • Đảm bảo tiền không bị "kẹt" mãi mãi
  • Dùng CLTV (CheckLockTimeVerify) trong Bitcoin Script

Kết hợp lại: HTLC là conditional payment — "Trả X sat cho ai reveal được preimage của hash H, trong vòng T block. Nếu không có ai claim sau T block, hoàn tiền về tôi." Bitcoin Script enforce điều này on-chain nếu cần.

3Hashlock – Khóa Bằng Hash Function

Dave tạo một số ngẫu nhiên bí mật gọi là preimage (R). Tính H = SHA256(R) và chia sẻ H (payment hash) công khai với Alice khi Alice muốn thanh toán. Không ai ngoài Dave biết R.

# Hashlock mechanism ## Dave tạo (giữ bí mật): preimage R = random_secret_bytes() payment_hash H = SHA256(R) # H là public, R là secret ## Alice tạo HTLC với Bob: "Tôi sẽ trả Bob 10.000 sat NẾU Bob reveal R thỏa SHA256(R) == H" ## Bob tạo HTLC tương tự với Carol ## Carol tạo HTLC tương tự với Dave ## Dave nhận HTLC từ Carol → reveal R để nhận tiền ## Carol thấy R → dùng R claim tiền từ Bob ## Bob thấy R → dùng R claim tiền từ Alice ## Preimage lan truyền ngược route, tiền chạy xuôi route → atomic!
Tính chất quan trọng của SHA256: Biết H không giúp tính ngược ra R. Không ai trong route (Bob, Carol) có thể giả mạo hay tự tạo R hợp lệ. Chỉ khi Dave chủ động reveal R thì tiền mới giải phóng — Dave không có lý do gì để không reveal nếu đã nhận được HTLC với đúng số tiền.

4Timelock – Khóa Bằng Thời Gian (CLTV)

Timelock giải quyết trường hợp: nếu Dave không claim (offline, từ chối), tiền của Alice không bị kẹt mãi mãi. Mỗi HTLC trong route đặt một thời hạn — nếu không có preimage được reveal trong thời hạn đó, tiền tự động refund về người tạo HTLC.

Điểm quan trọng: timelock giảm dần theo chiều route. Hop gần Alice có timelock dài hơn hop gần Dave:

HopHTLCTimelockLý do
Alice → BobHTLC_ABT+40 block (~6.7h)Dài nhất — Alice cần đủ thời gian để claim refund
Bob → CarolHTLC_BCT+30 block (~5h)Bob cần claim từ Alice trước khi HTLC_AB hết hạn
Carol → DaveHTLC_CDT+20 block (~3.3h)Carol cần claim từ Bob trước khi HTLC_BC hết hạn

Khoảng cách giữa các timelock (delta = 10 block trong ví dụ) đủ để mỗi node có thời gian claim tiền từ hop trước khi timelock của mình hết hạn — kể cả trong điều kiện mạng chậm hoặc block thời gian bất thường.

Timelock và force-close risk: Nếu một node trong route biến mất khi HTLC đang pending, các node khác phải force-close channel on-chain trước khi timelock hết hạn. Đây là chi phí ẩn của Lightning: trong trường hợp route failure, có thể cần on-chain transaction để settle — tốn phí và thời gian.

5Flow Thanh Toán Đa Hop – Bước Từng Bước

Phase 1: HTLC được tạo từ Alice → Dave (lock tiền)

Alice
Sender
HTLC(H, 10ksats, T+40)
Bob
Hop 1
HTLC(H, 9.9ksats, T+30)
Carol
Hop 2
HTLC(H, 9.8ksats, T+20)
Dave
Receiver

Phase 2: Dave reveal preimage R → tiền giải phóng ngược route

Alice
Sender
R reveal → -10ksats
Bob
+100 sat fee
R relay → -9.9ksats
Carol
+100 sat fee
R reveal → +9.8ksats
Dave
+9.8ksats
Phase 1: Lock (HTLC forward) Phase 2: Settle (preimage backward)

Toàn bộ quá trình này xảy ra off-chain — không có Bitcoin transaction nào được broadcast trong happy path. Chỉ khi có dispute hoặc route failure mới cần on-chain settlement. Đây là lý do Lightning Network có thể xử lý hàng triệu transaction mà không làm tắc nghẽn Bitcoin mainchain.

6Tại Sao HTLC "Atomic"?

Atomic có nghĩa là: toàn bộ payment hoặc thành công hoàn toàn, hoặc thất bại hoàn toàn. Không có trạng thái "nửa vời" — tiền không thể biến mất ở giữa.

  • Nếu Dave reveal R: Tất cả HTLC trong route được settle — Dave nhận tiền, Bob và Carol nhận fee, Alice trả đúng số tiền cam kết. ✅
  • Nếu Dave không reveal R (offline, từ chối): Tất cả HTLC hết hạn timelock theo thứ tự từ Carol ngược về Alice — mọi người nhận lại tiền của mình. ✅
  • Nếu Bob biến mất giữa chừng: Alice force-close channel với Bob on-chain, HTLC được settle theo timelock. Alice không mất tiền, chỉ tốn phí on-chain và thời gian. ✅
  • Không thể: Bob giữ tiền của Alice mà không chuyển cho Carol, hoặc Carol giữ tiền mà không chuyển cho Dave. HTLC không cho phép điều này về mặt cryptographic. ✅
HTLC là ví dụ điển hình của "trustless by design": Không cần biết Bob và Carol là ai, không cần biết họ honest hay không — Bitcoin Script và timelock đảm bảo bạn luôn có thể lấy lại tiền nếu route thất bại. Đây là sự khác biệt căn bản giữa Lightning và các hệ thống payment tập trung.

7HTLC Trong Bitcoin Script Thực Tế

# HTLC Bitcoin Script (simplified) OP_IF # Happy path: receiver claim với preimage OP_SHA256 <payment_hash> OP_EQUALVERIFY <receiver_pubkey> OP_CHECKSIG OP_ELSE # Timeout path: sender refund sau T block <locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP <sender_pubkey> OP_CHECKSIG OP_ENDIF # Để claim happy path: cần (preimage + receiver_sig) # Để refund: cần (sender_sig) sau khi block height > locktime # Bitcoin Script enforce cả hai — không cần trust bất kỳ ai # Trong Lightning, script này nằm trong commitment transaction # Chỉ được broadcast on-chain khi có dispute — thường không cần

Trong thực tế Lightning, HTLC script được nhúng vào commitment transaction của mỗi channel — transaction này được ký sẵn nhưng không được broadcast, chỉ broadcast nếu cần force-close. Với Taproot, HTLC script được ẩn trong tapscript leaf, chỉ reveal khi cần thực sự.

8PTLC – Thế Hệ Tiếp Theo Của HTLC

HTLC có một điểm yếu về privacy: payment hash H giống nhau trên tất cả các hop trong route — bất kỳ node trung gian nào cũng có thể nhận ra họ đang xử lý cùng một payment nếu họ kiểm soát nhiều hop.

HTLC (hiện tại)

  • Payment hash H giống nhau trên tất cả hop
  • Node kiểm soát hop 1 và hop 3 có thể link payment
  • Dùng SHA256 hashlock
  • Tương thích với tất cả Lightning node hiện tại

PTLC (Point Time-Locked Contract)

  • Dùng Schnorr signature + adaptor signature
  • Mỗi hop có "secret" riêng biệt — không link được
  • Privacy tốt hơn đáng kể
  • Cần Taproot (đã có) + protocol upgrade Lightning

PTLC đang được nghiên cứu và phát triển trong cộng đồng Lightning. Tương thích ngược với infrastructure hiện tại nhưng cần upgrade phần mềm của toàn bộ node. Timeline không rõ ràng — có thể vài năm tới. Đọc thêm về kiến trúc Lightning Network đầy đủ tại SATS.VN.

?FAQ Về HTLC

Tiền có thể "bị kẹt" trong HTLC không?
Về lý thuyết không — timelock đảm bảo tiền luôn được giải phóng sau T block. Thực tế: nếu node đối diện biến mất khi HTLC đang pending, bạn phải đợi timelock hết hạn (có thể vài giờ đến vài ngày) và force-close channel on-chain. Tiền sẽ về, nhưng cần đợi và trả phí on-chain. "Kẹt" tạm thời là có thể — mất vĩnh viễn thì không.
Node trung gian có thể đánh cắp tiền qua HTLC không?
Không — đây là thuộc tính thiết kế cốt lõi của HTLC. Bob không thể nhận tiền từ Alice mà không chuyển preimage cho Alice, và không thể nhận preimage từ Carol mà không trả tiền cho Carol. Chuỗi HTLC atomic đảm bảo điều này. Điều duy nhất node trung gian "xấu" có thể làm là từ chối route (không chuyển tiếp) — dẫn đến payment fail và Alice phải thử route khác.
HTLC khác smart contract Ethereum như thế nào?
HTLC là Bitcoin Script — stack-based, có giới hạn, không Turing-complete. Ethereum smart contract là EVM bytecode — có thể làm bất kỳ computation nào. HTLC chỉ làm được một việc (conditional payment với hashlock + timelock) nhưng làm rất tốt và hiệu quả. Đây là thiết kế có chủ đích — không cần Turing-complete để giải quyết bài toán thanh toán trustless.
Tại sao Lightning dùng SHA256 cho payment hash?
SHA256 là hash function được Bitcoin dùng rộng rãi, đã được kiểm chứng security nhiều năm, và có opcode native trong Bitcoin Script (OP_SHA256). Đây là lựa chọn thực dụng — không cần opcode mới, không cần soft fork, tương thích với Bitcoin Script hiện tại. PTLC sẽ dùng Schnorr adaptor signature thay thế, an toàn hơn về mặt lý thuyết nhưng phức tạp hơn để implement.
Muốn Hiểu Toàn Diện Lightning Network?

HTLC là nền tảng, nhưng Lightning còn nhiều hơn thế: channel liquidity, watchtower, LSP, routing algorithm và giới hạn thực tế. Đọc phân tích kỹ thuật đầy đủ tại SATS.VN.

→ Đọc Phân Tích Tổng Thể Tại SATS.VN