ステート・決済チャネル

なぜオフチェーンで決済するのか

パブリックチェーンでは、すべての取引を全ノードが検証・記録します。この冗長性が改竄耐性を生む一方、1件ごとに手数料とブロック確定待ちが発生し、コーヒー1杯のような少額・高頻度決済には割に合いません。/blockchain/finality-fork-choice/ で見たように、確率的ファイナリティのチェーンでは「もう覆らない」と言うために複数ブロックの確認を待つ必要もあります。

決済チャネルは、この構造を根本から変えます。二者間の取引を毎回オンチェーンに載せる代わりに、チャネルの開設と閉鎖の二回だけをL1に記録し、その間の残高更新は当事者どうしが署名済みの状態をオフチェーンで直接交換して済ませます。100回送金しても、オンチェーンに残るのは2件。手数料もブロック確定待ちも、この2件分に圧縮されます。

ステートチャネルはこれを一般化した概念で、やり取りする「状態」を残高に限らず、ゲームの盤面や汎用的なコントラクトの状態にまで広げたものです。決済チャネルはその最も普及した特殊形と捉えられます。

署名済み状態の交換

チャネルの中核は、両者が署名した最新の残高分配（state） です。開設時にたとえばAが0.6・Bが0.4をロックしたとします。AがBへ0.1送るたびに、新しい分配（A=0.5, B=0.5 …）を作り、双方が署名して相手に渡す。この署名済み状態そのものが「いまの正しい残高はこれだ」という証拠になります。

開設: A=0.6, B=0.4 をマルチシグにロック（version 0）
  A→B 0.1: 新状態 A=0.5, B=0.5 (version 1) を両者署名して交換
  A→B 0.1: 新状態 A=0.4, B=0.6 (version 2) を両者署名して交換
  B→A 0.2: 新状態 A=0.6, B=0.4 (version 3) を両者署名して交換
        …何百回でもオフチェーンで反復。L1は一切関与しない…
閉鎖: 最新の署名済み状態(最大 version)をL1へ提出して残高を精算

決定的に重要なのは、各状態に単調増加するバージョン番号（またはシーケンス番号） が付く点です。これにより「どれが最新か」が一意に定まり、古い状態を持ち出して不正に精算しようとしても、より大きなバージョンの署名済み状態で上書き・反証できます。署名は、当事者だけが作れ誰もが検証できる——この非対称性が土台であり、/blockchain/signatures-wallets-keys/ で扱った ECDSA の性質がそのまま効いています。

紛争解決とオンチェーン決済

理想は、両者が最新状態に合意して署名し、協調的クローズで速やかに精算することです。問題は一方が非協力的、あるいは悪意を持つ場合です。ここでL1コントラクトが紛争解決の裁定者として機能します。

一方が「この状態で閉じたい」と署名済み状態をL1へ提出すると、コントラクトはチャレンジ期間を開始します。この間、相手はより大きいバージョンの署名済み状態を提出できます。仕組みは次の通りです。

1. A が version 2 (A=0.4) を提出してチャネル閉鎖を申し立て
2. コントラクトがチャレンジ期間を開始（例: 数百ブロック）
3a. B が保管していた version 3 (A=0.6, B=0.4) を提出
      → コントラクトは version 3 > version 2 を確認し状態を更新
      → 古い状態を出した A に対しペナルティを科す設計もある
3b. 誰も反証しなければ、期間満了で version 2 の分配が確定し精算

つまりL1は毎回の送金を見る必要はなく、争いが起きたときだけ「提示された署名済み状態のうち最大バージョンのものを正典とする」という単純な裁定を下します。これは/blockchain/layer2-rollups/ の不正証明と同じ「性善説で進め、異議があればオンチェーンで決着」という発想で、決済チャネルはその二者版と言えます。

この紛争解決コントラクトは、/blockchain/smart-contracts-evm/ で述べた決定的な状態遷移の上に成り立ちます。全ノードが同じ規則で「最大バージョンが勝つ」を判定するからこそ、裁定に誰もが同意できるのです。

ライトニングネットワーク — チャネルを連結する

二者間チャネルだけでは、送金のたびに相手ごとの開設が要り不便です。ライトニングネットワークは、既存のチャネルを経路として数珠つなぎにし、直接チャネルの無い相手へも送金します。A→B→C とチャネルが繋がっていれば、AはBを中継してCへ送れます。

問題は「Bが中継の途中で持ち逃げしないか」です。これを解くのが HTLC（Hashed Timelock Contract） です。受取人Cが秘密 R を持ち、そのハッシュ H=hash(R) を用いて条件付き支払いを連鎖させます。

前提: C が秘密 R を持ち、H = hash(R) を共有
1. A→B: 「R (Hに対応) を期限 T2 までに見せれば 0.1 払う」
2. B→C: 「R (Hに対応) を期限 T1 までに見せれば 0.1 払う」（T1 < T2）
3. C は R を提示して B から受領（Cだけが R を知る）
4. B は今や R を知ったので、A から同じ条件で受領
   → R を知らなければ誰も次段の資金を引き出せず、期限で払い戻し

要点は二つあります。第一に、同じハッシュ条件を全経路で使うため、Cが受け取った瞬間に秘密 R が上流へ伝播し、中継者Bも確実に回収できます。誰かが持ち逃げしても、R を知らなければ資金は動かず、タイムロックで元へ戻ります。第二に、期限は下流ほど短く設定します。これにより、下流が確定したのに上流の払い戻し期限が先に切れて中継者が損をする事態を防ぎます。ハッシュとタイムロックという素朴な部品だけで、信頼できない中継者を挟んだ多段送金を安全に成立させているわけです。

チャネルの資金効率

決済チャネルの制約は、突き詰めると資金がチャネルにロックされる点にあります。開設時に預けた額が容量（capacity）の上限であり、その範囲でしか送金できません。ここに実用上のいくつかの限界が生じます。

具体的な効率の壁が流動性の偏りです。A→B のチャネルでAばかりが送ると、Aの残高が枯れBの残高に寄り、以降Aは送れなくなります（受け取りは可能）。経路上のどこか一区間でも残高が不足すれば、その経路全体が使えません。つまりネットワーク全体の見かけの容量が大きくても、方向ごとの残高分布次第で実際に通せる送金は限られます。

もう一つの効率観点がオンチェーン設置コストの償却です。開設・閉鎖のオンチェーン手数料は固定費なので、そのチャネルで多数の送金を捌くほど1件あたりに薄まります。裏を返せば、数回しか使わない相手のために専用チャネルを開くのは割に合わず、長期・高頻度の相手や、多くの経路が通るハブ的ノードでこそチャネルの利得が最大化します。ここに、少数の資金力あるノードへ中継が集中しやすいという中央集権化の懸念も伴います。

まとめ

• 決済チャネルはオンチェーン取引を開設・閉鎖の二回に圧縮し、その間の残高更新は両者が署名した状態をオフチェーンで交換するだけで完結する。手数料も確定待ちもこの二回分に収まる。
• 安全性は単調増加するバージョン番号とL1コントラクトの紛争解決で担保する。一方的閉鎖にはチャレンジ期間中により新しい署名済み状態で反証でき、古い状態での閉鎖は取消鍵で罰せられる。
• ライトニングネットワークは HTLC で複数チャネルを連結し、直接チャネルの無い相手へも送金する。同一ハッシュ条件と下流ほど短いタイムロックが、信頼できない中継者を挟んでも安全性を保つ。
• 本質的制約は資金がチャネルにロックされることと流動性の偏り。方向別の残高分布が実効容量を左右し、開設・閉鎖の固定費は送金回数で償却されるため、長期・高頻度の相手でこそ効果が大きい。