ライトニングノードを共有できる時代は来るのか？

「普通の人はライトニングノードなんて実行しない」という主張には、技術的な難しさの側面とコストの側面があります。前者はさておき、後者は日常生活の出費をビットコインで支払っていない場合は月間の送金額も非常に小さくなりやすく、確かに手間や費用を考慮した経済合理性には疑問符がついてしまいます。

しかし、そこですぐにカストディ型のライトニングウォレットに走るのではなく、ライトニングノードの運用コスト低下を目指す人たちが存在します。比較的お手軽に利用できるノンカストディアルなライトニングウォレットの裏にはユーザーに軽量なノードを実行させるLSP型と呼ばれるもの以外にも、ユーザーの秘密鍵以外をデータセンターに置いたり、はたまた複数人で１つのノードを共有する構想など、様々なデザインパターンがありえます。

今日は実際にいくつかのウォレットで採用されているGreenlightというノード管理代行サービスと、リガのカンファレンスで聞いてきた１つのライトニングノードを複数のユーザーがノンカストディアルに共有できる構想について解説します。

・Greenlightではノードをサーバーに置き、ユーザーのウォレットには秘密鍵を保管することでノンカストディアル性を実現

・ライトニングノード内の各チャネルを違うユーザーが管理できる仕組みを作れるFROSTy Lightning

・遠隔地にあるノードとの通信によって引き起こされる問題

・どれくらいのスケールメリットが見込めるのだろうか？

Greenlightではノードをサーバーに置き、ユーザーのウォレットには秘密鍵を保管することでノンカストディアル性を実現

GreenlightはBlockstream社の製品で、ライトニングノードをBlockstream社のサーバーで動かしつつエンドユーザーの秘密鍵はエンドユーザーのスマホ内にある、というプロダクトです。既にGreenlightを利用しているライトニングウォレットはいくつかあり、例えばBlockstream GreenやRelaiなどのライトニング機能がそれに当たります。つい先日リリースされたElysium Walletも一員です（これは興味深いのでまた記事にするかもしれません）。どうも今年5月時点でGreenlight上で10万ノードが動作しているようです。

日本のDiamond Hands社が開発しているDiamond WalletなどもGreenlightを採用しています（そのため、後述する問題もあり荒削りな部分があります）。

ライトニングノードにはいくつかのSignerと呼ばれる秘密鍵があり、これらの全ての鍵をエンドユーザーに渡してしまいノード側では保持しないことによってノンカストディアルにライトニングノードを「預ける」ことを実現しました。つまり、ノード自体と鍵を分離しているのです。ここには以前紹介したValidating Lightning Signerというプロジェクトを利用しています。

VLSはライトニングノードの安全性と拡張性を高める重要な部品となるか

ライトニングノードを維持するにあたって基本的な関心事は故障やバグの可能性と、盗難を防ぐセキュリティの２つです。最近はチャネル情報のクラウドへのバックアップ等で故障リスクに対処するアプローチがありますが、後者はまだ必要な知識を身に付けてノードを適切に守る以外の対策はありません。これはライトニングノードがホットウォレットであることに起因します。 一般的には仮想通貨の保管においてホットウォレットを避け、インターネットから隔離された場所に秘密鍵を保管するコールドウォレットの利用がベストプラクティスであることは皆様もご存知のとおりです。その際に秘密鍵だけでなく署名デバイスごとオフラインに置く一例がハードウェアウォレットです。 今日はライトニングノードの秘密鍵と署名ロジックをノード自体から隔離してライトニングノードの攻撃表面を小さくすることを目標に開発されているVLS (Validating Lightning Signer)について、概要と応用方法を解説します。 Validating Lightning Signerの存在意義 VLS (Validating Lightning Sig

ビットコイン研究所加藤 規新

ユーザーが送金をする際にはウォレット側からノード側へと送金経路を探すよう指示し、見つかったらウォレット側で必要な署名を加えてノード側へと送信します。逆に受け取るときは着金（決済前）したときにウォレット側で署名をすることで受け取ることができます。ウォレットがスマートフォンにあり、必ずしもインターネットにつながっていないため、ここには少し工夫が必要になりますが。

Greenlightの価値訴求はエンドユーザーというよりはどちらかというと事業者に刺さる内容です。例えば事業者はLSPモデルを採用して自社のノードとウォレット内の軽量ノードという構成（現在のノンカストディアル・ライトニングウォレットの定番）を選択することもできますが、この構成に伴う様々な技術的課題を自社で解決していく必要があります。

一方で、Greenlightを使えばノードの管理を丸ごとBlockstream社に任せてしまえるため、ここを丸ごと外注することによってアプリケーションやプロダクトに集中することができます。基本的にはユーザーのノードに対してチャネルを開設してくれるLSPも併せて利用することになります。

Greenlightには特有の課題がまだあります…（後述）

さらに効率化しようと思えば、本来はサーバー上に大量に個別のライトニングノードがある必要はないのかもしれません。Greenlightのサーバー側が実は1つの巨大なノード、あるいは個別のノードだがネットワーク図の管理やブロックチェーンの参照など重複する部分を共有している、という構成も考えられると思います。

ライトニングノード内の各チャネルを違うユーザーが管理できる仕組みを作れるFROSTy Lightning

先日も触れたラトビアのカンファレンスで聞いた中でかなり面白かったのがSphinxのPaul Itoi氏による「FROSTy Lightning」というプレゼンテーションでした。

Greenlightの項目でも触れた通り、ライトニングノードにはSignerと呼ばれる秘密鍵がいくつかあります。例えばNode SignerはノードIDとなる公開鍵に対応していて、一部のライトニング上のメッセージ署名などに使われます。それに対して、各チャネルにもChannel Signerというものが個別に存在し、オフチェーントランザクションの更新や一部のメッセージ署名を担っています。

Paul Itoi氏はこのうちChannel Signerをシュノア署名を使ったマルチシグ（FROSTという手法）によって作成し、要するにそのチャネルの更新（送受金）に遠隔地にある複数の鍵が必要になるプロトタイプを作成したというのです。

つまり、該当するチャネルについて次の図のような関係が成り立ちます：

FROSTy Lightningは名前の通りマルチシグに重点を置いていますが、原理的にはそれぞれのChannel Signerが別のユーザーが鍵をもつシングルシグだったとしたら複数ユーザーで１つのライトニングノードを共有しているような形になります：

鍵がノード上にないことから署名に少し時間がかかるのでルーティングノードには向いていませんが、1つのライトニングノードを実行する計算リソースで多数のユーザーのチャネルをホスティングできるため効率は良いでしょう。送金時の経路選択については遠隔ノード任せとなるため、プライバシー面での弱点といえます。（今日紹介している全ての手法に当てはまる気がしますが）

ただし、チャネル開閉時の扱いを含め、ノード自体に多くの改修が必要になると思われます。現時点で存在するものではないため、「いつか出てくるかもしれない」１つの手法だと思ってください。

遠隔地にあるノードとの通信によって引き起こされる問題

さて、GreenlightもFROSTy Lightningも鍵とノードが別々のロケーションにあることが想定されます。場合によっては地球の裏側かもしれません。多くの場合は鍵はスマートフォンにあるでしょう。この条件が引き起こす様々な問題が予想されます。

例えば動作の遅さ、これは先述しましたがルーティングノードには致命的かもしれません。北米にあるサーバーと日本にある鍵だと、どうしても1回の送金中継に合計数秒の時間がかかってしまったりします。速度も求められるライトニングにおいてこの違いは重大です。

また送金を受け取る場合に、決済する前にブロックの同期が完了したことを確認する必要があり、実はGreenlightのノードは定期的に動作を停止してコストを削減しているため、資金を安全に受け取れるまで数秒～数十秒かかる場合があります。（Diamond Handsのウォレットが最近この問題に直面していました）

もしFROSTy Lightningでマルチシグを利用しているなら、通信経路はもはや自分とノードの間ではなく、他の署名者も絡み複雑化する上に、通信にかかる時間も大きく増えてしまうなど、これらの問題はさらに大きくなります。またマルチシグでチャネルを共有すること自体にも様々な問題がつきまといます。署名する前に他のユーザーの送金が正当なものかどうやって判断すべきでしょうか？

最後にスマートフォンを利用することによる問題もあります。LSP型のウォレットでも課題となるのがオフライン時の受けとり（アプリは常時起動しているわけではない）ですが、一般的にはLSP側で送金を一旦保留したり、プッシュ通知でユーザー側のアプリの起動を試みています。GreenlightはLSPと組み合わせて使うことを前提として同じような仕組みを実現できますが、FROSTy Lightningのチャネル接続相手をLSPに限定してしまうとノードを共有できるメリットが激減してしまうように思います。

どれくらいのスケールメリットが見込めるのだろうか？

このように、遠隔地にあるノードと通信しなければ動作しないライトニングウォレットには様々な課題があり、解決可能なものから原理上避けられないものまであります。しかし、ライトニングノード（またはその一部）を共有するメリットとしてのコストダウンはどれくらい望めるのでしょうか？

Greenlight＋LSPの既定のケース

単純にライトニングノードをクラウドにホスティングして、その管理をBlockstream社に任せるという話ですが、手元のライトニングノードを管理するのと比べて人的コストはほとんどかかりません。Greenlight側にノウハウが溜まっていたり、自動化できている部分が大きいためです。

例えばトラブルシューティングや管理に月1時間かかるだけだったとしても、10万ノードで月10万時間の節約に。現実には技術的なスキルも求められるため、ライトニングノードの管理負担がもっと重いと感じるユーザーは少なくないでしょう。

Greenlight＋LSP＋重複する部分の共有でコストダウン

さらにGreenlight側でコストを削減する方法として、ライトニングノードのうち個別に動かす必要のある部分以外を共有することでコストダウンを図ることができます。例えばライトニングネットワークに接続して新しいチャネル・ノードについての情報を受け取る部分などは全てのノードに共通なので、本来は個別に立てる必要は小さいです。

Greenlightは比較的軽量に動作するCLNをライトニング実装に採用しているので、仮に全て合計して1ノードあたり256MBのメモリを必要とするとしましょう。共有できる部分がこれの半分だったとしても128MB×10万ノードで12.8TBのメモリ要求量削減になります。実際はもう少し複雑な話ではありますが、スケール感でいえばそれなりのリソース節約になります。

FROSTy Lightningで1つのノードを共有

では、FROSTy Lightningではどれくらいの人数で1つのノードを共有できるのでしょうか？

ルーティングノードの定石の１つとして、チャネルを100本程度に抑えたほうがルーティングされやすいというものがあります。これは経路選択のアルゴリズムにも関連したことなので通常のライトニングノードに当てはまる話ではないかもしれません。例えばライトニング上で最大のノードの１つ、Phoenix Walletを運営しているACINQは3500本ものチャネルを持っています。（これに加えて、Phoenixなどのチャネルは非公開なので数十万本があると考えられます。）

仮に100人で1つのノードを共有するにしても3500人で共有するにしても、非常に大きなリソース削減につながることは明確です。なぜなら、本当に署名部分以外は単一のノードを動かしているのと大差ないためです。

FROSTy Lightningで1つのチャネルを共有＋ノードの共有

ここにさらにFROSTy Lightningで提案されているようなマルチシグチャネルを使えば、１つのチャネルを数人でシェアして使うことも考えられます。お互いのチャネル内残高を記録していかないといけなかったり、送金時にもマルチシグ相手がオンラインである必要性が出てきてしまいますが、これらが認められるトレードオフであればさらに数倍の効率化が見込めるかもしれません。

逆に他のユーザーのせいでチャネルが強制閉鎖されるリスクもあります。

​Greenlightは「自分のノードをクラウド上にホスティングしてもらう」、FROSTy Lightningのような仕組みでノードを共有できれば「１つのノードをシェアする」というふうに、効率面で後者のアプローチが勝ることは明確な気がします。これから数年内にそういうプロダクトが出てくるかもしれません。