はじめに

ライトニングネットワークには自ノードが他ノードの送金を仲介した場合に徴収できるルーティング手数料（以下fee）という概念があります。feeの価格競争（一般に安い方が送金されやすい）は安価な送金の実現に一役買っており、同時にノードを維持するインセンティブを生み出しています。

最近では著名なノードがfeeで収益を上げているというニュースもチラホラ入ってきていますね。

ただ、feeの仕組みを理解せず闇雲にチャンネルを開設してもうまくいきません。まったくルーティングされないか、ルーティングされても他ノードのカモにされてチャンネルバランスが崩れ、リバランス手数料で赤字になるのが関の山です。

この記事ではライトニングネットワークに手を出してみたけどルーティングされなくて悩んでいる初心者の方向けにfeeの概要について説明を試みます。また、おまけとして有料部分に弊ノードの基本戦略を書き出してみます。

feeとは何か

先述の通り、feeとはライトニングネットワーク上での送金を仲介した際に徴収できる手数料です。ここでいう「仲介」とは、自ノードと接続した送金元ノードから入ってきた資金が自ノードと接続した送金先ノードに出ていくことを指します。この際、自ノードと送金先ノードを接続するチャンネルの自ノード側のfee設定に応じてfeeを徴収できます。資金が入ってくる時にはfeeは発生しません。

ライトニングノードを運用している方は早速チャンネルのfee設定を確認してみましょう。Umbrelを運用している場合は単体では確認できないので、ダッシュボードのApp StoreからRide The Lightning（以下RTL）をインストールしてください。

RTLにログインし、左側の「Lightning」から「Peers/Channels」を開きます。 チャンネル一覧が表示されるので確認したいチャンネルの右端のコンボボックスから「Update Fee Policy」を押してください。現在の自ノード側のfee設定が表示されます。

このうち直接関係するのは「Base Fee」と「Fee Rate」の2つで、両者を足し合わせたものが徴収できるfeeです。

「Base Fee」は基本料金です。仲介する資金の金額に関わらず、必ず徴収する金額になります。Umbrelの初期設定では1000mSat（=1Sat）が設定されています。

「Fee Rate」は従量課金です。仲介する送金額の何%を手数料として徴収するかを設定します。Umbrelの初期設定では0.0001%が設定されています。

ちなみにこの初期Fee Rateは安すぎるぐらい安い設定と言ってよいと思います。特に意図が無ければ取り急ぎ0.01%程度に上げて「Update Channel」ボタンを押して変更しておきましょう。

ちなみに同じチャンネルの相手側のfee設定についてはチャンネル一覧右端のコンボボックスから「View Remote Fee」を押すことで確認できます。

fee設定を変えると何が起きるか

資金がチャンネルを出ていくときにfeeが発生することを考えれば、fee設定が低ければ出金されやすく、高ければ出金されにくいだろうことは容易に想像がつきます。

またライトニングネットワークの仕様を頭に入れると、出金とはチャンネルのアウトバウンドキャパシティがインバウンドキャパシティに変化することを意味します。つまり、fee設定が低いとインバウンドキャパシティが生まれやすく、高いとアウトバウンドキャパシティが溜まりやすいと言い換えることができます。

さらにインバウンドキャパシティとはそのチャンネルで受領できる金額を意味するため、fee設定が低いとより多くの資金が流入する素地ができ、高いとより多くの資金が流出する素地ができる、と言い換えることができます。

fee設定とノードの需給

加えてfee設定に影響する要素としてノードの需給があります。資金流入の需要が高いノードに対するチャンネルはかなりfee設定を上げても出ていきますし、その逆も真です。

ただ、需給判断は需要が高いノードと直接接続するチャンネルだけ見ても判断できません。

入金需要が高い事業者ノードDがあり、そこにチャンネルをつないでいるノードBとCがあるとします。BはDの需要が高いことを知り、Dと接続するチャンネルのfeeを上げ、Cは需要が無いとみなし下げています。一方、CはDの需要を知ってか知らずか、Dとのチャンネルに相場よりかなり安いfeeを設定しています。

この状況で各チャンネルのイン／アウトのキャパシティが十分にあると仮定し、AからDに送金しようとした場合、下記２つのシナリオが考えられます。

1. B→Dのfee < B-Cのfee + C-Dのfee ならば A→B→Dのルートで送金
2. B→Dのfee > B-Cのfee + C-Dのfee ならば A→B→C→Dのルートで送金

つまり経由するノード数が増えたとしても全体として安ければそのルートが使われるということです。さらに言えばCにはDへ安く送金できるという見えない需要があるとも考えられます。

ならば、ということでBがB→Cのfeeを上げるとどうなるでしょう。短期的に見れば1のシナリオになる可能性が高まりますが、AがCに直接チャンネルを開いたり、AとCを安価に仲介するFが現れれば全くルーティングできなくなるかもしれません…

このようにノードの需要を見極めてfeeを設定するのはライトニングノードの運用上重要なテーマであり醍醐味ですが、時々刻々と変化する情報となるため絶対的な正解はあり得ません。その上で、どのようなノードに需要があるのかまとめたロクヨウ氏の記事は理解の手助けになると思うので貼っておきます。

feeとリバランス

ルーティングが発生すると流入元チャンネルのインバウンドキャパシティがアウトバウンドキャパシティになり、流出先チャンネルのアウトバウンドキャパシティがインバウンドキャパシティに変化します。トコロテン方式、ビリヤード方式、ソロバンの珠…等々、色々な表現がありますが兎にも角にもチャンネルの両端のキャパシティを増減させることで価値の移転を表現するのがライトニングネットワークです。

この仕組みにより、特定のチャンネルでルーティングが集中するとチャンネルのキャパシティバランスがイン／アウトのどちらかに偏った状態になります。前述の例でいえばB→Dの方向でルーティングが起き続けると、キャパシティはイン側に偏りアウトが枯渇するため、早晩このルートでは送金できなくなるでしょう。そうならないために行うのがチャンネルキャパシティのリバランスです。

Bが自分自身に対してB→C→D→Bのルートで送金すれば、B→Cのアウトバウンドキャパシティを失う代わりにその分のアウトバウンドキャパシティをB→Dに補充することができます。もちろん、この送金はCやDにとってはルーティングに他なりません。BはC→DのfeeをCに、D→BのfeeをDに支払うことになります。

つまり、リバランスにおいてもfeeは無視できません。場合によっては赤字になるかもしれません。Bが赤字にならないためには下記の条件を満たす必要があるでしょう。

将来得られるB→Dのfee > リバランスで支払うfee (C→DとD→B)

しかし実際にはこれでは不十分です。なぜならB→Cのルーティングが発生した際に生まれていたはずのfeeが、リバランスによってアウトバウンドキャパシティを失った分だけ減るためです。したがってより厳密には下記のような条件に修正されるべきです。

将来得られるB→Dのfee > リバランスで支払うfee (C→DとD→B) + リバランスで生じる機会損失分のfee (B→C)

この「リバランスで生じる機会損失分のfee」はリバランスに使用するチャンネル（First Hop Channel / First Outgoing Channel）に設定されたfeeに依存します。どのチャンネルを使ってリバランスするか、も考えないといけないということです。

なお、リバランスにかかるコストの比較対象が将来得られるfeeであることは留意すべきです。ルーティングが全く起きなければ損になりますし、リバランス後にfee設定を下げ過ぎても損になるでしょう。チャンネルを相手に閉鎖されない保証もありません。

弊ノードの戦略