Core Lightning 25.12：「Boltzのシームレスなアップグレード体験」

yutaro stacksats
12月4日
読了時間: 7分

私たちはこれまでに 24.08、25.05、そして 25.09 にも改良が含まれていることをお伝えしてきましたが、今回のようなものは見たことがないはずです。自画自賛なのは承知していますが、今回のリリースは改良点、最適化、そしてご想像のとおり「バイアス」に満ちています。

⚡ TL;DR... ハイライト：

BIP-39 の 12 語リカバリーフレーズ
デプロイ後のフィードバックを反映した xpay の改善
大規模ノード向けの広範なパフォーマンス改善
ピアに関する情報（ping 時間や接続時間）へアクセスするための networkevents サブシステム
Exper!mental 機能：非互換なスプライシングおよび定期オファーの変更

ニーモニックの話

BIP39 ニーモニック対応の更新と、ウォレット復元の改善

これまで Core Lightning ノードは、32 バイトの 16 進シードを生成してきました。暗号学的にはクールですが、保存するにはあまり簡単とは言えません。今回から、新しく作成される Core Lightning ノードは、BIP39 に互換性のあるニーモニックシークレットで起動するようになります。この改善により、標準的な 12 語のリカバリーフレーズを使ってノードをバックアップできるようになり、認証情報を安全に保管・管理する作業が大幅に楽になります。

既存のノード運用者の皆さんにも敬意を表します。既存ノードは、これまでどおり現在の hsm_secret 形式のままで完全に動作し続け、後方互換性は維持されます。

バックアップされたリカバリーフレーズ（Core Lightning ノードのものであっても）さえあれば、BIP39 / BIP86 に対応した任意の Bitcoin ウォレットを使って、オンチェーン資金を復元できるようになりました。これは、ニーモニックで初期化されたノードに対して、Taproot アドレス用の標準 BIP86 ウォレット導出を実装したためです。

xpay がレベルアップ

私たちはオープンソースコミュニティからのフィードバックを重視しています。そして [25.09] 以降、皆さんは本当に多くの貢献を届けてくれました。ここでは、そのフィードバックと貢献を受けて実装した xpay の改善点のハイライトを紹介します。

routehints とブラインドパスを併用した同時支払いで発生していた競合を修正しました。
pay の挙動に合わせるため、支払い失敗の原因が最終ノードとのブロック高の不一致だと疑われる場合、xpay は待機するようになりました。
ピアが消失したことによって支払いが失敗した場合、xpay が支払いパートの状態を pending のまま残してしまうことがありました。その結果、listpays や listsendpays に未完了の支払いとして表示されていました。この問題を修正し、アップグレード時に残っているものもあわせて修復します。
Phoenix クライアントへの支払いの信頼性が向上しました。HTLC の上限（Phoenix では 6）があるというフィードバックを受け、xpay は非公開ノードに対して maxparts を 6 に制限します。これにより、やむを得ない場合を除き、未知のチャネル経由で 6 個を超える HTLC を送信しようとしなくなります。

Enhancements?「お金データを見せてくれ！」

Postgres 派でも Sqlite3 派でも、すべてのデータベース、そしてあらゆる規模のノード向けに改善が入っています。説明するより、数字を見てもらう方が早いでしょう。

xpay は rpc_command に対してフィルタリングを行い、pay のときだけ呼び出されるようになりました。

時間（L2 ノードの開始から終了まで）：以前は 227 秒、現在はわずか 135 秒
最悪レイテンシ：以前は 62.4 秒、現在はわずか 12.1 秒

私たちは、読み取り専用の操作に対して明示的なトランザクションを作成しないようデータベースに指示しました。書き込みは私たちだけが行っているため、トランザクションは不要だからです。これにより、Postgres では約 30% の高速化が得られました。

これまでは常に処理前にトランザクションを開始していましたが、実際には不要なケースも存在します。そこでオンデマンド方式に切り替え、本当に必要な場合にのみデータベーストランザクションを開始するようにしました。これにより、Postgres ユーザーではレイテンシが 12% 以上削減されます。

Sql ユーザー向けには、chainmoves や channelmoves の取得件数を一度に制限しました。lightningd に 200 万件のエントリを要求した際に発生していたレイテンシスパイクを回避するためです。

最悪レイテンシ：以前は 4.5 秒、現在は 0.028 秒

lightningd も進化！

みんな大好きなデーモン、lightningd もいくつかの点で改善されています。

各コマンドが完了するたびに、すべてのコマンドをループ処理することをやめました。コマンド数が多い場合、これが処理時間の大半を占めていたためです。

時間（L2 ノードの開始から終了まで）：34 秒 → わずか 13 秒
最悪レイテンシ：24 秒 → わずか 4.0 秒！

大量のコマンド出力をよりスムーズに処理できるよう、lightningd にいくつかの変更を加えました。プロファイリングの結果、膨大な数の出力ストリームを扱う際に tal_arr_remove に処理時間のほとんどを費やしていることが判明しました。そこで、配列ではなく linked リストを使用するように変更しました。

時間（L2 ノードの開始から終了まで）：518 秒 → わずか 239 秒
最悪レイテンシ：353 秒 → 56.9 秒

さらに、lightningd がフック配列をフックリクエストにコピーする処理も廃止しました。これはスケールしなかったためです。縮小するのではなく、plugin_hook 内で配列を単純に NULL に設定する方式に切り替えました。

時間（L2 ノードの開始から終了まで）：85 秒 → わずか 34 秒
最悪レイテンシ：75 秒 → わずか 24 秒

ライトニングのように高速なネットワークを常に把握する

Lightning ノードは常に進化し続けています。これを管理するために、Core Lightning では networkevents サブシステムを用いて、ネットワークレベルの通知を一元管理しています。ネットワークが進化するのと同様に、私たちの改善も進化します。今回、このサブシステムを拡張し、ピアに関する情報（ping 時間や接続時間）へアクセスできるようにしました。

sql が networkevents テーブルをサポート
listnetworkevents から削除するための delnetworkevent を追加
wait が networkevents サブシステムに対応

私たちは境界を押し広げ、仕様書に静かに一礼しない限り cln ではあり得ません…

LSPS0 および LSPS1 への準拠に向けた、真に直線的な次の一歩として、LSPS2 に対応する experimental-lsps-client と experimental-lsps2-service のサポートを追加しました。
スプライスコミットメントに関する Bolt 仕様への準拠をさらに強化しています。今後はピア同士が同時にアップグレードする必要があります！
おっと！まだアナウンスされていないチャネルでスプライスを行った際にクラッシュしてしまう問題がありましたが、これを修正しました。
BOLT 12 の定期オファーに対応するため、Core Lightning は古い定期オファーを受け付けなくなります。利用開始時期を制限したい場合は expiry を使用する必要がありますが、expiry を指定する際は「月」ではなく「年」を使ってください！

私たちは今回のリリースを数日間延期しました。Blockstream のマネジメントに逆らったわけではありません。土壇場の第十一時間に、Rusty があの elusive な missing_utxo バグの真相を突き止めたからです。

[25.09] 以降に 3 つのポイントリリースがあったことに気づいた方もいるかもしれませんが、それには正当な理由があります。バグ修正と機能満載のアップデートに加え、**クラッシュの修正、リグレッションの解消、テスト体制の強化（CI の時間短縮を含む）**に多大な労力を注ぎ、よりスムーズで信頼性の高い結果を実現しました。