LDKのPhantom Node Payments機能はLN支払いをロードバランシングする大口向けソリューション

加藤規新 • 2023年02月10日

一般的なライトニングユーザーはモバイルアプリのライトニングウォレットを利用していたり、自宅にあるラズパイでノードを運用していることはあっても、複数のノードを運用している場合は稀でしょう。そのような一握りのパワーユーザーは決済事業者や取引所、大手ルーティングノードにとどまります。

多額のビットコインを複数のノードに分散させて運用するに際して、ノード間の送受金のロードバランシングという新たな要求が生まれてきます。今日はその方法の１つとしてSpiral社のLDK (Lightning Dev Kit)が提供するPhantom Node Payments機能を紹介します。

LDKベースで仮想のノードを利用する他のソリューションとして、過去にMutiny Walletを取り上げました。お時間のある方はそちらもどうぞ。

複数ノードのマネジメントの難しさ

ライトニング上でサービスを提供している事業者(LSP)などが、それぞれ支払いや受け取りが発生する複数のライトニングノードを管理するのはかなり複雑なタスクです。なぜならソフトウェアのスケーリングの話とは別に、ライトニング上のチャネルバランスの管理も検討する必要があるためです。

例えばカストディアルウォレットはユーザーの代わりに支払いを受け取る際、どのノードで受け取るかを決めてインボイスを発行する必要があります。ところが、インボイス発行後に大きな支払いが連続した場合など、最悪のケースではインボイスを発行したノードで支払いを受けることができなくなってしまう可能性があります。各ノードのチャネルバランスをうまく管理しないとユーザーエクスペリエンスが大きく毀損されてしまう例です。

この問題をさらに厄介にしている特徴に、インボイスは発行されたからといって必ずしも使用されないというものがあります。発行したインボイスの累計額を利用して受け取りに使用するノードを振り分けても、大きなインボイスがいくつか支払われずに期限を迎えるだけで実際の受取額は大きく偏ってしまいます。

特定のノードに受け取りが集中してしまい、各ノードのバランスが偏ってしまった場合、これを考慮してインボイスの発行や支払いの出口となるノードを調整することになります。確かに、支払いがあればローカル側に偏ったチャネルのバランスを多少押し戻すことはできそうですが、リモート側に偏ったチャネルのリバランスはやはり上述の困難に直面します。費用をかけてリバランスすると結果的にユーザーに転嫁する必要がありますし、利用データをもとにインボイスの使用率を予測するなどしようにもソフトウェアの複雑性が大きく増してしまうでしょう。

このように、複数のライトニングノードからお金が出入りするカストディアルウォレットなどのLSPは、特に受け取りがどのノードを通して行われるかについて予測しがたく、バランスの安定を困難にし、ユーザーエクスペリエンスの低下を招きます。

Phantom Node Paymentsは個別のノードのバランス調整を不要にし、ユーザーエクスペリエンスの安定を実現するシンプルなソリューションとしてLDKに実装されました。

実際のノードへの資金を仮想のノードに集約する

Phantom Node Paymentsにおいて、LSPは相変わらず複数のノードを運用します。これはデバイスの分散による信頼性向上やソフトウェアのスケーリング面でのロードバランシングといった目的があるので、単一の巨大ノードにまとめることはできないという前提があるためです。

この各ノードと仮想の"Phantom Channel"でつながる「黒幕ノード」のような仮想のノードを考えます。Phantom Channelはプライベートチャネルのようなものですが、仮想なのでオンチェーンに入金トランザクションが存在しませが、ネットワークがそれを知る必要もありません。

これでユーザーがインボイスを発行する際、Phantom Node宛のRoute Hintsつきのインボイスを発行できます。Route Hintsとはプライベートチャネルを用いるノードに対して支払いを行う際に利用するインボイスの欄で、発行者が指定するいくつかのノードとそれらのノードなら理解できるチャネル情報(この場合はPhantom Channel)が記入されます。

各ノードのバランス関係なしに、上図では送金者に最後のホップをその中から選ばせることができます。すなわち、バランスを上手に管理しないと支払いが失敗してしまう状況から、送金者が適切なノードに送金してくれて支払いが基本的には失敗しない状況を作り出せました。

もちろん、３ノードがトータルでリモートバランス不足になっていたり、どのノードも十分なリモートバランスがない場合には失敗してしまうので、最低限の管理は必要になります。送金と受け取りの割合がよほど偏っていなければ問題はないかもしれませんが。

欠点はMPPへの対応が困難なこと

表面上はPhantom Nodeという１つのノード宛の送金ですが、実際には複数のノードのいずれかを使用する仕組みと、Multi-Part Payments (MPP)の相性は非常に悪いです。

MPPとは大きな送金をより小さい金額に分割して、同一のPreimageで決済できる多数のより小さい送金として複数の経路を利用して送金するテクニックです。これによって1BTCなどライトニングを利用するのには大きな金額でも、0.01BTCの送金100個などに分けることで様々な経路の流動性を利用できるようになります。

残念ながら、同一のPreimageをもって決済するという特徴から必ず全てのPartが手元に到達するのを待つ必要があり、決済時には実際には複数のノードにわたって決済処理を行わなければならず、ライトニングノードという不具合に厳しい環境でこれを安全に行うエンジニアリングがかなり難しいと考えられます。

LDKの開発者は大きな金額の受け取りにはPhantom Node Paymentsを使わずにMPPを行うなど、状況に応じて対応するほうが現実的と指摘しています。

まとめ

・Phantom Node Paymentsは「黒幕」となるPhantom Nodeを自身が運用する複数のノードの背後に置き、プライベートチャネルに似たPhantom Channelを経由させることでインボイスの発行ノードを統一し、インボイス発行後でも送金者が送金先のノードを選べるようにする

・複数のライトニングノードから入出金があるLSPにとって受け取りの金額・タイミングの予測困難性はUXの問題につながるものであったが、Phantom Node Paymentsでは同一のインボイスでどのノードの流動性も利用できることでこの問題を解決する

・LDKを使った仮想ノードを用いたソリューションはMutiny Walletなど他にもあり、ポテンシャルが高そう

加藤規新

1994年生まれ、シカゴ大学でGISやコンピューターサイエンスを学び学士号取得。2016年末よりビットコインに関するリサーチや実験的な開発をしており、今までにいくつかのブログやサロンで解説を担当。ビットコインについて一番好きなところはパーミッションレスに誰でも使うことができること。 2024年11月より日本ビットコイン産業株式会社取締役。