55 / 736HTLC

HTLC

Hashed Timelock Contract — ハッシュと時間の条件

HTLC は、正しい秘密の値を明かすことを支払いの条件とし、支払いが完了しない場合には資金を回収する経路を用意します。Lightning Network では、仲介者の約束だけに頼らずに送金できます。ただし、この保護には有効な署名と期限に間に合う対応が必要です。

HTLC は Hashed Timelock Contract の略です。条件付きの支払いで、一方の経路では、ハッシュを計算すると、あらかじめ知られた値(デジタルな指紋)に一致する秘密の値が必要です。もう一方では、時間条件を満たした後に資金を回収できます。秘密の値を preimage と呼びます。ウォレットのパスワードではありません。その値を知っていても必要な署名の代わりにはならず、時間が経っても自動返金はされません。

アンナは Lightning Network でパヴェルに 20,000 sat を送りたいとします。Sat は satoshi の略で、ビットコインのチェーン上で扱う最小単位です。共通の支払いチャネルはありませんが、双方がエヴァを経由する適切な接続を持っています。チャネルは二者間のビットコインの配分に関する合意で、支払いのたびに新しいトランザクションをブロックに記録せず更新できます。エヴァはパヴェルに条件付きで 20,000 sat を提示し、アンナはエヴァに 20,010 sat を提示します。この単純化した例では、差額の 10 sat がエヴァの手数料です。二つのチャネルで残高が連動して変わるのであり、同じ一枚のコインが通り抜けるわけではありません。パヴェルは自分の条件を満たす秘密を知っており、エヴァはその値を使ってアンナ側の条件を満たせます。パヴェルの約束だけを頼りに、先に取り消せない支払いをする必要はありません。金額は仕組みを示す例で、一般的な手数料や推奨額ではありません。 [1]

パヴェルは支払い用にランダムな32バイトの秘密、payment_preimage を用意します。SHA-256 がそこから payment_hash を計算します。公開された値が正しい指紋を生むかは簡単に検証できますが、適切に選んだ秘密を指紋だけから求めることは現実的に不可能です。通常の BOLT 11 請求書、つまり Lightning の支払い要求は、p フィールドにハッシュを含み、preimage 自体は含みません。パヴェルが支払い条件を満たすと、秘密は経路を逆向きに伝わり、対応する HTLC を結び付けます。s フィールドの payment_secret は別の値で、受取人の正しい支払い処理に役立ちますが、preimage の代用にはなりません。どの値も Seed Phrase(ウォレットを復元するための単語列) やウォレットの秘密鍵ではありません。 [1] [4]

二つの支払いが同じ期限なら、パヴェルが遅く秘密を公開したとき、エヴァは受信側の支払いを受け取るのに間に合わないかもしれません。そのためアンナからの受信 HTLC の期限は、エヴァからパヴェルへの送信 HTLC より後になります。この差 cltv_expiry_delta がエヴァの余裕です。相手が応答しなくなり、ビットコインのオンチェーントランザクションで合意を実行する場合にも必要です。余裕は正確な分単位の時間ではなくブロック数で測り、遅延やチェーン再編成も考慮します。安全な設定はソフトウェアとチャネルのルールに従います。余裕が小さすぎると資金が危険にさらされます。 チェーンの再編では、チェーンの一部が別の有効な分岐に置き換わるため、それまでの取引の確認状況が変わることがあります。 [1]

Lightning の cltv_expiry はブロック高、つまりチェーン内のブロックの位置です。Unix timestamp(日付と時刻を秒数で表す値)や、秒単位で示される BOLT 11 請求書の有効期間ではありません。時間条件を満たすと、秘密なしで決済する timeout 経路が使える場合があります。資金は勝手に動きません。支払いチャネルを管理するプログラムである Lightning ノードが、チャネル更新を正しく完了するか、該当するオンチェーントランザクションを使う必要があります。有効な preimage も期限到来で自動的に無効にはなりません。同じ出力(使用条件が付いた金額)がまだ別の方法で使用されていなければ、複数の許可された経路が競合することがあります。ただし両方の使用が同じ有効なチェーンで確認されることはありません。適時の対応も安全性の一部です。 [1] [4] [5]

HTLC は条件を結び付けますが、どの金額でもどの経路でも通せるわけではありません。エヴァには送信方向の十分な資金、つまり流動性と、追加の保留 HTLC を扱う空き枠が必要です。上限、手数料、接続できないノードによって支払いは止まることがあります。保留中の試行が適切に解決するまで、一部の資金が拘束される場合もあります。ウォレットの状態は試行全体の情報として読み、一つのメッセージだけで結果を判断しないことが大切です。preimage の開示はビットコイントランザクションの確認とは異なります。通常の成功した Lightning 支払いはチャネル更新で決済され、個々の支払いを新しいブロックに記録しません。 [1] [3]

以下は技術的な参照資料です。チャネル状態には各金額の帰属と、まだ保留中の HTLC が記録されます。Commitment transaction はその状態をオンチェーンで実行できる署名済みビットコイントランザクションです。update_add_htlc は追加の提案、update_fulfill_htlc は履行、update_fail_htlc は失敗の通知です。変更を通知するだけでは足りません。commitment_signed と revoke_and_ack を通じて、新状態の署名と、旧状態の使用を危険にする情報を交換します。BOLT 2 に従い、双方が該当の更新を取り消せない形で確定してから、それに依存する次の義務へ進みます。この参加者間の合意はブロック確認ではありません。一方、チャネルへの入金や必要になった閉鎖はビットコイントランザクションに基づきます。 [1]

フィールドとはメッセージ内の個々の値です。Millisatoshi は satoshi の千分の一で、Lightning 内の計算単位です。その端数をビットコインのチェーン上で独立に使用することはできません。 update_add_htlc の基本フィールドは channel_id、id、amount_msat、payment_hash、cltv_expiry、onion_routing_packet です。amount_msat の単位は millisatoshi です。ノードはチャネルの上限、利用可能な流動性、転送条件を検証し、送信側 HTLC には固有のパラメーターがあります。BOLT 2 に従い、受信側の追加が取り消し不能に確定するまで、対応する送信側 HTLC を提示してはなりません。 [1]

Onion routing は各仲介者への指示を別々の暗号化層に包みます。エヴァが受け取るのは自分の段階に必要な情報で、全参加者の読める一覧ではありません。 ノードは自身の onion 層を復号し、完全性を検証します。通常の非ブラインド経路では amt_to_forward と outgoing_cltv_value を受信金額、手数料、必要な期限差と照合します。パケットは経路全体を開示しません。ただし通信の相関分析や他の方法による身元の推定は排除されず、onion routing は完全な匿名性を保証しません。 [3]

出力は使用条件を持つ金額で、その条件を Script という言語で記述します。Offered と received はチャネル参加者から見た提示側と受信側を表します。第2段階は後続トランザクションで、CHECKSEQUENCEVERIFY(CSV)は、使用する出力の確認を起点とする待機を要求します。失効鍵は、公開された古い失効済み状態に対するペナルティに使われます。 BOLT 3 は offered と received の出力、および HTLC-success と HTLC-timeout の経路を区別します。単にハッシュを知っているだけでは不十分で、対応する署名、preimage、時間条件が適用されます。ローカルの第2段階出力には to_self_delay の CSV 遅延があり、正しい失効鍵を持つ相手方はその遅延なしでペナルティ分岐を使用できます。正確な Script はチャネルの種類に依存します。 [2] [6]

Trimming とは、チャネル状態をオンチェーンに移す際、小額の HTLC が独立した出力にならないことです。Dust はそのような小額を指し、dust exposure はこの制約を受ける金額の合計を表します。 該当する第2段階手数料を差し引いた金額が dust_limit_satoshis 未満なら、コミットメントトランザクションは HTLC 出力を作成しません。ルールは合意した種類によって異なります。option_anchors と zero_fee_commitments にはその第2段階手数料がなく、zero_fee_commitments は除外した金額を shared_anchor に割り当てる場合があります。存在しない出力を独立にオンチェーン請求することはできません。こうした HTLC の合計が dust exposure です。 [2] [1]

次の確認はノード運営者や開発者向けです。デコードは記録を読めるフィールドに変換するだけで、何も送信せず、全条件を満たした証明にもなりません。 受信側と送信側の amount_msat、payment_hash、cltv_expiry を比較し、SHA-256 で preimage を検証します。単一の fulfill/fail メッセージだけでなく、commitment_signed、revoke_and_ack、最終状態も追跡します。オンチェーンで強制する際は実際のコミットメントトランザクションをデコードし、出力の存在、使用する分岐、HTLC-success/HTLC-timeout を確認します。署名と時間条件を調べ、ブロックでの確認状況も確かめてください。デコードだけでは有効性を証明できません。 [1] [2]

理解を深めるには、この項目とあわせて次もお読みください Lightning Network, Payment Channel, Timelock, Hash, CLTV, CSV. 次の項目からも参照されています Timelock, Payment Channel, Lightningの流動性, Lightning Routing.

DOC · 001BOLT 2 — Channel state and HTLC handling仕様 DOC · 002BOLT 3 — HTLC transaction scripts and trimming仕様 DOC · 003BOLT 4 — Onion routing and payload validation仕様 DOC · 004BOLT 11 — Payment hash and invoice expiry仕様 DOC · 005BIP 65 — CHECKLOCKTIMEVERIFY仕様 DOC · 006BIP 112 — CHECKSEQUENCEVERIFY仕様
改訂日: 一次資料を優先 · 投資助言ではありません