Lightning Networkのノード運用をする場合、特に重要なのがバックアップです。オンチェーン上のビットコインのバックアップは秘密鍵を保管しておくだけで良いですが、LNのノード運用をする場合は少し特殊です。LNノードのバックアップは大きく2つに区別することができます。それは①オンチェーン資金のバックアップと②オフチェーン資金のバックアップです。①のバックアップは秘密鍵の保管をするだけで問題ありません。②のオフチェーン資金のバックアップとは、チャネルのバックアップです。LN上のチャネルは送受信がある度にチャネル状態が更新されていくので、その都度バックアップをとる必要があります。もし古いチャネル状態で相手と通信をすると、不正な状態と見なされ、最悪の場合、資金を失うかもしれません。

data loss protection

そのような場合を考慮して、LNの仕様書では data loss protection （DLP）と呼ばれる安全装置が付いています（02-peer-protocol）。これは、もしアリスのチャネル状態が5で、ボブのチャネル状態が6だった場合、アリスのチャネルは古い状態なので、ボブにチャネルを強制閉鎖することを依頼できる仕組みです。この依頼を受けたボブが取れる行動は、(a)最新のチャネル状態6で強制閉鎖するか、(b)古いチャネル状態、例えば自分の残高が多くなるようなチャネル状態まで遡り、そのチャネル状態で強制閉鎖することが考えられます。ボブが(b)の選択をしても、もしアリスが嘘を付いていて最新のチャネル状態までデータを保持していると、ボブはペナルティとして、アリスに全額没収されてしまいます。そのため、ボブは(a)の正直な選択を取ったほうが無難なのです。これが data loss protection と呼ばれる仕組みで、ゲーム理論的な側面があります。この仕様は各LNソフトウェアに実装されています。

またLNDでは、static channel backup（SCB）と呼ばれるチャネル開設がある度に取得するバックアップがあります。これは、最初のチャネル状態だけをバックアップして、リストア時にSCBからチャネル状態を復元しようとするとチャネル状態が古いので、DLPによってチャネルの強制閉鎖を相手に依頼するというものです。このSCBはLNDのみ実装されており、c-lightningやEclair coreには実装されていません。LNのバックアップでは秘密鍵以外にも②のチャネルのバックアップも必要でした。一見するとこのSCBは必須な気がしますが（実際コミュニティでも議論されている[1] [2] [3]）、そもそも data loss protection は自分がデータを消失したことを相手に通知する仕組みで、ゲーム理論的な側面があるにしても、相手が不正をせずチャネル閉鎖をしてくれることに依存・信頼を置いています。この理由からLND以外のソフトウェアはSCBの実装がされていないのが現状です。ただ、c-lightningでは lightningd.sqlite3 がチャネル状態諸々を管理するDBで、このDBをチャネル開設ごとに保存することで、LNDのSCBと同じように相手にチャネル強制閉鎖を要求することが実質可能です。

static remotekey

SCBによるバックアップができない場合、チャネル上の資金を回収することはできないのでしょうか？理想的には①の秘密鍵だけを保管することです。その状態に近づけるために考案されたのが static remotekey と呼ばれる仕組みです（03-transactions）。LNのチャネルは送受信がある度にチャネル状態が更新されますが、それに伴い強制閉鎖するための commitment tx のアウトプットも変化していきます。それ故にチャネル状態を常に追っていく必要がありましたが、この static remotekey を使うとそのアウトプットのアドレスを固定にすることができます。これにより、相手が強制閉鎖するという条件はありますが、秘密鍵さえ保管していれば、オフチェーン資金も回収することが可能です。

・・・

以下は主要なLN実装ソフトウェアと上記でみたバックアップ種類の対応表です。feature bitsとはLNノードが各機能をサポートしていることをシグナリングするものです。どのソフトもDLPとStatic Remotekeyは対応しているのが分かります。またSCBはLNDのみが実装されていますが、極論をいうとSCBとDBバックアップはさほど変わりはなく、DBバックアップはデータ容量が大きいというぐらいです。とは言え、SCBはデータサイズが小さく、簡単にバックアップとリストアができるのは、ユーザーフレンドリーだと思います。

まとめ

static channel backup と data loss protection による強制閉鎖の要求も、 static remotekey による資金回収も、最終的には相手側が不正をせずにチャネルを強制閉鎖することが必要です。ここにある一定の信頼や依存があることがLNの難点だと思います。また別な視点では、不正をするとペナルティを課せられるのだからユーザーは正直な行動をとるので、LNの仕組みは十分機能していると考えることもできます。どちらにしても、バックアップをしっかり取っていればある程度の復旧は可能で、そのリスクを考慮してもゼロ承認による低手数料・高速送金は魅力的ではないでしょうか。