LNDのinbound feeを使う。

LNDのinbound feeを使う。

こんにちはかずみょんです。今回はLightning networkでLNDを用いたノード運用におけるinbound feeの活用方法について少し書いてみたいと思います。

ルーティングを効率よく発生させる1つの方法として資金が移動する方向に常に流せる状態を保つ必要があります。そのためのFee戦略としてoutbound balanceが多い時はFeeを安くし資金が流れ安くし、少ない時はFeeを高くし資金を流れにくくするという方法(DiamondHand method!)がありますが、従来の通りoutbound feeの設定だけでは自nodeから他nodeへの出力channel側の中継しやすさは制御できますが入力channel側の制御はできません。そこでLNDに実装されているinbound feeを設定することで入力channel側のバランスを制御しようという試みです。(LNDのinbound feeをプラスに設定することでルート探索時にエラーが発生しやすくなるのと互換性の観点から注意が必要とあるのでinbound feeに関してここではマイナス側の設定についてを話します。)

1.LNDのinbound feeの計算

Boltの仕様上自分のノードを介した際に得られるルーティング手数料は

fee_base_msat + ( amount_to_forward * fee_proportional_millionths / 1000000 )

で定義される。計算結果についてはマイナスは許容されない(例外エラーになる)。LNDの手数料計算の実装は下記のようになっており、ルート探索時

fee_proportional_millionths = 入力channel側のinbound fee + 出力channel側のOutbound fee

として計算され、計算結果がマイナスにならないように、

入力channel側のinbound fee-出力channel側のOutbound fee

の場合には 入力channel側のinbound fee =  -出力channel側のOutbound fee

に書き換えられる。

2.Inbound feeで基準点をマイナス側にずらす。

ルーティング探索時、outbound balance の多い入力チャネルからは資金の流出を抑えたい場合があります。このようなケースでは、ルーティング手数料(fee)を高く設定することで資金移動を起こりにくくする手段が考えられます。

そのため、チャネル全体に対して、デフォルトでノードの inbound fee に -1000ppm を加算します。さらに outbound fee に inbound fee 分を上乗せして相殺する構造となります。

特に流入を抑制したいチャネルに対しては、inbound fee をさらに増加させることで、ルーティング候補から外れやすくすることが可能です。

図1に例を示してみました。シナリオとしてはルーティング探索にてchannel Aは充分にoutbound capacityが確保されているため入力channelとして使われたくない。

①. node A --> 自node --> node B の場合
    手数料 = -200ppm(channel Aのinbound fee) + 1700ppm = 1900ppm

②. node C --> 自node --> node B の場合
    手数料 = -1000ppm(channel Cのinbound fee) + 1700ppm = 700ppm

3. Lightning networkのLND以外のソフトウエアではinbound feeというパラメータはない??

LND以外のソフトウェア、Core Lightning (CLN)、Eclair、rust-lightningではネットワークグラフにそもそもinbound feeなるパラメータは存在しないと思われるため、LND以外から送金した時にはルート探索時にinbound feeは無視されルーティング手数料としてinbound feeで相殺前の高い手数料設定になってしまうという問題があると思われます。Kazumyonノードは4月からinbound fee=-1000ppmを導入したのですが、導入直後ルーティングイベント数が半分以下になりました。

あわてて6月からはinbound fee=-200ppmにして観察してたらイベント数戻ってきそうな感じがしてます💦。200ppmは底上げされてしまいますが許容範囲ということでしょうか。。。LNDで結構inbound fee設定してるノードありますし他のソフトからの送金率が下がることはないのでしょうかね?と思ったりもします。

4.(めんどくさいのでAI)まとめ

今回は、LNDにおける inbound fee の仕組みと戦略的な活用法について見てきました。

LNDでは、通常の outbound fee に加えて、独自に inbound_fee_base_msat および inbound_fee_rate_milli_msatrouting_policy に実装しており、自ノードがルート探索する際に「入力チャネルに対しても手数料的な重みづけ」が可能となっています。

これによって、流出させたくない方向からのルーティングを抑制するといった、高度なバランス管理が可能になります。 いわば、自ノードの流動性を**より賢く誘導・防御するための「第2の手数料レバー」**とも言えるでしょう。

ただし、この inbound fee はあくまで LND独自の拡張仕様であり、CLNやEclairといった他実装では考慮されません。 そのため、他実装のノードが自分を通過するルートを組み立てる際には、この inbound fee が反映されず、期待した抑制効果が効かないケースもある点には注意が必要です。

実際に私のノード(Kazumyon)でも、inbound fee を -1000ppm に設定した直後はルーティング数が激減し、そこから -200ppm に緩和して様子を見たところ、イベント数が戻ってきたので、現実的な運用では「多少底上げされる程度」に抑えるのが良さそうという感じです。

ではまた。

Remaining : 0 characters / 0 images
100

Sign up / Continue after login

Related stories

Writer

Share

Popular stories

DEXアービトラージ自動化への道(序)

894

UNISWAP(V2) テストネットRopstenでETHからDAIの交換をしてみる!

631

UNISWAP SDK(V2)をいじってみる!

382