Payment Channel

共同でロックした資金に対する二者の取り分を、その都度更新すると考えてください。支払いごとに独立した Bitcoin トランザクションをブロックに載せる必要はありません。代わりに、新しい状態の署名を交換します。単に信用して使う表ではなく、合意した条件で決済を実行できるトランザクションを、それぞれが持っています。 [1] [2]

資金供給トランザクションは、ビットコインをチャネルに入れる取引です。その出力は、誰が使えるかというルール付きの金額です。取引がブロックに含まれることを確認と呼びます。一般的な Lightning チャネルでは、この出力に双方の署名、つまり 2-of-2 が必要です。資金供給トランザクションを公開する前に、参加者は一方的に閉じられる有効な手段を確保しなければなりません。通常は資金供給の確認を待ちます。一定の条件では、zero-conf により確認を待たずにチャネルを使えます。ただし受け手は資金提供者をより強く信頼する必要があります。資金供給トランザクションはまだ未確認で、同じ資金を使う別のトランザクションに置き換えられる可能性があるためです。 [2] [3]

Commitment トランザクションは、現在合意している配分で決済するため、あらかじめ署名した取引です。ここでのノードは、チャネルとその更新を管理するプログラムを指します。 双方はそれぞれ別の commitment トランザクションを持ちます。更新時、ノードは commitment_signed と revoke_and_ack を通じて署名と失効用の秘密情報を順序立てて交換します。新しい合意ができても、古い署名済みトランザクションが Bitcoin のコンセンサス上で無効になるわけではありません。失効した状態の公開への対策は、出力の支出条件に組み込む必要があります。 [2] [3]

一般的な失効型チャネルでは、自分の commitment を公開した側は、自分の資金を使うまで to_self_delay を待ちます。待機期間は commitment トランザクションの確認を起点に、ブロック数で数えます。失効した状態を公開した場合、相手は失効用の鍵で該当する出力を支出し、対処できます。ただし期限内に行動し、そのトランザクションが確認される必要があります。Watchtower はチェーンを監視し、事前に用意した情報を使って失効済み状態の公開に対処できるサービスです。ただし、このサービスも成功を保証するものではなく、バックアップの代わりにもなりません。 [3] [4]

Sat は satoshi の略で、ビットコインのチェーン上で扱う最小単位です。容量はチャネル全体の金額であり、それぞれの参加者の残高ではありません。 容量が 100000 sat で、Alice の取り分が 70000 sat、Bob が 30000 sat のチャネルを考えます。Alice が Bob に 10000 sat を払うと、配分は 60000 sat と 40000 sat になります。説明を簡単にするため、手数料と準備金は省いています。容量は同じでも、Alice が送れる額は減り、受け取れる額は増えます。実際の上限には準備金や処理中の支払いも影響します。 [6]

Lightning は複数のつながったチャネルを通る経路を探します。HTLC は条件付きの支払いです。資金を受け取るには preimage という秘密の値を明かす必要があり、そのハッシュ（デジタルな指紋）が事前に知られた値と一致しなければなりません。支払いが完了しない場合にも、時間条件に従って決済する経路があります。中継者には流動性、つまり必要な方向へ送れる資金が必要で、手数料を取ることもできます。すべての店と直接チャネルを開く必要はありませんが、つながっているだけで、どんな額でも送れる経路が保証されるわけではありません。 [2] [4]

双方の合意による閉鎖、cooperative close では、参加者が閉鎖トランザクション、資金配分、手数料を合意します。双方が署名し、ブロックチェーンに公開します。通常は一方的な決済より簡単ですが、自動的に無料や即時になるわけではありません。このトランザクションにも確認と、ネットワークの状況に合った手数料が必要です。 [2] [4]

一方的な閉鎖、force close では、相手の新たな同意なしに、自分の最新の commitment を公開できます。ただし資金をすぐ使えるとは限らず、待機条件や HTLC の決済が残る場合があります。追加のトランザクションや手数料も必要になり得ます。緊急の出口はありますが、所要時間と費用はチャネル状態やブロックチェーンの状況によって変わります。 [3] [4]

Seed Phrase は、ウォレットの鍵を復元するためのバックアップ用の単語列です。ただし、それだけでは開いているチャネルの最新状態を復元できないため、利用するウォレットの手順に従ってください。例えば、Lightning ノードを動かすプログラム LND は、この単語列と Static Channel Backup (SCB) を組み合わせます。この静的バックアップは、相手へ連絡してチャネルの閉鎖を求めるための情報を保存します。チャネルを元に戻して支払いを続けるためのものではありません。この方法での復旧は、相手が応答するかどうかにも左右されます。一方、channel.db はチャネルのデータベースファイルで、古いコピーには危険なほど古い状態が含まれる場合があります。チャネルを「修復」するために、実際のバックアップ用の単語列を他者のサイトへ入力しないでください。 [5]

誰が鍵を持ち、誰がチャネルを監視し、端末を失ったらどうアクセスを回復するのかを確認しましょう。カストディ型とは、サービス提供者が鍵を保管する方式です。カストディ型サービスに表示された Lightning 残高は、自分のチャネルとは限りません。自己管理ならバックアップ、可用性、障害への対応も自分の責任です。チャネルはチェーンへの記録を減らしますが、運用の責任や決済費用をすべてなくすわけではありません。 [4] [5]