複数のLNチャネルを利用したアトミックな決済を可能にするAtomic Multi-Path Payments（AMP）

Lightning Networkでは予めチャネルを開いた際にロックした額がそのチャネルのキャパシティになり、各ユーザーはそのキャパシティの範囲内でオフチェーン決済をすることができる。

現在のネットワークの各チャネルのキャパシティはあまり大きくはなく、少し大きめの額を送金しようとすると送金可能な経路が見つからないというケースもある。またウォレット内の総額は足りているものの、個別のチャネルの残高が送金額に満たないといったケースも考えられる。

こういったケースにおいて、１つ１つのチャネルの額は送金額に満たないものの、送金額を満たすよう複数のチャネルを組み合わせて決済できるようにしようというのがAtomic Multi-Path Payments（AMP）のコンセプトで、Olaoluwa OsuntokunとConner Fromknechtにより紹介された。

https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html

AMPの要件

AMPにより、１つの支払いをネットワーク上の複数の経路に分割することができるようになるが、この実現のためには以下が重要になる。

• アトミック性
  実際の支払いは複数のチャネルを使って行われるが、支払いが成功するか失敗するかの結果は、使用する全チャネルで同じである必要がある（あるチャネルは送金できて、あるチャネルは送金できなかったということが無い）。
• ペイメントハッシュの再利用の禁止
  LNのマルチホップ決済ではHTLCが使われ、あるハッシュのプリイメージとコインの交換がアトミックに行われる仕組みになっているが、AMPで決済に使用する複数のチャネルで同じプリイメージ・ハッシュを使用してはならない。これは悪意ある中間者が決済に使用する複数のチャネルの経路内にいた場合、不正に資金を盗むことができないようにするためだ。

AMPの仕組み

このAMPの要件を満たすように、AMPを利用した決済は以下のような仕組みで実行される。

送信者のフロー

１．まず送信者が受信者に送金するための経路を選択する。AMPでは複数のチャネルを使って送金するため、ここで複数の経路が選択される。この１つ１つの経路への支払いを部分的な支払いと呼ぶ。２．続いて送信者はベースプリイメージ（BP）を生成する（AMPの場合プリイメージは送信者が生成する）。このベースプリイメージは、部分的な支払いの数(ｎ)分のシェア（s）をサンプリングし、その排他的論理和を計算することで算出できる。

BP = s1 ^ s2 ^ s3 ^ .... ^sn (^は排他的論理和)

これはs1〜snまで全て集めればBPを導出できること意味する秘密分散の一種だ。

３．部分的な支払いの数分（n）、生成したBPに数値（インデックス）をインクリメントしながら付与したハッシュを計算する（R）。この値を各経路での決済に使用するプリイメージとし、さらにそれをハッシュしたペイメントハッシュを計算する（H）。

４．送信者はすべての部分的な支払いの経路に対して、4で計算したペイメントハッシュを使って決済を開始する。この時、AMPの１決済を指す識別子（ID）と、部分的な支払いの数（n）、2で生成したシェアの１つsiで構成される３つの情報（ID, n, si）を、各経路の（Lightning決済に任意のデータをアタッチできる）extra onion blob（EOB）にセットして送信する。※ EOBはEnd-to-Endの暗号化されたデータを受信者に送ることができる。

受信者のフロー

１．受信者は、各部分的な支払いの経路毎に送られてきたEOBのデータをID毎にまとめ、データ内のn個分の支払いが届くまで待つ。２．n個分のデータが届いたら、EOB内の全siの排他的論理和を計算してBPを導出する。３．BPが導出できたら、各経路の支払いのコインを受け取るのに必要な個々のプリイメージを送信者の3のフローと同じ計算をすることを導出する。４．3で全ての経路のコインを入手可能なプリイメージが揃うので、そのプリイメージを使って全ての経路のコインを入手する。

参考までに、アリスがキャロルに2つのチャネル（2BTC, 1BTC）を使って3BTCを送金するフローは以下のようになる。

このようにAMPは、ベースプリイメージのシェアを各チャネルの決済情報と一緒に流し、それらが全て揃わないと受信者がプリイメージを再構築できないようにすることで、受信者まで全ての支払い経路が準備できた場合のみ決済ができるようになっており、これによりアトミック性を担保している。また、各チャネルで使用するペイメントハッシュはBPから導出しているものの、各ペイメントハッシュは全く別の値であるため、悪意ある中間者が資金を盗難するという欠点もなくなる。

さらに、このプロトコルは送信者と受信者のみがAMPを構成するための処理をするだけで、各経路にいる中間者にとっては、通常のLN決済となんら変わらないように見える。

LNがAMPを利用した決済をサポートすることで、個々のチャネルで大きな額を維持する負担が減り、インバウンド・アウトバウンドの流動性をより有効に活用できるようになることが見込まれる。AMP自体はまだ現在のBOLTには定義されていないが、今後作成されるBOLT 1.1への追加や実装が期待される。