ライトニングノードの多くは個人が動かしているものですが、特に大規模な事業者が動かす場合に考慮すべき点がいくつかあります。例えば常に送受金が可能になるようにチャネルの残高を管理したり、オフラインになってしまうことがないようにすることです。また、デバイスが故障した場合などに速やかに復旧するために、まだオンチェーンに反映されていない送金などのデータをバックアップしておく必要もあります。

今回の記事では、ライトニングノードのネットワークからの切断時や故障時に、安全に予備のデバイスに切り替えるために普段から「同じノード」を複数台のデバイスから使えるようにする進展を紹介します。

「バックアップ」のノード

上述したとおり、事業者にとって致命的なことに、今はオフラインのノードは支払いに使えませんし、万が一長期間オフラインになってしまうと不正行為とみなされ相手によってチャネルの残高が没収される可能性があります。そこで、ある程度大きな金額をライトニングで使用しているユーザーが、ライトニングノード固有のデータをクラウドなど違うデバイスにあるデータベースにバックアップし、故障に備えるということが現在行われています。

その状況で、ノードを動かしているデバイスが故障したときに、別のデバイスで速やかにライトニングノードを立ち上げることができれば、データの損失もチャネル残高の没収も免れることができます。これは一番簡単なライトニングノードの「バックアップ」と言えるでしょう。

ただし、ここに１つ「罠」があります。平常時に複数のライトニングノードが起動していて、１つのデータベースを共有していると、同時に書き込もうとするなどしてデータが破損する可能性があります。(同じソフトで動いていれば、同時にアクセスしようとすることも容易に想像できます。)
こうなると、意図せずとも不正行為を働いたとして、やはりチャネル残高没収の憂き目に遭います。これを避けるには、ノードが落ちたことを確認してから予備のノードを起動しなければならず、ダウンタイムが発生します。この問題に関して、ライトニング払いのAPIを開発しているSuredbitsが昨年末、Eclair Walletにシンプルな解決策を実装して提案しました。

データベースロック

Suredbitsが実装したデータベースロックとは、ライトニングノードのデータが格納されているリモートのデータベースにアクセスしている最中は、予備のノードからのアクセスを許さない、というものです。

データベースロック自体は今さら革新的なものではなく、読み書きが競合することによって意図せぬ結果をもたらすことを防ぐために多くのデータベースに存在します。データベース以外でも、処理が競合することを防ぐのに同じようなアクセス権の管理を行うシチュエーションはよくあります。

他のどのノードも書き込み権を持っていない場合は、書き込み権を取得して通常通り処理を続行できます。つまり、ノード間にメイン・予備といった主従関係はなく、単純にノードが複数個存在していて、毎回そのうち１つだけがアクセス権を取得でき、読み書きを担当するという仕組みになります。

なお、アクセス権を取得した状態で故障した場合などに備えて、アクセス権にはタイムアウトが設定されています。既定では5分となっているので、もしアクセス権を取得している状態で故障が起きると最大で5分間のダウンタイムが発生します。この数値は変更できるので、許容できるダウンタイムと、短縮によって発生しうる問題のバランスをとって各事業者によって設定されるでしょう。

おわりに

今回の機能追加でダウンタイムを最小限に限定しつつ、アクセス競合によるGOXの可能性を避けながらLNノードの複数台体制を簡単に実現できるようになります。個人のLNノードにとってより、事業者のLNノードにとって重要な進歩だと思いますが、決済用のテクノロジーとしてこのように安定性や可用性が向上する機能追加は確実に進歩です。
比較的にシンプルで直感的な内容の機能追加でしたが、まだまだこのような細かいが重要な改善点はあると思うので、大きく報道されることはなくても地道な開発がLNの発展に大きく貢献していることをぜひ知っていてください。