LNDのInbound Routing Fee対応が目前に

加藤規新 • 2024年04月26日

去年の1月、本稿でライトニングネットワークにおける「Inbound Routing Fee」をめぐる論争について取り上げました：

重要な背景知識となるため、今回の記事と合わせてご覧いただくことをおすすめします。

さて、おそらく2024年夏～秋頃にリリースされるLnd v0.18.0でついにInbound Routing Feeを設定できるようになります。今日はその変更の内容とその影響について改めて解説します。（若干のネタバレになりますが、上の記事で紹介した論争が収まったわけではありません。）

・ライトニングのRouting Feeの決まり方

・Inbound Routing Feeの実装方法と、各実装の反応

・本当に効果があるのかは不透明

ライトニングのRouting Feeの決まり方

ライトニングネットワークにおいて、複数のチャネルを経由する送金は2つ目以降のチャネルにおいて中継手数料を支払います。この中継手数料はその際に中継するノードが自由に設定し公表するものです。

では、手数料はどのように決めているのでしょうか？送金を中継する「中継ノード（Routing Node）」の視点から考えてみましょう。

ライトニングチャネルには容量に関して「キャパシティ（容量、総残高）」と「バランス（残高分布）」の２つの概念と、「（自ノードからみた）アウトバウンド手数料」と「（相手ノードからみた）アウトバウンド手数料）」の２つの手数料があります。例えばAliceとBob間のチャネルについて、次のようにキャパシティとバランスを表します：

Alice　◯◯◯◯＿＿＿◯◯　Bob

キャパシティは６で、バランスはAlice側に４、Bob側に２となります。用語としてはAlice側からみてLocal Balanceが4、Remote Balanceが2と呼んだり、もう少し古い用語だとAlice側からみてOutbound Capacityが4、Inbound Capacityが2ともいいます。

さて、仮にAliceが送金の中継によって手数料収入を狙ういわゆる「中継ノード」だとすると、このバランスを概ね３：３に保ちたいはずです。なぜなら、チャネル内のバランスという情報は非公開で、現状のバランスを知らない送金者によってAlice側・Bob側の両方から送金が試行される可能性があり、バランスが極端に偏っていると送金を中継できないことが増えてしまうためです。

送金を中継できないとエラーを返して送金者に別の経路を試してもらうことになりますが、そうすると送金手数料を受け取れないばかりか送金者から見たそのチャネルの「信頼性」が下がり、それ以後の試行自体が減ってしまいかねません。

そこでAliceは手数料を設定することで資金の流れる方向を調整しようとします。例えば上の例ではバランスが４：２となっていますが、放っておくと５：１、６：０というふうに残高がAliceに偏る状況だと仮定します。これはBob側からAlice側へと送金が流れやすい状況になっているということです。したがってAliceはAlice→Bobの向きの送金手数料を引き下げ、現状の流れに対抗する送金がこのチャネルを利用するように促すことができます。

Alice　◯◯◯＿＿＿＿◯◯◯　Bob

このようにAliceがOutbound Routing Feeをちょうどよく引き下げることで資金の流れは均衡し、概ね１：１のバランスを保てる状態が理想的です。もちろん、これ以外にもBobが自身のOutbound Routing Feeを引き上げるケースも考えられます。チャネルのバランスに関してAliceとBobの利害は概ね一致しているためです。

チャネルのバランスは非公開情報ですが、このようにRouting Feeが変更される場合、どちらにバランスが偏りやすいかを推測することはできます。この情報を活用して新たにチャネルを開設する相手選びの参考にしている中継ノードもいるかもしれません。

ここで重要なのは、AliceもBobも自身からみたOutbound Routing Feeしか調整することができないことです。それは送金を中継する際に、「自分の資金を利用する送金」から手数料を得ている性質のためです。（自分のノードが送金を中継するとき、入ってくる向きの送金はそのチャネルの相手方の残高を利用するが、出ていく向きの送金はそのチャネル内の自分の残高を利用するため、そこで手数料を徴収できる）

今回のInbound Routing Feeの話は、つまるところチャネルの相手方がいい感じに手数料を調整してくれないときに自分で調整する方法を用意するものです。

Inbound Routing Feeの実装方法と、各実装の反応

今回Lndに追加されるInbound Routing Feeの設定はOutbound Routing Feeと同じくチャネルごとに設定可能で、既定値はこれまで通りゼロとなります。

送金者はさっきの例で言えばAlice→Bobの方向に送金するときはalice_outbound_feeとbob_inbound_feeを合算してそのチャネルを利用する中継手数料とします。

Inbound Routing Feeに対応しているライトニング実装であれば上記の式が計算できますが、対応していない場合はこれまで通りalice_outbound_feeだけを参照するため、仮にbob_inbound_feeがプラスの値であった場合は送金が失敗してしまいます。前述の通り送金の失敗はチャネルの評価を落としてしまうため、当面はInbound Routing Feeを設定する場合の主流はディスカウント（キャッシュバック）になると思われます。この場合、非対応のクライアントからの送金はキャッシュバックを放棄して従来通りの手数料を支払う、という形になります。

冒頭でリンクした昨年の記事内の論争は解決しておらず、今回のLndのアプローチは実際にはオプショナルなBLIPではなくライトニング自体の仕様であるBOLTに関わるものだとして反発する実装が多く、対抗してInbound Routing Feeをローカルで完結する形（チャネルを共有するノード同士のネゴシエーション）で実現するBLIPも提案されていますが、Lndは強行突破する様子です。

ほかの実装ではLDKだけはマイナス手数料（キャッシュバック）によるユーザーの利益を考えてLndに追随して実装する方針のようです。Lnd自体がライトニングノードの大多数を占めているため、アップデートされたライトニングウォレットからInbound Routing Feeの恩恵(?)を受けることになるでしょう。

また、チャネルの両端のノードが対応していればライトニングネットワーク上のchannel_updateメッセージでネットワークにInbound Routing Feeを公開できる性質のものと思われるので、新しくチャネルを開き直さないと使えないという類のアップデートではありません。（間違っていたらすみません）

本当に効果があるのかは不透明

ここまでInbound Routing Feeが導入されることでノード運用者がより効率的にチャネルを管理できるようになるという前提のもとで話を進めましたが、実際にそうなるかはやってみないとわからない部分があると思います。

というのも、やはりアクティブにチャネルを管理しているノード同士であればInbound Routing Feeの導入以前からお互いにチャネルバランスを保つインセンティブがあり、両者が適切に手数料を調整していたわけです。適切にバランスが取れている状況でInbound Routing Feeの出番はあまり想像できません。

活躍する場面があるとすれば手数料の設定を放置しがちなノードと接続している中継ノードが、その怠けがちなノードの代わりに手数料をうまく操縦したい場合でしょう。しかし、この状況には何点か疑問がわきます。

まず、中継ノードとして資金効率を意識してバランスを細かく調整するようなノードがそのような雑なノードとチャネルを共有すること自体が非効率的な点です。理想としては、お互いに「わかっている」ノードとチャネルを共有するのが一番資金効率的にも労力的にも好ましいでしょう。中継ノードの経済的側面からみた疑問点です。

もう１つは「相手のOutbound Routing Feeが低すぎる」状況への対処に非常に使いにくい点です。このような状況においてチャネルバランスは自分の方へと偏りがちになることが想定されます。Inbound Routing Feeを使ってこれを解決するにはプラスのInbound Routing Feeを設定することとなりますが、そうするとInbound Routing Feeに対応していない送金者からの送金は従来の安い手数料を参照しているため失敗してしまいます。これを嫌ってInbound Routing Feeはマイナス手数料が主流となるだろうと前述しましたが、この縛りがあることで資金の流れを逆転したい場合に予想以上に使いにくい可能性があります。

また、（確か）そのチャネルの利用で課されるOutbound Routing FeeとInbound Routing Feeの合計がマイナスになる設定はチャネル内で資金の流れが逆転してしまうためできなかったように思います。この制約も、相手方のOutbound Routing Feeが安いときに取れる対応の幅を狭めるでしょう。

このようにその有効性にも若干の疑問が残るInbound Routing Feeですが、Lndへの導入によって早ければ今年後半～来年にはなんとなくの答え合わせができ始めるかもしれません。

他にもウォレットで「送金手数料を◯sats節約しました！」のようなアピールが見られるようになるかもしれませんが、数字が小さすぎてありがたみが伝わらない可能性だってあると思っています。（笑）

加藤規新

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