一般的なライトニングユーザーはモバイルアプリのライトニングウォレットを利用していたり、自宅にあるラズパイでノードを運用していることはあっても、複数のノードを運用している場合は稀でしょう。そのような一握りのパワーユーザーは決済事業者や取引所、大手ルーティングノードにとどまります。
多額のビットコインを複数のノードに分散させて運用するに際して、ノード間の送受金のロードバランシングという新たな要求が生まれてきます。今日はその方法の１つとしてSpiral社のLDK (Lightning Dev Kit)が提供するPhantom Node Payments機能を紹介します。
LDKベースで仮想のノードを利用する他のソリューションとして、過去にMutiny Walletを取り上げました。お時間のある方はそちらもどうぞ。
加藤 規新
複数ノードのマネジメントの難しさ
ライトニング上でサービスを提供している事業者(LSP)などが、それぞれ支払いや受け取りが発生する複数のライトニングノードを管理するのはかなり複雑なタスクです。なぜならソフトウェアのスケーリングの話とは別に、ライトニング上のチャネルバランスの管理も検討する必要があるためです。
例えばカストディアルウォレットはユーザーの代わりに支払いを受け取る際、どのノードで受け取るかを決めてインボイスを発行する必要があります。ところが、インボイス発行後に大きな支払いが連続した場合など、最悪のケースではインボイスを発行したノードで支払いを受けることができなくなってしまう可能性があります。各ノードのチャネルバランスをうまく管理しないとユーザーエクスペリエンスが大きく毀損されてしまう例です。
この問題をさらに厄介にしている特徴に、インボイスは発行されたからといって必ずしも使用されないというものがあります。発行したインボイスの累計額を利用して受け取りに使用するノードを振り分けても、大きなインボイスがいくつか支払われずに期限を迎えるだけで実際の受取額は大きく偏ってしまいます。
特定のノードに受け取りが集中してしまい、各ノードのバランスが偏ってしまった場合、これを考慮してインボイスの発行や支払いの出口となるノードを調整することになります。確かに、支払いがあればローカル側に偏ったチャネルのバランスを多少押し戻すことはできそうですが、リモート側に偏ったチャネルのリバランスはやはり上述の困難に直面します。費用をかけてリバランスすると結果的にユーザーに転嫁する必要がありますし、利用データをもとにインボイスの使用率を予測するなどしようにもソフトウェアの複雑性が大きく増してしまうでしょう。
このように、複数のライトニングノードからお金が出入りするカストディアルウォレットなどのLSPは、特に受け取りがどのノードを通して行われるかについて予測しがたく、バランスの安定を困難にし、ユーザーエクスペリエンスの低下を招きます。
Phantom Node Paymentsは個別のノードのバランス調整を不要にし、ユーザーエクスペリエンスの安定を実現するシンプルなソリューションとしてLDKに実装されました。
実際のノードへの資金を仮想のノードに集約する
Phantom Node Paymentsにおいて、LSPは相変わらず複数のノードを運用します。これはデバイスの分散による信頼性向上やソフトウェアのスケーリング面でのロードバランシングといった目的があるので、単一の巨大ノードにまとめることはできないという前提があるためです。