ライトニングの中継ノードの運営で苦慮するのは適切な手数料設定です。なぜなら、あるチャネルからの収益を最大化させるためには「チャネルの回転率を高める」ことと「中継あたりの手数料率を最大化する」ことが求められるためです。

チャネルには双方向に送金需要がある場合と、専ら一方向に送金需要がある場合があるので、費用を払ってでも残高を「再チャージ」したいような場合もあります。これを一般的にチャネルのリバランスと呼びます。

リバランスにはLNを経由して自分自身のチャネルに送金する方法や、スワップサービスを利用する方法など色々ありますが、その中でも比較的最近生まれた方法に「インバウンド手数料（ディスカウント）」を利用して特定のチャネル経由で中継を受け付けやすくするという戦略があります。

Inbound Routing Feeについては過去記事を参照してください。

LNDのInbound Routing Fee対応が目前に
去年の1月、本稿でライトニングネットワークにおける「Inbound Routing Fee」をめぐる論争について取り上げました： 難ありなInbound Fees実装をLndが強行突破で導入する思惑にライトニング開発者らが反発今週の論争で際立ったのは、ライトニングでInbound Feesを実現する方法をめぐり、明確に最適な提案がいない状況で、ロールアウトや後方互換性の面で懸念が残る実装方法をLndが強行突破で導入しようとしていることと、それに対する反発でした。 今日はどのような実装方法が議論に上がっているのか、それぞれの特徴と欠点、そして論争の内容をまとめました。 Inbound Feesでライトニング上の資金の流れを効率化 ライトニングにおけるルーティングノードは送金を中継する際に自らが中継先に送る金額について手数料を徴収することができます。その一方で、送金元に近いノードから自身が受け取る送金については送金元に近いノードが手数料を設定することになります。 ルーティングノードはチャネルの手数料を設定する際に自身の都合も考慮して設定します。例えば、これ以上残高がリモート側に流れてほし
ビットコイン研究所加藤 規新

実際にInbound Routing Feeを設定するとそのチャネルからの中継が発生しやすくはなるのですが、問題なのが「どのチャネルに出ていく中継か選べない」ことです。Inbound Routing Feeがどでかい調節弁として機能しても、細かい結果が望んだとおりになるとは限りません。

そこでInbound Routing Feeと並行して提案されていたPairwise Fee Schedulesというコンセプトならどう解決されていたか、今回はこれについて詳しく見ていきましょう。

・ライトニングの中継は実質的に非代替性の残高のトレーディング

・Pairwise Fee Schedulesは厳密な値付けを可能にする技術

・莫大な組み合わせ数やBOLT対応の必要性が欠点

ライトニングの中継は実質的に非代替性の残高のトレーディング

冒頭で言った通り、送金の中継をするライトニングノードは実質的にチャネル内の資金を何回転させられるか、いくらで売れるかという商売をしています。これはつまり、それぞれのチャネルごとにチャネル内資金の特徴が異なり、そのため適切な手数料設定が異なるということになります。

実際にライトニングチャネルには手数料がゼロに設定されているものから0.5%程度のものまで幅広く存在します。（それより高く設定されているチャネルすらありますが、そのレベルになると本当に中継させる気があるのか疑わしいです）

もちろん中継ノードにも様々な戦略が存在するので一概には言えませんが、収益を最大化するには中継できる残高をいかに安く早く仕入れるか、仕入れた残高をいかに高く早く中継に使えるかの勝負になるのはすべての戦略に共通しています。そこで、なかなか仕入れがうまくいかないチャネルの仕入れにお金を出そうというのがInbound Routing Feeの考え方です。

💡
Inbound Routing Feeは一般的にマイナスの値を取ります。（つまり、送金者目線でいえば割引が受けられます。）なぜなら、Inbound Routing Feeは新しい仕様で、プラスの値に設定するとそれを理解しないノード実装からの送金が手数料不足で失敗してしまうためです。

そこで問題となるのが、中継ノードがせっかくお金を払って中継を獲得したのに、その中継で出ていく先のチャネルの回転率も低くて結果的にあまり得をしていないようなケースです。Inbound Routing Feeは中継元のチャネルを指定できても、中継先のチャネルに関しては選ぶことができないためです。

これは値付けの問題ですが、たくさんチャネルを持っていると交換しているもの（中継元チャネルの残高と中継先チャネルの残高）同士の組み合わせがたくさんあるので自分にとって不利な組み合わせが選択されてしまう可能性が高くなります。送金者にとって一番おいしいためです。

Pairwise Fee Schedulesは厳密な値付けを可能にする技術

そこでPairwise Fee Schedulesという提案がありました。

これは具体的には、中継元のチャネルと中継先のチャネルの組み合わせによって手数料を設定するという手数料の公開方法です。先ほどのトレーディングの例えに戻ると、正しく「チャネルAのローカルバランスとチャネルBのローカルバランスを交換するときの比率」を表現することができるため、中継ノード目線で最も厳密な値付けを可能にします。

個人的にはルーティングの本質を考えたときに一番しっくりくる手数料の設定方法だと思います。

💡
ひょっとするとチャネルをいくつかのノードにわけて運用することでInbound Routing Feeだけでもある程度効率化できたりするのかもしれません。ここは研究が必要な分野ですね。

逆にPairwise Fee Schedulesが存在しないことによって、LN全体で手数料が高止まりしやすい構造になっているともいえます。中継ノード目線だと、自身が不利な組み合わせで送金を中継してしまったときでも赤字が膨らまないように高めに手数料を設定する必要があるためです。

したがって、ユーザー目線ではPairwise Fee Schedulesが導入されたほうが安くLNを利用できるというメリットが考えられます。

莫大な組み合わせ数や対応の複雑性が欠点

それではなぜルーティングの改善策としてPairwise Routing FeeではなくInbound Routing Feeが導入されたのでしょうか？

1つは対応が比較的簡単だったためです。Inbound Routing Feeに非対応のノードはそれを無視しても大抵の場合は送金が行えます。Pairwise Routing Feeで同じことをしようとすると（非対応のノードと比べてすべての組み合わせにおいて必ず手数料が安くなるようにしないといけないため）設定がかなり複雑になっていまいます。

また、大規模なルーティングノードになると組み合わせの数が非常に大きくなってしまいます。例を挙げると、チャネルを3000本持っている巨大なルーティングノードでは450万通りもの組み合わせが存在するので、その設定データをどうやって伝播するのか、更新するときにどうやって更新するのかが課題になります。

このようにInbound Routing Feeに敗北を喫して現時点では導入されていないPairwise Fee Schedulesですが、一部には根強いファンがいるため将来的に再訪されるかもしれないアイデアの1つです。手数料市場の効率化が求められるフェーズがいつか来るなら、そのときまた議論が活発化するでしょう。

まとめ

・Pairwise Fee Schedulesは中継元・中継先チャネルの組み合わせごとに手数料を設定することができる仕組みで、ライトニングの中継手数料の設定を効率化することができる提案である

・もともとはInbound Routing Feeに対抗するアップグレード案だったが、よりシンプルなInbound Routing Feeに敗北して現時点では導入されていない

・手数料市場の効率化はユーザーにとっても手数料の低下というメリットをもたらすため、将来的に再訪されるかもしれないトピックである