跳到正文
Financial Context Wiki

雜湊時間鎖合約（HTLC）

雜湊時間鎖合約允許收款方在到期前用原像領取款項，並允許付款方在到期後透過另一條支出路徑退款。了解 HTLC 如何協調支付通道與原子交換，以及它仍可能在哪裡失效。

更新於

僅供教育參考，不構成投資、法律或安全建議。HTLC 的安全性取決於具體腳本或合約、鏈規則、確認策略、費用、監控和及時操作。

直接答案

雜湊時間鎖合約（HTLC）是一種有兩條競爭性支出路徑的條件付款。到期前，收款方可公開一個值 x，使其雜湊與已承諾值 h = H(x) 相符，並滿足所需簽章或授權來領取資金。到期後，付款方可使用退款路徑。臨界點上的確切先後順序由鏈和合約決定，不能只按自然語言中的「之前」理解。

雜湊鎖把動作關聯起來：參與者在付出一筆下游款項後，得知同一原像便可能結算相關的上游付款。時間鎖限制資金保持條件狀態的時長。支付通道協定用這些性質轉發付款，原子交換協定則可用它們協調不同系統上的轉移。

HTLC 並不會自動帶來無須信任、原子性、隱私或自動執行。安全還取決於腳本或合約正確、雜湊與原像編碼相容、到期時間錯開、最終性假設、手續費可用、持續監控，以及交易能在截止前確認。Lightning 的 HTLC 是一種有明確規範的比特幣設計；其他鏈上的合約語意可能有實質差異。

  • 雜湊分支： 在該路徑仍有效時公開所需原像，並滿足成功路徑的授權。
  • 逾時分支： 在適用的絕對或相對時間鎖成熟後，滿足退款路徑的授權。

運作原理

以單筆條件付款為例，假設 Bob 選擇一個全新且不可預測的原像 x，計算 h = H(x)，並把 h 交給 Alice。Alice 按一組承諾 h、指定授權參與方並定義到期點 T 的規則鎖定資金。

  • Alice 在出資前核對雜湊演算法、位元組編碼、金額、資產、收款方、退款目的地、鏈和到期點。
  • Bob 核對實際獲得資金的輸出或已部署合約，而不是相信交易草稿或介面顯示。
  • 若 Bob 走成功分支領取，他提供 x；支出邏輯檢查 H(x) = h 以及所需授權。
  • x 在鏈上公布或透過協定傳遞後，Alice 或中間節點可能據此結算另一筆使用相同付款雜湊的 HTLC。
  • 若成功分支未及時使用，退款分支在 T 時具備資格；具備資格並不會自行廣播或確認退款。
  • 參與者仍須建構或保留正確交易、支付足夠費用、提交交易、監控替換與衝突，並取得所需確認深度。
  • 一旦 x 已向對手方或公鏈公開，就應視為已經洩露，不要把它重複用於無關條件。

比特幣區分絕對鎖與相對鎖。BIP 65 的 OP_CHECKLOCKTIMEVERIFY 透過交易鎖定時間，將支出限制到指定區塊高度或區塊時間之後；BIP 112 的 OP_CHECKSEQUENCEVERIFY 將支出限制到輸入達到足夠相對年齡之後。腳本還必須搭配相容的交易欄位。因此，時間鎖是驗證規則，不是定時排程器。

在 Lightning 中，update_add_htlc 攜帶金額、payment_hash 和 cltv_expiry。每個轉發節點給下游 HTLC 設定的到期點早於對應上游 HTLC，使其在得知原像後仍有時間向上游領取。BOLT 3 定義了承諾輸出、HTLC-success 與 HTLC-timeout 路徑，包括簽章、撤銷處理、塵額裁剪和附加延遲；只有兩分支示意圖並不能構成完整的 Lightning 通道實作。

範例

設想一個 Alice 用 1 BTC 交換 Bob 的 20 ETH 的教學範例。它只說明操作順序；正式環境中的比特幣與以太坊實作需要針對各自鏈審查程式碼，不應照搬這些名義期限。

  • Alice 產生全新的 x 和 h = H(x)，隨後鎖定 1 BTC，使 Bob 可憑原像領取，而 Alice 在 48 hours 後有退款路徑。
  • Bob 檢查比特幣交易及所選確認策略後，按相容的雜湊與編碼規則鎖定 20 ETH；Alice 的成功路徑在 24 hours 後結束，Bob 的退款路徑隨後生效。
  • Alice 在公開 x 領取 20 ETH 前，核對以太坊鏈 ID、合約位元組碼與地址、代幣或原生資產、金額、參與方、h 以及兩條可呼叫路徑。
  • Bob 從成功領取或約定的協定訊息中得知 x，並在較晚的截止點前嘗試比特幣成功路徑。
  • 如果交換在原像公開前停止，每筆退款都只能按各自鏈規則取得資格；雙方都必須提交相應退款交易並等待確認。

48 hours 與 24 hours 的間隔是回應緩衝，並非普適安全參數。必須同時為兩套系統建立重組、出塊時間波動、最終性、合約執行、中繼假設、記憶體池策略、手續費激增、審查和操作延遲的模型。後行動的一方不能僅因介面顯示「已確認」就繼續。

風險

  • 承諾錯誤： 兩邊的雜湊演算法、原像長度或編碼不同，導致同一個 x 無法同時滿足兩邊條件。
  • 對象錯誤： 實際出資的輸出、鏈 ID、合約地址、位元組碼、資產、金額、收款方或退款目的地與介面聲稱的不符。
  • 到期順序不安全： 截止點相同或間隔不足，使中間節點或交換對手在付出下游資金後無法向上游領取。
  • 邊界理解錯誤： 區塊高度、區塊時間、時間戳、相對年齡，以及 < 與 <= 等合約比較並不等價。
  • 不會自動退款： 成熟只會讓一筆支出變得有效；錢包、節點、使用者或監控服務仍須採取行動。
  • 費用與塵額失敗： 領取可能不經濟、從 Lightning 承諾中被裁剪、因費率太低而卡住，或因沒有鏈的原生費用資產而無法執行。
  • 確認與重組風險： 看到交易或原像不等於任一鏈上的結算已不可逆。
  • 競爭與壅塞風險： 成功支出、逾時支出、替換、衝突或惡意拖延都可能耗盡回應窗口。
  • 實作風險： 腳本、智慧合約、錢包、簽章、nonce、RPC 或用戶端缺陷可能破壞預期路徑。
  • 監控風險： 離線參與者可能錯過原像公開、到期、強制關閉、交易替換或最後實際廣播時點。
  • 隱私洩漏： 重複使用的付款雜湊、公開原像、金額、時間和通道事件可能幫助關聯轉帳或路徑。
  • 選擇權與拖延： 一方可鎖住對方流動性後放棄；條件結算不保證完成，也不補償延遲。

在投入有意義的價值前，應以可忽略金額測試成功與退款兩條路徑，記錄準確對象和截止點，保留手續費儲備，並明確故障時由誰監控和廣播。

常見誤解

  • 「逾時後資金會自動退回。」 通常逾時只會啟用退款支出；仍須有人廣播並等待確認。
  • 「滿足 H(x) = h 就是全部合約。」 簽章、腳本分支、交易欄位、鏈規則、撤銷邏輯和合約授權同樣重要。
  • 「兩邊使用相同到期點最公平。」 轉發節點或後行動方在得知 x 後需要刻意保留的上游緩衝。
  • 「看到原像就保證來得及領取。」 確認延遲、重組、壅塞、費用和審查都可能耗盡剩餘窗口。
  • 「原子意味兩條鏈在一筆不可分交易中同時改變。」 跨鏈交換協調的是分開的狀態轉換；中止與退款路徑仍存在，也可能暫時出現單邊狀態。
  • 「HTLC 匿名並消除了所有信任。」 它可能洩漏關聯訊號，仍依賴協定程式碼、鏈行為、金鑰、監控和操作假設。

相關主題

來源

導覽

搜尋知識庫...