# LNノードの運用に関する注意点

運用面で想定される様々なリスクとその対策を列挙していくドキュメント

ここにはないトラブルに直面する可能性も考えてディフェンシブに運用したい

## セキュリティ面

#### 秘密鍵の流出

LNノードはホットウォレットのため、LNおよびオンチェーンの秘密鍵が流出のリスクに晒されやすい。秘密鍵をオフラインにして使用する場合は送受金のたびに手動で署名が必要になるので、個人的利用ならまだしも今回の目的だとTPSが劇的に落ちる。

対策としては、LNノードを運用するデバイスのアクセス権の適切な管理、LNノード以外のソフトウェアからできる限り隔離する攻撃平面の最小化、他のLNウォレットやコールドウォレットなどへの定期的な送金による送金可能残高の限定などが考えられる。

また、LNノードの秘密鍵でインボイスに署名するため、秘密鍵が流出すると任意のpreimageに対するインボイスを作成できてしまい、攻撃者にL1でClaimされてしまう可能性があるため注意が必要。

#### アクセス権の流出

LNノードへの接続に必要なTLS証明書・権限Macaroon・パスワードの漏洩は、秘密鍵の流出と同程度のリスクである。対策としては、送金機能が必要なければ送金権限のない権限を限定したMacaroonを発行し使用することで攻撃者によるLN送金は防げる。

なお、前述の通り不正にインボイスを発行されてしまうとL1で補償をClaimされてしまう可能性があるため、今回のユースケースではインボイス生成権限だけのMacaroonでも資金流出リスクがあることに注意が必要である。

#### プリイメージとインボイスの流出

ユーザーはオペレーターの不正を告発するのにそのオペレーターが発行したインボイスとプリイメージをもって支払いの証明としている。したがって、プリイメージの生成が甘かったり使い回すとユーザーに予測され、L1でClaimされてしまうリスクがある。

またインボイスの第三者への流出に関しても、それ単独ではリスクではないが、必要以上に公開しないようにしたい。(ユーザーが勝手に公開することは防げないが)

## その他のGOX対策

#### ストレージのバックアップ

データが壊れることによるGOXを防ぐには、コミットメントTXの更新のたびに最新ステートのバックアップを取ることが望ましい。そうすればストレージが壊れても、LNウォレットのシードとバックアップを使って安全に各チャネルを閉鎖してやり直せる。(間違って古いステートを配信してペナルティで没収されない。) 相手が古いステートを配信した際にペナルティTXを出すのに必要なrevocation keyも都度バックアップして保管する必要がある。

あるいはミラーリングで事故った際の可用性を高めることも可能だが、費用対効果は疑問。また、LNノードをまるごとミラーリングするのは事故が起こりやすいので非推奨。

具体的な方法・ツールは要検討。

## 可用性面

#### チャネルバランスが内側に偏って送金を受け取れない

まず最初に送金を受け取るためには、外側にバランスのあるチャネルが必要である。これは外部からチャネルを開設したり、開設してくれるサービス(LNBIG等)を利用したり、自らチャネルを開設し外部へと送金することで獲得できる。

手数料として送金を受け取っていると、どんどんチャネルバランスが内側に偏ってくる。LNでは手数料市場の存在で送金需要の大きいノードに対して他者がチャネルを開設してくれるようになっているが、万一そうならない場合には前述の方法でバランスを調整する必要がある。

なお、流出リスクを限定するために定期的に他のLNウォレットへと送金することは、チャネルバランスの維持にも役立つ。

#### 未決済HTLCが多すぎてチャネルが使えなくなる

LNチャネルは同時に保有できる未決済HTLC数に上限がある。これが上限に達してしまうと、そのチャネルで新しい送金を受け取れなくなってしまう。また、多数の未決済HTLCを含むチャネルを強制決済することは割と大きなコストがかかる。

他者から他者への送金の中継を行わない設定にし、受け取った送金をすぐ決済することで回避できる。

#### LNノードが落ちる

LNノードは十分な処理能力を与えればかなり安定性は高いが、万が一LNノードが落ちても自動的に再起動するように、システムサービスあるいはDockerコンテナとして管理したい。長期間落ちていると可用性面のみならずチャネルのセキュリティが機能しない。

#### Bitcoinノードが落ちる

これはLNノード以上に滅多に起きないが、システム障害や停電等を考慮して、自前のBitcoinノード１つのみに接続する設定ではなく、バックアップとして複数用意することを検討したい。あるいは、信頼できる別のノードも登録しておく。

#### チャネルがオフライン

十分な数のチャネルがあれば、そのうちの一部がオフラインでも支払いを受け付けることができる。

## プライバシー面

LNにはタイミング攻撃などプライバシー面での攻撃手法がいくつか存在するが、一般的に送金者以外が送金者を特定することは困難である。また、中継ノードは送金者・宛先ともにわからない。

ただし、ユーザー側はL2のトランザクションとの結びつき、Claim時のL1との結びつきなどで追加で漏洩する情報はある点に留意したい。

オペレーターはLNと同レベルの匿名性で稼働可能なように思える。

Torを使うかはセキュリティ・プライバシー面のメリットとUX面・レスポンス時間のトレードオフで要検討だが、各オペレーターに委ねて良いのではないか。

## DoS攻撃、リソースの問題

#### 未決済HTLCで取引の邪魔されるジャミング攻撃

前述の対策で回避できる。

#### 大量のインボイスを短期間に作成させられる攻撃

インボイスを生成した時点で、生成ノードはプリイメージを期限まで保管する必要がある。これを逆手に取って、大量のインボイスを生成させてストレージを圧迫し、ノードの動作に影響を与える攻撃が想定できる。

だからといって単純に未決済インボイスの生成数を限定すると、ノードは守れてもDoS攻撃自体は可能である。

考えられるリスク低減策としては、ユーザーアカウントやIPアドレスあたりのインボイスリクエスト数の制限、インボイス期限を短く設定することなどである。

将来的にはStateless Invoicesという、インボイス自体にプリイメージの生成に使う情報を含めて送金時に伝達してもらう方法も使えるようになりそう。(ウォレットや中継ノードの対応が必要なので現時点では非現実的)

#### チャネルを持つ相手が全員DoS攻撃などでダウンする

大規模攻撃で防ぎづらい。プライベートチャネルを一定数保持することで牽制はできても、インボイスにプライベートチャネルの情報を乗せることになり、結局接続相手が露呈してしまう。

質の悪いピアを排除するには、向こうから開かれるチャネルサイズに下限を設定すると良い

## ルーティング関連で覚えておきたいケース

#### 送金失敗時(送金途上、エラーあり)

送金途上でエラーが発生した場合、送金自体がrevertされ、何も起こらない。→無問題

#### 送金スタック時(送金途上、エラーなし)

送金したがプリイメージもエラーも返ってこない場合、ユーザーは支払いがオペレーターまで到達したかわからない。(※スタックの大半のケースでは到達していない) L2上で反映されてるか確認することはできる。

急ぎであればもう一度、違う経路で試すと成功するかもしれないが、後にスタックしていた送金が通って二重で支払ってしまう結果になるかもしれない。

#### 送金成功後スタック時

これはオペレーターがプリイメージを返して手数料を受け取ったが、プリイメージのユーザーへの伝播段階でスタックするレアなケースである。L2上に反映されていることを確認したら再度送金する必要はない。

プリイメージの伝播はHTLCの資金を受け取るインセンティブで機能しているが、それでも伝播が止まった場合、その地点から先のノードはHTLCのタイムアウトで資金を取り戻せる。この場合、L2の取引は実行され、ユーザーはプリイメージを持たないが、手数料を支払ってもいない。損をするのはプリイメージを伝播せず自らへのHTLCを決済しなかったノードのみ。