今週の論争で際立ったのは、ライトニングでInbound Feesを実現する方法をめぐり、明確に最適な提案がいない状況で、ロールアウトや後方互換性の面で懸念が残る実装方法をLndが強行突破で導入しようとしていることと、それに対する反発でした。
今日はどのような実装方法が議論に上がっているのか、それぞれの特徴と欠点、そして論争の内容をまとめました。
Inbound Feesでライトニング上の資金の流れを効率化
ライトニングにおけるルーティングノードは送金を中継する際に自らが中継先に送る金額について手数料を徴収することができます。その一方で、送金元に近いノードから自身が受け取る送金については送金元に近いノードが手数料を設定することになります。
ルーティングノードはチャネルの手数料を設定する際に自身の都合も考慮して設定します。例えば、これ以上残高がリモート側に流れてほしくないチャネルについては手数料を高くすることで中継の対価を高く設定でき、逆に残高がローカル側に偏ってしまったチャネルについては手数料を下げることでより中継に使用されやすくすることができます。ただし、自分が設定した手数料は「自分から送金先側へと流れる残高」にのみ適用され、「送金元側から自分へと流れる残高」については送金元側のノードが設定した手数料が適用されます。
このようにチャネルの手数料はチャネルの残高のバランスを調整するのに使われる主力のツールですが、現状ではバランスがリモート側に偏ってしまったチャネルの残高を自身の方に呼び戻す手段が多くありません。様々な提案がありますが、現在使えるものは基本的にはチャネルを閉鎖して新しく開設しなおす、チャネルの相手方にオンチェーン送金してチャネルバランスを自分に戻してもらう(PeerSwapに対応する相手とのみ可能)、他のチャネルから送金し当該チャネルから受け取るようライトニング上でリバランスする、の３つです。
ここで、仮に「送金元側から自分へと流れる残高」にかかる手数料を調整することができたらどうでしょう。手数料のディスカウントを設定できれば残高がリモート側に偏ったチャネルの残高を自分側に寄せやすくしたり、手数料を追加することで特定のチャネルからの流入を減らすこともできるかもしれません。
手数料のディスカウントを設定できても、送金元側のノードがその分手数料を値上げすることで差し引きゼロになる可能性もあると思います。送金を中継しやすいようにチャネルをバランスさせるインセンティブと助成金をくすねるインセンティブのどちらが強いかにかかってくるでしょう。
ちなみに手数料がマイナスとなるホップに対応する実装は今のところ存在しないので、たとえディスカウントを設定できてもインバウンドの手数料との合計がゼロ以上である必要があり、ライトニング上の送金をするだけでお金がもらえるような機能にはなり得ません。
実装方法１：channel_updateメッセージ内でディスカウントをネットワーク全体に告知
Inbound FeesはJoost Jager氏がbLIPとして提案しました。bLIPは一部のノードが対応しても良いオプショナルな規格を提案する文書で、ビットコインのBIPに対応するものです。これに対してBOLTは全てのノードが対応しなければならない規格を定めた文書です。
lightningこの実装案ではライトニングチャネルの手数料を変更する際などにネットワーク全体に配信されるchannel_updateメッセージにインバウンド手数料を追記します。このメッセージを受け取ったノードでInbound Feesに対応するノードはこの内容を解釈し、適切な金額を送金します。
一方でbLIPとして導入するということはInbound Feesに対応していないノードも多数あるでしょう。このようなノードは従来の手数料欄のみを参照して送金するため、Inbound Feesが正の値だと手数料不足で送金が失敗します。逆に負の値であればその分だけ余分に手数料を払う形になります。したがって、Joost Jager氏は当初はInbound Feesはマイナス手数料のみから利用され、ネットワーク全体が広く導入して初めてプラスの手数料も使用されるだろうと想定しています。
この実装方法の長所として、Inbound Feesを課すノードが送金の最終目的地の場合も、送金元のノードはそのことを把握しているため過不足なく送金することができます。また、主にchannel_updateメッセージの解釈と経路探索に手を加えるだけで対応できるため、ノード実装によっては比較的単純な部分の変更で導入できます。
この提案に対してMatt Corallo氏が以下の問題を指摘し、対案を提示しました：