素のライトニングネットワークで実現が難しい機能の１つに「非同期支払い」があります。非同期支払いとは、支払いを受けるユーザーがオフライン状態のときに別のユーザーからの支払いを保留状態で受け付けて、オンラインに復帰した際に着金させるという支払いフローのことをいいます。

非同期支払いが簡単に実現できない理由はライトニングの仕組みにあります。LN上の支払いはライトニングチャネルというオフチェーンの台帳を１つ以上経由して最終的な宛先までバケツリレーされますが、途中のチャネルの利用可能な残高が足りない場合や途中のノードがオフラインの場合があります。このため送金者は宛先のノードまで利用可能な支払経路を見つけるために、様々な経路を試していきますが、もし受取主がオフラインであれば宛先までの経路が確定できず、送金ができません。

今日はLNで非同期支払いをする方法として考案されているものをいくつか紹介します。

Lightning Rod

Lightning RodはノンカストディアルLNウォレットのBreezが考案した手法で、送金者(以下Alice)から宛先(以下Carol)への支払いを、AliceからRod、RodからCarolという同じプリイメージで決済される２つの別々の支払いに分割することで非同期支払いを実現するアプローチです。

具体的にはAliceから送金を開始します。AliceはCarolに秘密情報Sを送り付けます。Carolはオンラインになった際に秘密情報Sを受け取り、これとは別にプリイメージPを生成します。CarolはRodに対してPをプリイメージとするインボイスをメッセージ欄にH(S)を添えて発行します。

この時点での知識は以下の通りです：

Alice：秘密情報S
Rod：秘密情報Sのハッシュ値H(S)、プリイメージのハッシュ値H(P)
Carol：秘密情報S、プリイメージP

RodはAliceに対してプリイメージPに対してのインボイスを発行します。インボイスのメッセージ欄に含まれるH(S)を確認したAliceはこのインボイスはCarolの指示で生成されたとわかるため、このインボイスに対して送金します。RodはプリイメージP自体はまだ知らないため、この送金は保留状態となります。(このように意図的に即座に決済しないことを「HODLインボイス」といいます)

Rodはこの支払いを保留した後、Carolからもらっているインボイスに対して支払いを試みます。もしCarolがオフラインである場合はCarolがオンラインに復帰するまで試みます。最後に、成功時にもらえるプリイメージPを使ってAliceからRodへの支払いを決済することができます。

上記の例ではAliceとCarolが同じRodを利用していますが、理論上は別々のRodを利用することで後述するTrampolineと同じようなことが実現できます。(真ん中にRod1→Rod2の送金が増えることになります。)

この方式の欠点として、同一のRodを使っている場合は送金者・宛先・金額がRodに知られてしまうこと、秘密情報Sを別経路で伝える必要があることなどが挙げられます。

詳細はBreezのブログ記事(2019)からどうぞ。

Trampoline

トランポリンペイメントという規格はEclairというライトニング実装が昔から盛んに提唱している、支払いのプライバシーを改善したり送金者の経路選択に関する負担を軽減するプロトコルです。

送金を受け取るユーザーは「トランポリンノード」と呼ばれる中間ノードを指定し、送金者はそのトランポリンノードまでの経路だけを計算します。トランポリンノードまで到達した後、最終目的地までの経路は改めてトランポリンノードが選択する、という支払い方式です。トランポリンノードを１つだけ使用する一番シンプルな構成ではトランポリンノードは経路選択のために最終的な宛先を知ることになります。

Lightning Rodと同様に、トランポリンノードを複数経由させるとトランポリンノードも送金先が最終目的地なのか別のトランポリンノードなのか判断が難しくなり、プライバシーが改善します。

人気のトランポリンノードが使われる場合などは簡単に判別できてしまいそうではあります。

やはりLightning Rodと同様にトランポリンノードが宛先ノードのオンライン復帰を待つことで同様の手法で非同期支払いが実現することはご想像いただけるでしょう。LNDやCLN、LDKにはTrampoline Paymentsは実装されていませんが、EclairとPhoenixでは利用可能な模様です。

Keysend＋LSP

Lightning RodとTrampolineはどちらも自由意志で第三者サービスを利用して非同期支払いを実現するプロトコルでした。その代わり、専用のプロトコルを実装しているウォレットがなければ利用のハードルが高いという欠点があります。そこでほぼすべてのライトニングウォレットが対応している支払い方法で非同期支払いを実現する別の手法があります。KeysendとLSPの併用です。

モバイル型のLNウォレットの多くはLSP型と呼ばれます。LSPとはライトニングサービスプロバイダーの略で、多くの場合はウォレット運営業者です。ノンカストディアルなLNウォレットでも特定のLSPとしかチャネルが開けない(ユーザーが勝手にチャネルを開くことができない)ものは多いです。逆にこれを利用してLSP側はユーザーへの送金を保留できることを利用したのが私がKeysend＋LSPと便宜上呼んでいる手法です。

要するにLSPは各ユーザーにチャネルを１つずつ割り振っており、ユーザーは勝手にチャネルを開設できないためそのチャネルへと抜けていく送金はそのエンドユーザー宛の送金と断定することができます。したがって、そのエンドユーザーへと送金を中継できるだけの流動性さえそのチャネルにあれば、あとはユーザーがオンライン状態に復帰するまで送金の中継を保留すれば良いわけです。

しかしこれには別の問題があります。Keysendという手法はインボイスとともにそのインボイスに対するプリイメージを送金者が生成して送りつけるものなので、Keysendに関してはプリイメージが支払いの証明とならないのです。これでは返金対応などの揉め事が厄介になってしまいます。

PTLCを用いた非同期支払いと支払証明

上記の手法はどれも数年前には登場していましたが、今年２月にAnthony Towns氏がライトニング開発者のメーリングリストに提案したPTLCを用いた手法は

もちろんライトニングネットワークへのPTLCの導入が必要になるため、利用可能になるのはまだ先の話ではあります。PTLCについては過去記事をご覧ください。

Lightning RodやTrampolineと基本的なアイデアは同一で、送金者Aliceと宛先Bobの中間に入ってくれるLSPノードLarryが登場します。Bobは事前にLarryに多数のナンス値を提供することでAliceとLarryはBobがオフラインでもBob宛の送金を行うPTLCを生成することができます。Bobがオンラインに復帰するとこのPTLCは通常通り決済され、このときAliceが指定したメッセージに対してBobの署名が付与されたものが手に入るのでそれが支払証明になるということです。

言い換えると、(LSPがナンスのリストを預かっていることで)Keysendのように一方的にAliceから送りつけられるが、(秘密情報の伝達やインボイスの発行が必要なため一方的に送りつけられない)Lightning RodやTrampolineのように支払証明が得られるというソリューションです。

ただしこの提案にもまだイケてない部分があります。支払いを受け取るBobが事前に多数のナンスを公開するかLSPに預ける必要がある点です。それでも、モバイルウォレットにありがちな特定のLSP縛りがないこと、事前に直接送金者に秘密情報を共有したりする必要がないことなど、今日紹介した既存の手法と比較していくつかのメリットがあります。

ただし前述の通りPTLCの導入が必要であったり、PTLCを生成する際のメッセージのテンプレートなど定めるべきプロトコルが多少存在するので果たしてこの手法が実際に利用される日が来るのかは不明です。PTLCが前提ならもっと良い方法が出てくるといいなと思います。

まとめ

・ライトニングネットワークで困難な非同期支払いを実現するアプローチはいくつか存在するが、一番シンプルに利用できるLSP型ウォレット宛の非同期支払い(LSP側での保留)ではKeysendを利用することになるため支払証明が得られない。

・Lightning Rod、Trampolineといった中間ノードを挟むアプローチは現状で利用できるものが存在し支払証明も得られるが、ほとんど採用されていないため使い物にならない。

・２月にLN開発者メーリスで提案されたPTLCベースの手法も同様に中間ノードを挟むが、支払証明が得られるほかKeysendのように一方的に送りつけることができる。

個人的にはトランポリンペイメントが普及すると送金者だけでなく(現在のライトニングでは比較的弱い)宛先ノードのプライバシーが改善するので、トランポリンペイメントを推したいです。