データから見るLNのパブリックノードの全体図

ライトニングネットワークの可視化を行ってくれる「ライトニングエクスプローラー」と呼ばれる種類のサービスには数社あり、老舗の1ML.comや最大手のAmboss.space、さらには人気ブロックチェーンエクスプローラーのmempool.spaceなどが参入しています。大量のデータを集めてユーザーに見つけやすくすることで価値を提供しているこれらのサービスですが、実はブロックチェーンエクスプローラー同様、彼らが収集しているデータの多くは一般的なライトニングユーザーにも収集可能なものです。

というわけで、ライトニングネットワークを流れてくるゴシップ情報を保存する仕組みを構築してみました。今回は自分のノードが受信した約10日分のライトニングネットワークのゴシップデータをもとに気づいたことを取り上げてみます。

・サポートされているほどノードの多様性はない

・ルーティングに活用される手数料設定の分布

・可視化される「迷惑なノード」

サポートされているほどノードの多様性はない

ライトニングネットワークを縦横無尽に伝播していく「ゴシップ」と呼ばれるノードやチャネルに関する更新情報ですが、その中には大きく分けてnode_announcement（ノードについての情報）、channel_update（チャネルの開設や設定変更についての情報）の2つがあります。まずはnode_announcementを見ていきましょう。

まず、ノードが公表できるアドレスにはIPv4、IPv6、Tor(v2)、Tor(v3)、hostnameという5種類ありますが、10日間で収集したおよそ6900ノード分のnode_announcementの中ではTor(v2)とhostnameは使用しているノードはありませんでした。

TorV2、Hostnameは設定ゼロ

また、IPv4アドレスを公開しているノードはそのうち30%ほどと想像したより多かったです。（Umbrelなどの普及で圧倒的にTor v3だけが多いと思っていました。ただし、公開チャネルがないノードはnode_announcementが伝播されないのでそれを含めると圧倒的にTor v3が多い可能性があります。）

LNの通信にデフォルトの9735番以外のカスタムのポート番号を設定しているノードも非常に少なかったです。

カスタムポート番号の設定

遊び心のあるデータとしては、ライトニングノードはイメージカラーを設定できるのですが、一番多いのはオレンジかな？と思いきや、LNDの規定値の#3399ff（シアンと青色の中間）が一番多かったです。CLNのデフォルト色 #ffa500、Eclairのデフォルト色 #49daaaはランクインしませんでした。2位はRaspiBlitzの既定値ですが、3位もおそらく何かの既定値か団体的に決めている色だと思います。ご存じの方は教えてください。

色の分布、上位10色

ルーティングに活用される手数料設定の分布

次に、channel_updateで見つけた情報をいくつか取り上げます。Channel_updateはチャネルの開設時や手数料設定などの更新時に配信されるものなので、分析することでそのノードのルーティングの状況や戦略を窺い知ることができます。

まず、チャネルのルーティングはデフォルトでは有効ですが、「無効化」することもできます。ネットワーク全体でいうとチャネルの1/4ほどが無効化されているようです。これはルーティングノードでなければあまり意識したことがない設定かもしれませんが、チャネルの相手がオフラインであったり、残高がローカルに全くないときなどに無効化することで中継の失敗を防ぎ、ネットワーク全体の送金成功率を上げることができます。

無効化されているチャネル

次に手数料関連を見ていきましょう。

先週も少し触れたInbound Feesの設定から見ていきます。

LNDのInbound Routing Fee対応が目前に

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

ビットコイン研究所加藤 規新

Inbound Feesは最近のバージョンのLNDしかまだ対応していないので、もしプラスの値に設定してしまうとそれ以外のライトニングノード実装からの送金は失敗してしまいます。ただ、パブリックチャネルの中でもそもそも設定しているものは5%程度で、プラスに設定されているものはわずか0.1%でした。実際、自分のノードでもチャネルの20%ほどにしか設定していませんが、これはリバランスしたい特定のチャネル経由の流入を促すのに使いたい機能だからです。

Inbound Feesに対応するチャネル数

また、チャネルの中継手数料はBase Fee（固定金額）＋Feerate（従量料金）となっていますが、Base Feeについてみていきます。一般的には1 sat（1000 msat）に設定されているので、むしろ1 satより大きな金額になっているチャネルを調べてみました。

Base Fee >1 satのチャネル

グラフにしたら面白いかと思って散布図にしてみたら、明確に選ばれやすい値（キリが良い10のN乗の値や2 sat・5 sat、4バイト自然数・整数最大値など）が目立ちました。一番多いのは10 satでした。

しかし大半のチャネルはここには該当しないです。逆にBase Feeをゼロに設定しているチャネルを見てみましょう。Zero-Base-Fee Routingという概念があり、「全員がBase Feeをゼロに設定した方が送金経路選択の最適化問題が解きやすい（変数が減る）」というメリットがあるとされているため、一部のルーティングノードが積極的にBase Feeをゼロに設定しています。（少額の支払いにとっては大きな手数料削減になるので、そういうノードにとっては小さい送金を中継する可能性が高くなると考えられます）

Pickhardt Payments: How To Send Large Bitcoin Payments On Lightning

The work of Rene Pickhardt shows that despite being mainly used for small, fast Bitcoin transactions, Lightning can also deliver large payments.

Bitcoin MagazineNamcios

Zero Base Feeチャネル

実はネットワークの全チャネルの数割がZero Base Feeを採用していることがわかりました！また、そのうち2100本はFeerateもゼロの完全なるZero-fee Routingを行っています。慈善事業なのか、残高がローカルに偏っているのをなんとしてでもリバランスさせたいのかは詳細を見ないとわかりません。ちなみにZero Base FeeではないがFeerateがゼロのチャネルも1333本ありましたが、これらはローカルに偏った残高をリバランスさせたいものと考えられます。

最後にルーティングにおいてチャネルの無効化のように「中継を防ぐ」役割を果たすFeerateが極端に高く設定されたチャネルと、Max_htlc_msat（中継可能最大金額）が極端に低く設定されたチャネルを見てみましょう。

一般的にFeerateは0.1% (1000ppm)が規定値とされ、日常的に見る範囲としては0～0.5% (0～5000ppm)あたりが多いです。今回は1% (10000ppm)以上のチャネルを抽出してみました：

Feerate > 1% (10,000ppm)

max_htlc_msatを1sat（1000msat）以下に設定しているチャネル

これらのチャネルも現実的にはルーティングは発生しません。

なお、max_htlc_msatについてはチャネルサイズとの比較でもっと深い分析ができますが、今回はデータ取得の都合上割愛させていただきます。（通常はチャネルサイズほぼ全体が上限になるが、意図的にそれより小さくしているチャネルを判別する必要がある）

可視化される「迷惑なノード」

今回のデータ収集を通じてもう１つ得られた知見があります。それはライトニングのP2Pネットワークに大量のゴシップを流す「迷惑なノード」の存在です。

一応ライトニングでchannel_updateなどのゴシップ情報を流すと、受け取ったそれぞれのノードが必要か判断して、必要ならほかのノードへと伝播させます。その際、同じチャネルについてのゴシップがあまり頻繁すぎるとP2Pネットワークが輻輳してしまう（通信で混雑して正常に機能しなくなってしまう）恐れがあるので、ノードが判断して頻繁過ぎるゴシップは無視します。一般的には1時間に1回は多すぎ、最大でも3時間に1回程度にとどめ、基本は1日1回くらいが「お行儀が良い」とされます。

しかし、LNDの既定の設定だとなんと同じチャネルについて1分間に10回までゴシップの処理が許可されているのです！これを逆手にとってゴシップで大量の更新を流してくるノードの存在が確認されました。

以下はデータ収集していた約10日間で大量にゴシップを送ってきたノード一覧です：

Nodes with most gossip (top 10)

1日あたりの1チャネルあたりゴシップ数を見ると、上位3つのノードが異常に多いことがわかります。彼らは自動化しているスクリプトでmax_htlc_msatを（送金を中継するごとに？）更新しており、ネットワークの帯域幅に相対的に大きな負担をかけています。そもそもmax_htlc_msatを事細かに更新したからといって防げる中継失敗はそんなに多くないので、ネットワークからみた視点でも費用対効果が悪い情報伝達です。

個人的にはこのようなノードの行為が許されないようにlnd.confの設定を厳しくすべきだと思います。上記3ノードだけで受け取ったゴシップの12%ほどを占めていたので、P2Pネットワークでのマナー違反の影響を実感しました。