LNのルーティングシュミレーター「CLoTH」について

  初めまして．株式会社Next Finance Techで10月後半よりインターン生としてリサーチ業務に携わっている，宮本と申します．
  普段は電気システムや情報通信システムなどを学んでいる大学生です．

  この記事では，Lightning Network(LN)のルーティング戦略についてLNのシミュレータであるCLoTHの使い方について詳しく説明したいと思います．

LNのルーティングについてとシミュレーションの目的

  LNのルーティング状況について問題点などを軽く整理しておきたいと思います．まず初めに目的ですが，ルーティング戦略を立てる目的はより多くのインセンティブを受け取るためです．
  次にルーティング戦略を立てるうえで考慮しないといけない問題点は，チャネルの偏りです．チャネルに偏りができてしまうと片方からの送金しか行うことができず，ノードの使用率が落ちインセンティブを受け取ることが少なくなります．

  そこで，偏りを解決する手段として2つ解決策があります．1つ目は，リバランスです．しかし，リバランスでは他のチャネルを経由するときに手数料がかかるためインセンティブよりもリバランスの手数料の方がかかってしまうということが起きてしまうことがあります．また，チャネルを閉じる手段もありますが，オンチェーンに戻すときの手数料がかかるためどちらにせよインセンティブよりもかかってしまうケースがあります．
  もう一つの解決策として，チャネルの手数料を上げ下げしてチャネルのバランスを取り持つ方法があります．この方法は，LNのルーティング探索のダイクストラ法の性質を逆手に取ったものです．

  今回はCLoTHの使い方と実際にCLoTHを用いて実験があった論文の紹介をしたいと思います．

CLoTHについて

  今回のLNのシミュレータで使うCLoTHについてどういったものなのかを軽く紹介したいと思います．
  CLoTHとは，C言語で記述されたペイメントチャネルネットワークシミュレータです．入力は，PCNと支払いのリストです．次に，実装されている離散イベントマッピング関数が実行されることにより，入力ネットワークでの入力支払いの実行をシミュレートします．出力は，支払い関連のパフォーマンス測定値（支払い成功の確率や平均支払い時間など）が生成されます．

 データ構造は以下の画像のようになっています． channel構造ではどのノードとどのノードがつながっており合計の容量がどれくらいかが定義されます．edge構造ではチャネルの方向ごとの設定がされています．通常手数料や比例手数料や最小のHTLCがデータとしてあります．

・CLoTHの詳細な情報
https://www.sciencedirect.com/science/article/pii/S2352711021000613 

CLoTH使ってみた

  では，実際に使いそれをもとに詳しく説明していこうと思います．
  CLoTHはこちらで入手可能です．ページの右側のReleasesよりcloth-v1.1-betaがダウンロードできると思います．ダウンロードしたら次はGitHubのREADMEに従い必要なものをインストールしてください

  次にアウトプット先のファイルを作成しておきます．ファイルを作成しておく理由は，カレントディレクトリがごちゃごちゃになるのを避けるためです．

$ mkdir output
$ make build
$  ./run-simulation.sh <seed値> ./output/

   以上で実行すると以下のようになると思います．どうでしたか無事に動いたでしょうか？

  多分シミュレーションがうまくいかなかった場合は，多くが「EXECUTION OF THE SIMULATION」の実行が終わらずそのところで停止しているか，もしくは「INITIAL DIJKSTRA THREADS EXECUTION」後にセグフォを起こしたりしていると思います．あとは，成功率が0の場合0では割り切れないよというエラーもよくでます．不親切な記事になってしまいますが，今回トラブルシューティングに関しては割愛します．

  シミュレーションがうまくいった場合は，JSONやペイメントを支払った後のチャネルやバランスなどの情報がoutputのファイルの中にあると思います．以下の画像はJSONの中身です．

  一番上が成功率で，%表示ではないので×100したら%表示になります．また，どれくらいの平均経路距離やバランスの影響で失敗したのかルートがなくて失敗したのかなどが分かるようになっています．どの失敗がどれくらい起きているのかがちゃんと分かるところが個人的にCLoTHの魅力だと思っています．

CLoTHの実例，こんなシミュレーションに使われたよ集

  CLoTHのシミュレーションを用いた論文がありますので，CLoTHってこんな風にも使えるということを紹介しておきます．紹介する論文は「Hubs, Rebalancing and Service Providers in the Lightning Network」になります．

今回紹介する論文では，CLoTHを用いて行った実験は3つあります．
・たくさんのチャネルを開設しているハブがLNに与えるパフォーマンスの影響．
・アクティブ・リバランスとパッシブ・リバランスの有効性について．
・LNでサービスが提供された場合のシミュレーション．

  1つ目のハブがLNのパフォーマンスにどのように影響を与えるのかについての結果は，ハブがなくなったとてあまり影響がないという結論になりました．
  実験の方法として，チャネルの開設数が多い上位6個のノードを順に消していき，そのたびに同じシミュレーションを回して結果がどう変わったのかを調べるというやり方で行われました．
  具体的な数値としては，消したハブの数：0個，成功率：95.2%で消したハブの数：6個，成功率：94.98%とほぼ変わっていません．前後の結果で他に変化したのは，ホップ数で3.34から3.62と微弱に増加したという結果でした．

  2つ目は，アクティブ・リバランスとパッシブ・リバランスの有効性についてです．アクティブ・リバランスとはチャネルのリバランシングを目的とした支払いを行うことで，一方のパッシブ・リバランスとは手数料を変更することでリバランシングしようとするやり方です．結論は，アクティブ・リバランスは効果なしだがパッシブ・リバランスは効果ありという結論でした．
  実験方法は，アクティブ・リバランスの方はチャネルの偏りが総量の20%を下回った時にチャネルを5：5になるようにリバランスし，リバランシングをしなかった時と比較するやり方．一方のパッシブ・リバランスはチャネルの手数料をバランスと反比例になるようにし同じくリバランシングをしなかった時と比較するというやり方で行う．
  アクティブ・リバランスでの失敗の主な原因は，リバランスの試みのほとんどが失敗しているところにあります．どれくらい成功しているのかというと，16%ほどしかリバランスは成功していません．成功率もリバランスをしなかった時と比べほぼ変わらないという結果になっています．パッシブ・リバランスの方は，ルートが見つからない失敗率が上昇しましたがそれ以上にTxがとっているため有効性は高いという結論になっています．

  3つ目は，LNでサービスが提供された場合のシミュレーションです．3つの役割のノードを振り分けます．1つ目は，Payeers：支払いを受け取るだけのノード（約6%）．2つ目は，Payers：支払いしかしないノード（約57%）．3つ目は，Hybrid：両方行うノード（約37%）．といった具合にノードごとに役割を持たせます．シミュレーションは役割を持たせたLNと役割が特にないLNを比較しています．
  結果は，役割のないLNと比べ26%ほど成功率が減少するという結果になりました．失敗の原因は，チャネルの偏りによるものが主な原因のようです．

以上がCLoTHを用いて実験された例です．

  CLoTH事態にランダムでのグラフの生成がうまくいかない問題があったり（私は自前のコードでランダムでグラフを作りCSVに書き写すことで回避しています）使う上で工夫して使わないといけませんが，LNでのシュミレーターとしてルーティング戦略を考えるうえでは活躍できると思っています．今後の進展としてCLoTHを用いてパッシブ・リバランスの手数料の最適解を探してみたりコントリビューターになれたらいいなと思っています．