難ありなInbound Fees実装をLndが強行突破で導入する思惑にライトニング開発者らが反発

加藤規新 • 2023年01月13日

今週の論争で際立ったのは、ライトニングでInbound Feesを実現する方法をめぐり、明確に最適な提案がいない状況で、ロールアウトや後方互換性の面で懸念が残る実装方法をLndが強行突破で導入しようとしていることと、それに対する反発でした。

今日はどのような実装方法が議論に上がっているのか、それぞれの特徴と欠点、そして論争の内容をまとめました。

Inbound Feesでライトニング上の資金の流れを効率化

ライトニングにおけるルーティングノードは送金を中継する際に自らが中継先に送る金額について手数料を徴収することができます。その一方で、送金元に近いノードから自身が受け取る送金については送金元に近いノードが手数料を設定することになります。

ルーティングノードはチャネルの手数料を設定する際に自身の都合も考慮して設定します。例えば、これ以上残高がリモート側に流れてほしくないチャネルについては手数料を高くすることで中継の対価を高く設定でき、逆に残高がローカル側に偏ってしまったチャネルについては手数料を下げることでより中継に使用されやすくすることができます。ただし、自分が設定した手数料は「自分から送金先側へと流れる残高」にのみ適用され、「送金元側から自分へと流れる残高」については送金元側のノードが設定した手数料が適用されます。

このようにチャネルの手数料はチャネルの残高のバランスを調整するのに使われる主力のツールですが、現状ではバランスがリモート側に偏ってしまったチャネルの残高を自身の方に呼び戻す手段が多くありません。様々な提案がありますが、現在使えるものは基本的にはチャネルを閉鎖して新しく開設しなおす、チャネルの相手方にオンチェーン送金してチャネルバランスを自分に戻してもらう(PeerSwapに対応する相手とのみ可能)、他のチャネルから送金し当該チャネルから受け取るようライトニング上でリバランスする、の３つです。

ここで、仮に「送金元側から自分へと流れる残高」にかかる手数料を調整することができたらどうでしょう。手数料のディスカウントを設定できれば残高がリモート側に偏ったチャネルの残高を自分側に寄せやすくしたり、手数料を追加することで特定のチャネルからの流入を減らすこともできるかもしれません。

手数料のディスカウントを設定できても、送金元側のノードがその分手数料を値上げすることで差し引きゼロになる可能性もあると思います。送金を中継しやすいようにチャネルをバランスさせるインセンティブと助成金をくすねるインセンティブのどちらが強いかにかかってくるでしょう。

ちなみに手数料がマイナスとなるホップに対応する実装は今のところ存在しないので、たとえディスカウントを設定できてもインバウンドの手数料との合計がゼロ以上である必要があり、ライトニング上の送金をするだけでお金がもらえるような機能にはなり得ません。

実装方法１：channel_updateメッセージ内でディスカウントをネットワーク全体に告知

Inbound FeesはJoost Jager氏がbLIPとして提案しました。bLIPは一部のノードが対応しても良いオプショナルな規格を提案する文書で、ビットコインのBIPに対応するものです。これに対してBOLTは全てのノードが対応しなければならない規格を定めた文書です。

この実装案ではライトニングチャネルの手数料を変更する際などにネットワーク全体に配信されるchannel_updateメッセージにインバウンド手数料を追記します。このメッセージを受け取ったノードでInbound Feesに対応するノードはこの内容を解釈し、適切な金額を送金します。

一方でbLIPとして導入するということはInbound Feesに対応していないノードも多数あるでしょう。このようなノードは従来の手数料欄のみを参照して送金するため、Inbound Feesが正の値だと手数料不足で送金が失敗します。逆に負の値であればその分だけ余分に手数料を払う形になります。したがって、Joost Jager氏は当初はInbound Feesはマイナス手数料のみから利用され、ネットワーク全体が広く導入して初めてプラスの手数料も使用されるだろうと想定しています。

この実装方法の長所として、Inbound Feesを課すノードが送金の最終目的地の場合も、送金元のノードはそのことを把握しているため過不足なく送金することができます。また、主にchannel_updateメッセージの解釈と経路探索に手を加えるだけで対応できるため、ノード実装によっては比較的単純な部分の変更で導入できます。

この提案に対してMatt Corallo氏が以下の問題を指摘し、対案を提示しました：

・Inbound Feesを設定しても相手がチャネル手数料を変更して帳消しにできてしまえるので、分けて管理する必要性は低いのではないか。

・最終的にプラスの手数料にも対応するには様々なライトニング実装が広く対応することが必要であり、ディスカウント以外のケースを含めて考えるならbLIPでなくBOLTである必要があるのではないか。

・後方互換性が仮にあったとして、マイナスのInbound Feesは送金者にとって得なので対応インセンティブがあるとしても、プラスのInbound Feesに対応するインセンティブはないのではないか。そもそもプラスのInbound Feesによって従来ノードの送金が失敗するなら後方互換性がないと言えるのではないか。

実装方法２：チャネルごとに当事者間で手数料をネゴり、ネットワークには従来と見分けのつかない手数料を告知

Matt Corallo氏は対案として、Inbound Feesを設定したい場合、そのチャネルの相手のノードに手数料を変更するようリクエストする仕組みを提示しました。こちらのほうがローカルな変更であり、bLIPという形式にも合致しています。

ハイレベルな仕組みは非常に単純で、Inbound Feeと従来のチャネル手数料は合算されて送金者に支払われるため、それぞれの値はチャネルの運用者らが管理し、合計値を従来通りチャネル手数料として公開します。そのチャネル内でHTLCを作るたびにInbound Feeと従来のチャネル手数料を考慮した値で更新すればチャネル内部でプラスおよびマイナスのInbound Feeを強制することができます。(相変わらず合計値はゼロ以上が条件)

実装面ではHTLCの追加などチャネルの更新に関する部分に手を入れる必要があるのと、Inbound Feesを指定する・されるためのP2Pメッセージとハンドラを追加する必要があります。

また欠点としては以下のものが指摘されています：

・送金者がInbound Feeと通常の手数料を分けて把握していないため、最終目的地のノードに対してもInbound Feeを払ってしまう。

・Inbound Feesを利用してルーティングしているチャネルではHTLCの追加にInbound Feesを考慮する必要があるため、そのチャネルの管理者同士で無料の直接送金ができなくなる。

・pairwise feesなど将来的に導入される可能性のある手数料モデルに対応できない(pairwise feesはinbound channel + outbound channelの組み合わせごとに手数料を設定する提案。この指摘は当てつけのようにも思えますが)

Lndが実装方法１の採用を強行しそうになっている

上述の通り、どちらの実装方法にも長所・短所があるように思います。しかし、Lndは実装方法１を採用しそうになっており、Joost Jager氏は実装方法１のほうが「Lndで実装しやすかった」ことを理由として挙げています。Lndで実装方法２を実現しようとする場合、合計のコード量は少なくてもチャネルのステート管理など様々な機能に変更を加える必要があり、その承認を得ることが難しいようです。

このようにライトニングネットワークの利用に大きな影響を与える変更がLndのコードベースに変更を加えるプロセスに左右されることにMatt Corallo氏を始め複数の開発者が遺憾の意を示し、実装方法２を対抗するbLIPとして投稿するに至っています。実際にこのbLIPはLDKのMatt Corallo氏に加え、EclairのBastien Teinturier氏、CLNのChristian Decker氏の支持も取り付けています(Decker氏はInbound Feesの必要性自体に疑問を付していますが)。

Lightning LabsがLndのシェアを背景にBOLTにない独自機能で囲い込みを目指していることに対する反発は何年も続いています。この論争は現在進行系ですが、そもそもInbound Feesが実際にルーティングノードの運用を改善できるのかを含め、ライトニングコミュニティの合意が取れる前からLndが特定の実装を推進することに対する反発が強く表れているため取り上げました。

加藤規新

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