閃電網絡 HTLC 原理：拆解雜湊鎖、時間鎖與多跳路由如何完成鏈下支付

在比特幣閃電網絡（Lightning Network）中發起一筆支付，理想狀態下款項可在數百毫秒內迅速到賬，且鏈下結算通常不直接產生比特幣鏈上手續費。這筆支付中間可能跨越多個互不相識的轉發節點，每個節點都在執行一項看似高風險的操作：先替下游墊付資金，再等待上游結算。閃電網絡讓陌生節點在零信任前提下協同轉發，核心依賴的是一項精密的鏈下合約機制——雜湊時間鎖定合約（HTLC, Hash Time-Locked Contract）。將這套機制拆解開來，核心在於雜湊鎖（Hash Lock）、時間鎖（Time Lock）以及協調兩者的多跳路由（Multi-Hop Routing）技術。

一筆付款走三跳：鏈下合約的轉發鏈條

假設 Alice 要向 Dave 支付款項。Alice 與 Bob 之間建有通道，Bob 與 Carol 有通道，Carol 與 Dave 也有通道，但 Alice 與 Dave 之間並無直接通道。Alice 無需為了單次轉賬特意在鏈上開啟新通道，而是讓資金沿著 Alice → Bob → Carol → Dave 的多跳路徑在鏈下推進。

這條支付路徑由 Alice 本地計算得出。她運行路由演算法，挑選出一串流動性充足、手續費符合預期的中繼節點，並構建出洋蔥數據包（Onion Packet）。Bob 收到後僅能解密出屬於自己的一層數據，獲取轉發目標 Carol、轉發金額以及指定的時間鎖參數；Bob 無法獲知 Alice 之前是否還有前序節點，也無法確認最終收款方是否為 Dave。Carol 拆解其所在層級的數據後，才知曉下一跳即為終點 Dave。

閃電網絡的洋蔥路由標準收錄於 BOLT 4 洋蔥路由規範。發送節點利用臨時私鑰與各跳節點公鑰進行 ECDH（橢圓曲線迪菲-赫爾曼密鑰交換） 派生出共享密鑰，進而以對稱加密封裝每跳的負載數據（Hop Payload）。這種分層加密設計確保中間節點無法回溯完整路徑。

整條轉發鏈條上流動的並非單純的轉賬指令，而是三份彼此咬合的獨立 HTLC：Alice 向 Bob 提供一份、Bob 向 Carol 提供一份、Carol 最終向 Dave 提供一份。三份合約通過同一個密碼學條件相連，任何一環出現中斷，全路徑資金均可安全回滾。

雜湊鎖：以密碼學原像確立資金歸屬

原像（Preimage）與支付雜湊（Payment Hash）

收款方 Dave 生成一個 32 位元組的密碼學隨機數，稱為 原像（Preimage），作為最終的提款憑證。Dave 的節點計算該原像的 SHA256 雜湊值，生成 支付雜湊（Payment Hash）。Dave 將 Payment Hash 寫入發票（如 BOLT 11 發票）並發送給 Alice，而 Preimage 則由 Dave 嚴密保管，在未收到合約承諾前絕不公開。

Alice 獲取發票中的 Payment Hash，但無法推導出 Preimage。Alice 能夠利用該 Payment Hash 構建合約，將資金鎖定在一個僅有 Dave 能夠開啟的密碼學條件中——因為全世界只有 Dave 掌握著能生成該雜湊的原像鑰匙。

整條多跳路徑上的每份 HTLC 均綁定同一個 Payment Hash。Alice 對 Bob、Bob 對 Carol、Carol 對 Dave 所開立的 HTLC，其雜湊解鎖條件完全一致。當 Dave 在終點出示 Preimage 提取資金時，該 Preimage 會沿著路由節點逐跳反向傳遞，每一跳節點均可憑藉此原像解鎖上一跳承諾的資金。

自發收款（Keysend）的密碼學反轉

在無需發票的自發收款（Keysend / Spontaneous Payment）場景中，收款方並未預先給出 Payment Hash。此時由付款方在本地生成 Preimage，計算對應的 Payment Hash 用於構建 HTLC，同時利用洋蔥路由中的 TLV（Type-Length-Value）擴展欄位將 Preimage 加密夾帶給收款節點。收款節點解析出 Preimage 後完成結算。其本質機制未變，僅由發送方代為生成解鎖密鑰。

雜湊鎖解決了兩大核心問題：第一，確立了只有掌握特定原像的主體具備資金提取權；第二，出示 Preimage 的操作在密碼學上直接構成不可抵賴的付款成功收據，無需依賴任何第三方中介裁決。

時間鎖：防範資金懸置的雙重計時器

雜湊鎖僅界定了提款許可權，但並未限制提款時限。若無時間約束，一旦 Dave 拒絕出示 Preimage 或中途離線，Alice、Bob 與 Carol 的資金將被無限期鎖死在通道中。時間鎖的作用即為每份 HTLC 設定鏈上安全邊界：一旦超期未結算，出資方即可通過鏈上超時交易全額收回本金。

在閃電網絡體系中，涉及兩種不同特性的時間鎖機制：

HTLC 超時退款依賴 CLTV 機制。在鏈下簽署承諾交易時，該數值在合約中被指定為 cltv_expiry，代表合約贖回的絕對區塊高度閾值。

時間鎖逐跳遞減（Delta）的關鍵防禦

為了確保轉發路徑的安全，各跳 HTLC 的超時高度必須沿著轉發方向逐級遞減：

• Carol 對 Dave 的合約過期高度最早（例如區塊高度 921,600）；
• Bob 對 Carol 的合約過期高度需更晚（例如 921,640）；
• Alice 對 Bob 的合約過期高度最晚（例如 921,680）。

相鄰合約之間的區塊差值稱為 cltv_expiry_delta。該參數由各節點在通道宣告（BOLT 7）中公開，代表轉發節點為下游墊資時所要求的安全緩衝期。若設置過小，節點在鏈上處理擁堵與廣播交易的時間將嚴重不足；若設置過大，付款路徑會因整體鎖定時間過長而降低路由競爭力。

此時間差機制確保了原子回滾能力：若 Dave 遲遲未能在區塊 921,600 前出示 Preimage，Carol 有權在達到 921,600 後將承諾交易廣播上鏈，執行超時退款贖回資金。此時 Bob 對 Carol 的合約尚有 40 個區塊才到期，Bob 擁有充足時間確認 Carol 的鏈上處理結果，繼而在自身與 Alice 的合約超時後依序回滾，杜絕轉發節點兩頭受損的風險。

腳本構造：比特幣鏈上 HTLC 輸出邏輯

在通道日常運行過程中，HTLC 作為承諾交易中的未結算輸出存在於雙方的鏈下狀態中。只有在節點異常或發生爭議時，該輸出才會被廣播上鏈。根據 BOLT 3 交易規範，簡化後的 HTLC 核心見證腳本邏輯如下：

OP_IF
## 成功路徑：出示正確的原像與收款方簽名
    OP_SIZE 32 OP_EQUALVERIFY
    OP_HASH160 <RIPEMD160(Payment_Hash)> OP_EQUALVERIFY
    <remote_htlc_pubkey> OP_CHECKSIG
OP_ELSE
## 超時路徑：達到指定區塊高度後由出資方取回
    <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
    <local_htlc_pubkey> OP_CHECKSIG
OP_ENDIF

成功分支（OP_IF）要求花費者在解鎖見證（Witness）中提供一個長度為 32 位元組的數據，其經雙重雜湊（HASH160，即 RIPEMD160 後接 SHA256）後須與腳本中的雜湊值一致，並附上收款方簽名。超時分支（OP_ELSE）則要求區塊高度達到 cltv_expiry，由出資方簽名後將資金原路收回。

訊息互動：BOLT 2 規範下的成功與失敗流轉

鏈下 HTLC 的建立與結算依循 BOLT 2 對等協議規範 中定義的訊息序列執行：

1. 合約提議：Alice 向 Bob 發送 update_add_htlc，包含 Payment Hash、轉發金額、cltv_expiry 及加密洋蔥數據包。
2. 逐跳中繼：Bob 驗證自身流動性與時間鎖參數無誤後，扣除轉發手續費，向 Carol 發送相應的 update_add_htlc。Carol 隨後向 Dave 遞送最後一跳合約。
3. 原像揭示與結算：Dave 校驗金額與 Payment Hash 無誤後，向 Carol 發送 update_fulfill_htlc，正式揭示 Preimage。Carol 獲取 Preimage 後立即向上游 Bob 發送 update_fulfill_htlc，Bob 再轉發給 Alice。
4. 狀態提交與舊狀態撤銷：相鄰節點間互相發送 commitment_signed 與 revoke_and_ack，銷毀舊有承諾狀態，確立結算後的通道餘額分配。

若支付流程受阻（例如終點拒收或發票失效），Dave 將發送 update_fail_htlc 並附帶洋蔥加密的失敗代碼。若中間節點發現通道容量不足或時間鎖過於臨近，則會主動返回由 BOLT 4 定義的中繼錯誤碼（例如 temporary_channel_failure 或 expiry_too_soon），合約沿路反向拆除，資金無損解凍。

進階議題：攻擊面、演進與技術局限

阻塞攻擊（Channel Jamming）與關聯性隱私

由於同一筆支付在全路徑上共享相同的 Payment Hash，具備廣域通道監控能力的實體可能藉此分析多條通道的關聯交易，削弱洋蔥路由的隱私優勢。此外，惡意主體可發起大量小額且具備極長時間鎖的 HTLC 請求，惡意佔用節點的通道並發名額（max_accepted_htlcs）與流動性，實施阻塞攻擊（Jamming Attack）。閃電網絡社群正在探索 HTLC 背書機制（HTLC Endorsement）以及有條件中繼收費等防護方案。

PTLC（點時間鎖定合約）的前瞻演進

為了徹底解決 Payment Hash 的跨跳關聯問題，基於 Schnorr 簽名與適配器簽名（Adaptor Signature）的 PTLC（Point Time-Locked Contract） 方案被提出。PTLC 使路徑上的每一跳合約均採用互不相同的隨機純量與點，消除了全網統一的雜湊特徵，顯著增強支付隱私性，並天然契合無條件原子交換等多種複雜金融邏輯。