Zenn
Closed2

Lightning Network ノードのDBの冗長化/バックアップ

motimoti

Lightning Network ノードのDBバックアップ

冗長化/バックアップ

  1. DBのレプリケーションによるチャネルの最新状態の保持
  2. チャネルの開閉時のバックアップ(SCB: Static Channel Backup)

考え方

  1. データベースは、同期的なレプリケーションを行えば、冗長化が可能
  2. データベース上でチャネルの最新状態を維持できなくなったら、SCBを利用して相手のノードに強制閉鎖の依頼が必要。
    • 閉鎖は自分でやらずに相手に依頼する。さもないと相手にPenalty Txを発行されて資産を失う。
    • 閉鎖せずにオフチェーンTxを継続した場合の言及は見つからなかった。本来の履歴におけるCommitment TxがRevokeされていない状況になるため、恐らく損することになる（要出典）。

SCB (Static Channel Backup)

https://techmedia-think.hatenablog.com/entry/2019/04/24/135549
https://spotlight.soy/detail?article_id=o38b3zme7

LNDのデータベース

DBのデフォルトがbboltで、単一ファイルに書き込むKVSなので障害に弱い（モバイルノードでの運用には便利）。

障害耐性のために、代わりに etcd, PostgreSQL(, SQLite3?) が使える。

etcd を使う場合は、LNDノードもクラスター化できる。
（Leader Electionにetcdの機能を使う。）

https://github.com/lightningnetwork/lnd/blob/master/docs/leader_election.md

The leader election feature currently relies on etcd to work both for the election itself and for the replicated data store.

Is leader election supported for Postgres?
No, leader election is not supported by Postgres itself since it doesn't have a mechanism to reliably determine a leading node. It is, however, possible to use Postgres as the LND database backend while using an etcd cluster purely for the leader election functionality.

DBにPostgreSQL等を使用する場合は、同期的なレプリケーション(Synchronous Replication)にすべき。

In case a replication architecture is planned, streaming replication should be avoided, ... synchronous mode, albeit slower, is paramount for lnd data integrity across the copies, as it will finalize writes only after the slave confirmed successful replication.

https://github.com/lightningnetwork/lnd/blob/master/docs/postgres.md#important-note-about-replication

(補足) bboltを使用する場合

bbolt (デフォルトで使われるKVS) は、channel.db にファイルで保存される。バックアップはほぼ不可能。

基本的に channel.db はmigrateに利用し、restoreでは使用しない。
https://docs.lightning.engineering/lightning-network-tools/lnd/secure-your-lightning-network-node#docs-internal-guid-8725c728-7fff-9b34-f746-fcdc7a49c5e5

ファイルからのバックアップは、クラッシュしたノードから直接取得するなど、確実に最新の状態の記録が保証されている時にのみ行うこと。
https://docs.lightning.engineering/lightning-network-tools/lnd/disaster-recovery

bboltでも長らく運用実績が存在する。モバイルノードなどの環境で便利。
bboltを安定して使用したい場合、ファイルシステムレベルで冗長化したほうがいい(RAIDやZFS/Btrfsなど)。

CLN

https://docs.corelightning.org/docs/advanced-db-backup

SQLite3, PostgreSQLに対応している。
エンタープライズとしては、PostgreSQLを使うと良い。

冗長化には、SQLite3はlitestream, PostgreSQLはpg_clusterがある。

同期的なレプリケーションにすべき。

https://www.postgresql.org/docs/13/warm-standby.html#SYNCHRONOUS-REPLICATION

不明点

  • DBが落ちなければ、ノードが落ちてもデータは失われないか？
    • 特に言及ないし大丈夫だと思うが、わからない。
    • 復旧時に相手ピアにオンチェーン化されている可能性はあるだろう。
  • CLNでノードを分散する方法は？
このスクラップは1ヶ月前にクローズされました