NLoop は、 Submarine Swap によって自分の運用する LND node の channel の状態を管理するためのデーモンです。
何をするものなのか
Submarine Swap とは、一言でいうと Lightning Network のチャンネルにロックされた資産 (off-chain asset) を、ブロックチェーン上の UTXO (on-chain asset) と交換するプロトコルのことです。
より詳しく知りたい方は、例えば以下の文書を参照してください。
なぜ作ったのか
1. 既存のソフトウェア (Lightning Loop) に至らない点があったため
Submarine Swap による Channel の状態管理をするためのソフトウェアには、 Lightning Loop と呼ばれるものがすでに存在します。
しかし、 bitbank が自社サービスのためにこのソフトウェアを利用するにあたって、好ましくない点がいくつかありました。
a. BTC 以外の swap をサポートしていない
Submarine Swap の目的の一つに、 Channel の流動性枯渇に伴う開閉の回数を最小限にする。というものがあります。
これは、常に Channel の状態を一定に保つことで管理を楽にしたいという点もさることながら、オンチェーントランザクション発行に伴うマイナー手数料の出費を低く抑えるためでもあります。
しかし、 LightningBTC to on-chain BTC の swap では、結局オンチェーン手数料を支払うことになってしまうので、対して削減できません。
NLoop は Loop と異なり、 BTC to LTC の swap もサポートしているので、より手数料の小さい Litecoin を使うことで経費を削減することができます。
b. swap 相手に制限がある
Lightning Loop では、 Swap を行う相手のサーバーは、 Lightning Labs が運用する物に限られます。そしてそのソフトウェアはクローズドソースです。
彼らのビジネスモデル上、ここは譲れない点なのだと思うのですが、ユーザーは選択肢が無いため以下のような不利益を被る可能性があります
- Lightninglabs 側がインバウンドキャパシティを取得するために、チャンネルを閉じる可能性がある
- 高い手数料を取られても別の選択肢がない
- サーバーサイドがクローズドソースであるため、自分たちがサービスを提供する側になる可能性が閉ざされている。
2. その他の選択肢が貧弱だったため
上のような Loop の問題点を受けて、別の選択肢を探したところ、 boltz-backend というソフトウェア/サービスが見つかりました。
開発もそれなりにきちんと行われており、ライセンスは FOSS である AGPL だったため、これを使えないか検討したところ、同じ人達の開発した boltz-lnd というクライアントが見つかりました。
ただし、これは以下の点が不満でした。
a. Server 側の挙動の Validation が不十分である
一般に、暗号資産を扱うアプリケーションをトラストレスにするためには、かなり注意して構築する必要があります。
相手がプロトコルに違反するようなレスポンスを返してきた場合はもちろんのこと、「プロトコルには違反していないが自分に有利な情報を返す」ようなケースもあり、網羅的に検証する必要があります。例えば、最初に実行に伴う fee をクエリして相手が伝えてきた内容と、実際に相手が送ってきた Invoice などの情報に齟齬がある場合などです。
このようなケースは普通想定するよりも多くのことを考慮する必要があります。例えば、相手が要求する金額は想定内ではあるけれど、相手との間にあるチャンネルが非常に大きな rougin fee を徴収するようなものであった場合、そうとは気づかずに大量の資金を失ってしまうことがありえます。
boltz-lnd は ( server side と同じ人たちが作っているためということもあり)、このような網羅性に不安がありました。
また、支払いたい fee の最大値を予め指定しておき、相手がそれより高い fee を要求してきた場合に swap を実行しないなどといった機能も必要でした。これは後述の Autoloop の実現に必要なものです。
b. エッジケースへの対処
boltz の開発人にとっては、 boltz-lnd よりも boltz-server の方が重要であるため、開発リソースはそちらに多く割かれています(多分)。
そのためブロックチェーンが reorg した場合や、 server が swap 途中で再起動した場合の挙動に不安がありました。
c. 必要な機能の不足
Lightning Loop には、Autoloop といって、自動で swap を行い続けてくれる機能がありますが、 boltz-lnd にはそれがありませんでした。
boltz-lnd に手を加える、または boltz-lnd を監視する別のデーモンを作る、といった事も考えたのですが、上記の fee の validation の問題や swap にかかった費用の計算などの機能も欲しかったため、 0 から作ったほうが楽そうということでこの案は却下しました。
d. サーバーサイドとの密結合
これは a (Server 側の挙動の Validation が不十分である)と関連しています。
boltz-lnd は、 boltz-server とのみ動作することを前提としているため、例えば現在の swap がどのステージに居るかという情報を、 相手の Server から教えてもらう形で動作します。
将来的に、 boltz-backend 以外の相手 (例えば、lightning loop server) に対しても動作するようにしたいため、このような依存を除外する必要がありました。
3. 可用性の高いアーキテクチャを試すため
暗号通貨を扱うアプリケーションには、以下の特有の要件が発生します。
このような要件に対処するため、 NLoop は、 Event Sourcing Pattern で作成されています。言語は F# です。
a. 監査を用意・確実にしたい
一般に、金融関連のアプリケーションに生じることの多い要件として、過去に何が起こったのかをすべてチェックしたいというものがあります。
そのため、 DB への操作の log を残しておくことに気を使います。
また、このような audit log は、運用している人物にすら簡単には変更できないものであるとなお良いです。
金融関連アプリの場合、内部の人物による犯行にも十分考慮する必要があるためです。(例えば以下の文書を参照)
Event Sourcing System ならばアプリケーションへの変更が log そのものになるので、このような要求に楽に対処できます。
また、資産の増減を監視することで運用に伴うコストの最適化するという点でもこの手法の方が適しています。
b. event の発行と、実際のアプリケーションの状態との間に齟齬が発生しないようにしたい
アプリケーションが、状態の変更と別サービスへの通知を同時に行いたい場合、一時的な通信の不具合などによってどちらか片方だけが発生してしまうようなケースがあります。
これはエッジケースですが、金融関連サービスの場合、その齟齬が致命的なことになる場合が多いので、Transactional outbox pattern などで対処する必要があります。
Submarine Swap の場合、例えば下流のサービスが swap の発生を検知しそこねた結果、良からぬことが起きる可能性があります
Event Sourcing System だと、この問題への対処が簡単になります。
c. Block explorer に依存したくない
一般に、ブロックチェーンを監視するようなアプリケーションの多くは、 監視だけを目的としたマイクロサービスである Block explorer を利用します。 (e.g. electrs)
ただ、 NLoop の場合はそこまで複雑な監視をしているわけではないことと、できる限り依存アプリケーションを少なくしたいことから、 Block explorer を省き、直接 block (あるいは、 filtered block) をチェックするような方式にしています。
event sourcing アーキテクチャを採用することで、block explorer がなくとも、 reorg 時の処理などが比較的 straight forward なものになっています。(具体的には event に IsOnChainEvent フラグを付けておき、ブロックが chain から外れたらこのフラグをもつ event を skip するようにします。)
また、将来 block explorer が容易に使えないような環境 (e.g. スマホ端末)にも対応できるようになっています。
どうやって使ったら良いのか
NLoop の利用に興味がある方は 公式レポジトリ からダウンロードし、まずは regtest での実行の手順 をなぞってみてください。
Open API の仕様 (Source) を見れば、だいたい何ができるのかわかると思います。
利用に伴う注意点: ライセンスについて
**現状 NLoop は、 open beta です。利用は自己責任でお願いいたします **
NLoop は、 PolyForm Small Business License を採用しています。
個人や、小規模なビジネスオーナーの場合 ... 永久に利用に制限はありません。
一定以上の規模の企業の場合 ... その場合も現状制限は一切ありませんが、将来制限を加える可能性があります。
現在の計画は、 Lightning Loop のように我々の運用するサーバーを相手にすることを要求するというものです。
これは、ソフトウェアの開発保守に対する正当な要求であると考えています。トラストレス性は担保されている (つまり、ユーザーが自分でコンパイルできる) し、ユーザーはいつでも別の選択肢 (e.g. Lightning Loop) にスイッチできるためです。
とはいえ、現状サーバー運用の目処が立っていないので、将来より permissive なライセンスに変更する可能性は高いです。ゆるいライセンスに変更するほうがその逆よりも簡単なので、はじめは厳しめのライセンスで公開しています。
今後の計画
NLoop の開発方針
今後の計画として、複数サーバーを比較して最も条件の良いものと swap を実行する機能や、自己支払いによる rebalance の自動化機能などを計画しています。
bitbank 社全体の方針
bitbank, inc では、取引所の User アカウントからの Lightning 入出金機能や、 Lightning Hub の運用開始を検討しています。
絶賛採用中なので、 Lightning 関連開発をしたい方は是非応募してみてください。
