NLoop
https://tech.bitbank.cc/nloop-announcement-jp/
https://github.com/bitbankinc/NLoop
https://www.slideshare.net/bitbankink/lightning-network-swap-nloop
NLoop は、 Submarine Swap によって自分の運用する LND node の channel の状態を管理するためのデーモン
Submarine Swap は、Lightning Network のチャンネルにロックされた資産 (off-chain asset) を、ブロックチェーン上の UTXO (on-chain asset) と交換するプロトコルのこと
LNのチャネルの残高が減った際にオンチェーン送金してチャージするイメージ
【Submarine Swap詳細】
https://blog.muun.com/a-closer-look-at-submarine-swaps-in-the-lightning-network/
https://docs.lightning.engineering/the-lightning-network/lightning-overview/understanding-submarine-swaps
Submarine Swapの課題
Channel の状態管理には Lightning Loop が使用されているが以下の懸念点がある
BTC 以外の swap をサポートしていない
チャネルの開閉を減らすことができたが、Bitcoinのオンチェーン送金は行っているので手数料がそこそこかかる
NLoopではBitcoin以外も対応しているため手数料が抑えられる。(例: Litecoin を使ってLN残高チャージ)
swap 相手に制限がある
Lightning Loop では、 Swap を行う相手のサーバーは、 Lightning Labs が運用する物に限られる
ソフトウェアはクローズドソース
Lightninglabs 側がインバウンドキャパシティを取得するために、チャンネルを閉じる可能性がある
高い手数料を取られても別の選択肢がない
サーバーサイドがクローズドソースであるため、自分たちがサービスを提供する側になる可能性が閉ざされている。
Loopとは別の選択肢
Loopにはいくつか課題があるため別のものを調査。
boltz-backend があったが不安な要素がいくつか見つかった(https://github.com/BoltzExchange/boltz-backend)
Server 側の挙動の Validation が不十分である
トラストレスであるため、不正に対しての検証が重要だが、その検証内容が十分ではなかった
メッセージで手数料は安く伝えて、実際の送金時は大量にとるなどしてくる可能性があり事前に弾けないかもしれない
エッジケースへの対処
reorgやswap途中の異常時の挙動に不安があった
必要な機能の不足
Lightning LoopにはあるAutoloopという自動でSwapを行い続ける機能がなかった
サーバーサイドとの密結合
boltz-lndはboltz-serverとの動作を前提としているため、boltz-backend以外の相手とやりとりできなかった
上記の課題を克服した可用性の高いアーキテクチャを試す
NLoop は、 Event Sourcing Pattern で作成。言語は F#
暗号通貨を扱うアプリケーションには、以下の特有の要件が発生
監査を用意・確実にしたい
一般に、金融関連のアプリケーションに生じることの多い要件として、過去に何が起こったのかをすべてチェックしたいというものがあります。そのため、 DB への操作の log を残しておくことに気を使います。
audit log は、運用している人物にすら簡単には変更できないものであるとなお良い
金融関連アプリの場合、内部の人物による犯行にも十分考慮する必要があるためです。
https://leanpub.com/esversioning/read
Event Sourcing System ならばアプリケーションへの変更が log そのものになるので、このような要求に楽に対処できます。
また、資産の増減を監視することで運用に伴うコストの最適化するという点でもこの手法の方が適しています。
event の発行と、実際のアプリケーションの状態との間に齟齬が発生しないようにしたい
アプリケーションが、状態の変更と別サービスへの通知を同時に行いたい場合、一時的な通信の不具合などによってどちらか片方だけが発生してしまうようなケースがあります。
これはエッジケースですが、金融関連サービスの場合、その齟齬が致命的なことになる場合が多いので、Transactional outbox pattern などで対処する必要があります。(https://microservices.io/patterns/data/transactional-outbox.html)
Submarine Swap の場合、例えば下流のサービスが swap の発生を検知しそこねた結果、良からぬことが起きる可能性があります
Event Sourcing System だと、この問題への対処が簡単になります。
Block explorer に依存したくない
動作確認