Forwardable Peerswaps

加藤規新 • 2022年10月21日

10月9日、ライトニングチャネルを閉じずにリバランスするPeerswapプロトコルをより便利に拡張しようと匿名開発者のZmnSCPxjからLightning-devメーリングリストに提案がありました。今日はその内容について解説します。

[Lightning-dev] Forwardable Peerswaps: Improving Network Health Via Pressure Release Valve

Peerswapについて

Peerswapについて詳しくは過去記事を参照してください。

短くまとめると、一方に偏ってしまったライトニングチャネルの残高を自分への送金によってリバランスする代わりに、チャネル内で残高が余っている方のチャネル内残高とその相手のオンチェーンの資金とをアトミックスワップで交換してリバランスと同様の効果を実現するシンプルなプロトコルです。ローカルバランスがほしい、リモートバランスがほしいの両方の場合に対応できます。

ライトニングの送金手数料は金額に比例するため、金額が大きいチャネルのりバランスをライトニング上で行うのはコストが高くなりがちです。そこで、チャネルを持つ相手が応じるならばPeerswapを使ってオンチェーンの安い手数料でリバランスを行うことができます。

Peerswapの欠点

従来のPeerswapにも欠点があります。チャネルを共有する相手としかできないこと、ローカルバランスがほしい方のオンチェーン資金に余裕があること、そしてオンチェーンのトランザクションがHTLCの作成時とHTLCの決済時の２回発生することです。

そこで、Forwardable Peerswapsは直接チャネルを共有していないノードとでもPeerswapを実行できるように従来のPeerswapを拡張する提案です。

Forwardable Peerswapsの仕組み

Forwardable Peerswapsの機能はインセンティブ設計に要点があります。まずは大まかな流れを見ていくためにOnchain-to-offchain Peerswap (オンチェーン資金を使ってローカルバランス＝LNチャネル残高を買う)を考えます。

用語の整理としてノードを３種類に分けましょう。消費者などで支払い＞受け取りなNet Senderノード、事業者などで受け取り＞支払いなNet Receiverノード、そしてルーティング目的のノードです。

まず、ローカルバランスが枯渇してきたNet SenderノードAが通常通りあるピアBとPeerswapを開始します。この際、Bも自身のチャネル一覧を確認し、ローカルバランスが枯渇してきて補充したいものがあれば、その先のノードCとPeerswapを開始します。ところが、このとき新たなPeerswapを開始せずに「AからBのPeerswap」を「AからCのPeerswap」となるように情報を伝達します。これがForward (転送)という名前の由来です。

この処理を繰り返していくと、ルーティングノードをいくつか経由した後にどこかの段階でリモートバランスがほしいNet ReceiverノードXにたどり着きます。Xはリモートバランスを増やしつつチャネルを閉じずにオンチェーン資金を手に入れたいので、Aのオンチェーン資金と自身のLN上の資金を交換します。するとLN決済によって経路上のBやCなどもリバランスしたかのような効果が得られ、ネットワークの流動性がNet SendersからNet Receiversへの送金をより多く処理できる状態に改善されます。またこのとき、オンチェーントランザクションもPeerswapが一度だけ行われたのと同じ２回(A-X間)で済みます。

インセンティブ設計の面で優れているのは、中継するノードはあわよくば無料でチャネルバランスの改善を図れることによって、上記の例で言えばAとXのマッチングなどが不要で経済合理性だけでNet SenderからNet Receiverまでたどり着けることです。

既存の提案よりもシンプルに問題解決

まさに、中継するノードの経済合理性によってNet SenderからNet Receiverまでたどり着けるというシンプルさが、ネットワーク流動性の最適化問題を解決しようとする他のアプローチより圧倒的にスマートなのです。

例えばAmboss MagmaやLightning Poolのようにマッチングのために中央主権的なサーバーを頼る必要はなく、またLiquidity adsのようにマッチングする意図のないただの中継ノードがオンチェーン資金を維持する必要もありません。さらに、チャネルのバランスによって手数料を変更する類のアプローチのように細やかな情報をネットワークに配信したり、ライバルに手の内を明かす必要もありません。

Forwardable Peerswapはシンプルかつ優れたインセンティブ設計によってマッチングと資金効率を両立しているのです。

欠点

これはオンチェーンとオフチェーンのアトミックスワップ全般に言えることですが、offchain-to-onchainのスワップ(LNの資金を払いオンチェーン資金を受け取る)はonchainを提供する側から見るとイタズラに脆弱です。オンチェーンでHTLCを作ったり取り消すのにはコストがかかるのに対して、オフチェーンのHTLCは無コストでキャンセルし得るからです。となると、取引相手が不特定となるForwardable Peerswapの仕組みとは相性が良くありません。

offchain側がonchainの資金も持っていれば共同でトランザクションを生成するなどしてインセンティブを調整できそうという指摘もされましたが、そもそもonchainの資金がないからoffchain-to-onchainのスワップをしている場合にはどうにもならなさそうです。

まとめ

・Forwardable PeerswapsはPeerswapをマルチホップで行えるように拡張する提案

・中継ノードが「タダで２つのチャネルをリバランスできる」という可能性によってリバランスが必要なチャネルを次々と経由し、最終的に「リバランスよりリモートバランスがほしい」というノードに行き着くインセンティブ設計によって中央主権的なマッチングやバランス情報の漏洩が要らない上に、中継ノードはオンチェーン資金を常備する必要がない

・Onchain-to-offchainのスワップでの使用が現実的か

加藤規新

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