複数のPayment Channelのアトミックな更新を可能にする「Atomic Multi-Channel Update」

Scaling Bitcoin 2019予習シリーズ第三弾は、「Atomic Multi-Channel Updates with Constant Collateral in Bitcoin-Compatible Payment-Channel Networks」。ホワイトペーパーは↓

https://eprint.iacr.org/2019/583.pdf

著者の１人のPedro Moreno-Sanchezは、Scaling Bitcoin 2018でもMulti-Hop Locksの発表しており、Payment Channel Networkの興味深い新しい提案をよく発表している人物。

Payment Channel Networkの課題

Lightning Networkでも採用されている現在のPayment Channel Networkでは、支払いがアトミックに行われることを担保するため、2フェーズコミット型のプロトコルが採用されている。ここでいう2フェーズコミット型のプロトコルというのは、

最初に送信者から受信者への支払い経路の各チャネルで支払いの金額がロックされ
次に受信者から送信者への経路の順にシークレットの値を明らかにし支払いを受け入れる

プロセスが処理されるプロトコルで、必ず経路順に処理が進む。

このPayment Channel Networkには以下の２つの課題がある。

経路制限

現在のPayment Channel Networkでは送信者から受信者までPayment Channelが繋がっている送金経路を確保し、さらにその経路の方向に各チャネルが送金額分送金できるだけの十分なキャパシティがないと送金はできない。

担保

Payment Channel Networkを利用した支払いを行う場合、経路内のチャネルの数をn個、支払うコインの量をαとすると、支払いを実行する際少なくともn × αのコインをロックすることになる。支払いが完了するまで、コインはロックされ、ロックされているコインは他の支払いに使うことはできない。そのため、コインがロックされている時間というのは重要だ。

支払いは通常数秒で終わるのでロック期間も数秒であまり意識することはないが、支払いの際に応答不能になるなどオンチェーン上での紛争解決が必要になった場合、n × αのコインがn × △時間（△はオンチェーン上でのトランザクションの承認時間）ロックされることになる。この支払いの経路に沿ってロックされるコインを担保と表現する。

攻撃者にとってはコインを盗めるようなメリットは無いが、単なる嫌がらせとしてチャネル上のコインをロックする攻撃は実際に考えられる。攻撃者が送信者、受信者となり十分に長い経路の支払いを行い、受信者が2フェーズコミットの②を可能な限り遅らせることで、攻撃者自体はαコインロックするだけで、経路上のコインn × αのコインをスタックさせることができる。チャネル全体で見た場合、担保は支払いの経路が長いほど大きくなる。

Atomic Multi-Channel Update（AMCU）の提案

Atomic Multi-Channel Update（AMCU）では、経路の関係性がない複数のPayment Channelの状態をアトミックに更新することで、上記の経路制限を緩和し、支払いに伴う担保を経路の長さに関係なく一定となるよう削減する。

Atomic Multi-Channel Update プロトコル

既存のPayment Channel Networkのアトミック性

Payment Channel Networkを利用したマルチホップ決済の重要な特性はアトミック性で、経路内の全てのペイメントチャネルの残高が更新されるか（支払いが行われるか）、されないか（支払いが行われないか）だ。

Lightning Networkなどで採用されている現在のPayment Channel NetworkはHTLCを使って、このアトミック性を担保している。ペイメントチャネルを持つ２人のユーザー（アリスとボブ）は、

アリスはy=H(R)となるRが提供されるとxコインボブに支払う（Hはハッシュ関数、つまりyのプリイメージが分かればコインを支払う）。
タイムアウト時刻tを経過すると、アリスはロックしたxコインを取り戻す。

という内容のコントラクトにコインをロックする。

Payment Channel Networkの支払い経路内の各チャネルのユーザーは、同じyを使ってそれぞれのチャネルでコントラクトを形成し（2フェーズコミットのフェーズ１）、受信者がRを公開してコインを受け取りチャネルを更新する（2フェーズコミットのフェーズ2）。もし、タイムアウト時刻になってもRが公開されない場合は、チャネルを元の残高に更新する（この時相手が応答しない場合はトランザクションをブロードキャストしチェーン上で紛争解決する）。

AMCU プロトコル

AMCUプロトコルは、プロトコルの参加者が以下の4つのフェーズを実行する。これらのフェーズは全てオフチェーンで実行される。

また、AMCUではプロトコルの参加者は他の参加者を認識し、認証された機密メッセージを送信してプロトコルを進める（参加者間でTLSチャネルを確立して使用する）。さらに参加者の内、プロトコルフェーズの調整を支援するコーディネーターを参加者間で１人決める。決め方のルールは強制されないが、参加者のアドレスのリストを辞書順にソートして最初のユーザーをコーディネーターとするなどで簡単に決められる。このコーディネータはネットワーク内のメッセージ数を減らす役割を果たす（その他のセキュリティやプライバシー上の利点などは無い）。

各フェーズにおいて全参加者がコーディネーターにOKの返信をすると次のフェーズに進む。

具体的にAMCUのプロトコルにおける支払いの４フェーズ（セットアップ、ロック、消費、ファイナライズ）について説明する。AMCUでは支払いのアトミック性をHTLCとは別の方法で担保しており、そのコアとなる機能は３つ目の消費フェーズにある。

セットアップ

プロトコルに参加する参加者の各チャネルで利用可能なコインをロックする。ここでチャネル内の残高が必要以上にロックされると、担保が不必要に増大することにもなるので、ペイメントチャネルの残高を2つに分割し、2つのサブチャネルを作る。

１つは、AMCUのプロトコルセッションで必要な量のコイン
もう１つは、残りのコインで自由に使用可能

A→B→C→D→Eの経路でAからEに5コイン送金する例で考える（AMCUの場合、経路は関係ないが経路にした場合も、担保が経路の長さによって大きくなることはなく一定になるので、担保を小さく保つという意味ではメリットがある）。この時、それぞれの中間者への手数料を１コインとする。つまりB, C, Dに手数料１コインずつ払うのでAが支払うコインは合計８コイン。

チャネルを開いているAとBは、AMCUセッションで使用するコインと残りのコインにアウトプットを分割する ${Tx^{A}_{setup}}$ トランザクションを作成し、お互いに署名する。これを他のチャネルのユーザーも並行して進める。すると以下のような状態になる。

※ ユーザー間の数字はチャネルの総キャパシティで、初期状態は左側のユーザーが全残高を持っている状態とする。

セットアップフェーズが終わるとAMCUの送金に必要な額のアウトプットがそれぞれ分離できた状態（サブチャネルができた状態）になる。

ロック

AとBはセットアップフェーズで作成した ${Tx^{A}_{setup}}$ のAMCU用のアウトプットをインプットとし、それをそのまま両者宛（AとBのマルチシグ）に送金するトランザクション ${Tx^{A}_{lock}}$ を作成し、署名する。このトランザクションにはタイムロック ${T_{△}}$ が設定されており、 ${T_{△}}$ 経過するまで、ブロックチェーンには追加できない。

これを他のユーザーも並行して進めると、ロックフェーズが終了すると以下のトランザクションをそれぞれ持つようになる。

このロックフェーズが実行されることで、参加者の誰かが将来のフェーズの進行を邪魔しても、 ${T_{△}}$ 経過したら、各チャネルはフォールバック可能になる。

消費フェーズ

消費フェーズで実際にコインを送金するが、この時重要になるのがアトミック性で、AMCUの参加者全てがそれぞれの受信者にコインを送金する状態か、全員が送金しない状態かのいずれかになることが担保される必要がある。

AとBはAからBにコインを送金するための ${Tx^{A}_{consume}}$ トランザクションを協力して作成する。このトランザクションのインプットは以下の２つ。

${Tx_{enable}}$ トランザクションのアウトプットの１つでAとBのマルチシグにロックされた7.99コイン
${Tx_{enable}}$ トランザクションのアウトプットの１つでAとBのフレッシュアドレスにロックされた0.01コイン

アウトプットはB宛に8コイン送る単一のアウトプット。このトランザクションの作成を他のユーザーも並行して進めると、消費フェーズが完了すると、それぞれ以下のトランザクションを持つようになる。

ここで、 ${Tx_{enable}}$ はまだ作られていないトランザクションだ。そのため、このトランザクションをこの時点でブロードキャストしてもブロックチェーンに格納されることはない。この ${Tx_{consume}}$ と ${Tx_{enable}}$ にアトミック性を担保する仕組みがある。

ファイナライズ

消費フェーズで全チャネルの消費トランザクションが作られたら、最後に ${Tx_{enable}}$ と ${Tx_{disable}}$ を作成する。

まず ${Tx_{enable}}$ トランザクションは、各チャネル毎に作られた ${Tx_{setup}}$ のアウトプットをすべて集めてインプットとし、 ${Tx_{consume}}$ のインプットとなる各チャネルごとに2つずつのアウトプットを持つ１つのトランザクションで、以下のようなトランザクションになる。

つまり、各ユーザーが消費フェーズで作成した送金トランザクションは、この１つの ${Tx_{enable}}$ がチェーン上にあらわれて初めて有効になる。この方法により、直接的な関連のない複数のPayment Channelの更新のアトミック性を担保する。

ただ、このままだと ${T_{△}}$ 経過したら ${Tx_{setup}}$ を参照する２つの有効かつ矛盾する内容の ${Tx_{lock}}$ と ${Tx_{enable}}$ が有効になってしまう。このため、 ${T_{△}}$ 経過したら ${Tx_{enable}}$ を無効化する ${Tx_{disable}}$ を実際は ${Tx_{enable}}$ より先に作成しタイムアウト ${T_{△}}$ を設定して署名しておく。

残高の更新

上記ファイナライズフェーズまで終えると、各ユーザーはやろうと思えばオンチェーン上で ${Tx_{setup}}$ -> ${Tx_{enable}}$ -> ${Tx_{consume}}$ を公開することで、送金の紛争解決ができる。

通常はオフチェーン決済を続けると思われるので、チャネルの残高を更新したコミットメントTxを作成し、合意すればAMCUプロトコルは終了する。

所感

経路とHTLCを使わずどうやってアトミックに複数のチャネルを更新するのかと思ったけど、なるほど確かにこういう構成を取ればアトミックにできそうで面白い。これは単純に既存のLNの担保を小さくするだけでなく、チャネルの残高の調整や、ペーパーにも書いてあるとおりクラウドファウンディング（募集額集まったら支払いし、集まらななかったら集金しない）のようなケースにも対応できそうで興味深い。

個人的には以下の点が疑問。

消費フェーズでアウトプット2つ分けてフレッシュアドレスを必要とする理由がイマイチ分かっていない。これ１つじゃダメなのか？
各 ${Tx_{consume}}$ には両者が署名するには、その後のフェーズで作られる ${Tx_{enable}}$ のトランザクション識別子とインデックス情報が必要になるが、この計算方法はどうする？もしくは、まだBitcoinでは導入されてないけど、bip-anyprevoutとかが導入されるとOutPointは空のまま署名できるから、そういう意図なのか？その場合別のOutPoinに切り替えられないよう、アウトプットを2つに分割し、フレッシュアドレスを導入してる？

それにしても、Payment Channelまだまだ奥が深いなー。