新たに提出されたバグ報告によると、リブランディングされた XRP Ledger のv3.2.0ソフトウェアで、約30%のノードが新サーバーを採用する中、実際には別のバリデータキーで稼働しているにもかかわらず、ログには別のキーが記録されることが判明した。
重要ポイント:
- あるノードオペレーターは、v3.2.0が移行済みバリデータの新しいキーをログに出力する一方で、サーバー自体は古いキーで動作し続けていると報告した。
- この不具合は、既存のバリデータトークンを稼働中のRPCノードに追加した際、Ubuntu 22.04上で発生するようだ。
- アップグレードの採用率は約30%にとどまり、大半のオペレーターは依然として以前のビルドを利用している。
XRPレジャーのバグがキー不一致を露呈
この欠陥は、プロジェクトのGitHubトラッカー上の issue #7581 として 提出 されたもので、オペレーターが既存のバリデータをすでに稼働しているRPCノードへ移行し、その後サービスを再起動した際に発生する。サービスログには移行済みバリデータの新しいアイデンティティが記録される一方、server_info エンドポイントはローカルの wallet.db ファイル内にある古いキーを返し続ける。両者の情報が一致しなくなる形だ。
この分裂状態の再現はさほど難しくないという。オペレーターによれば、既存のバリデータトークンを稼働中のノードに追加し、サーバーを再起動するだけでUbuntu 22.04上では再現でき、これは日常的なマイグレーション手順としてよくある流れだ。
関連記事: Anthropicパーペチュアルの売り浴びせは、プレIPO暗号投資への警告か？
バリデータのアイデンティティはネットワーク合意の要
バリデータのアイデンティティは、XRPレジャーが新しいレジャーごとに合意を形成する仕組みの中核にある。ノードの提案に重みが付くのは、他のサーバーがユニークノードリストを通じてそのキーを信頼している場合に限られるため、古くなったアイデンティティや不一致は、そのマシンを確認する人々を混乱させかねない。ログ情報が混乱していれば、その信頼形成にも時間がかかる。
これまでのところ、この不一致が停止や障害を引き起こした例はない。それでも、開発者たちが月半ばのリリース以降に 指摘してきた 一連の欠陥（同期失敗や設定パーサーのクラッシュなど）をさらに延長する形となっている。
報告者は修正案として、サービスログにはサーバーが実際に使用しているキーを出力するか、導出されたキーと実際にアクティブなキーを併記するよう求めている。現時点でこの報告にはメンテナーはまだ割り当てられていない。これ以前の複数の報告はすでにバグとして確認されレビュー待ちのキューに入っている一方で、他の報告はコントリビューター同士の検討が続く中でオープンのままとなっている。
採用は鈍く、修正アメンドメントの投票が継続
リリースの普及ペースは鈍いままだ。公開ネットワークデータによると、約30%のノードが現在バージョン3.2.0を 稼働 させているものの、大半のオペレーターは以前の3.1.3ビルドを使い続けている。
ロールアウトは6月15日に始まり、このアップデートでコアソフトウェアの名称は rippled から xrpld に変更され、メモリ使用量を30〜40%削減すると約束された。それ以降、オペレーターからは同期の途切れ、リレー計算の誤り、そして今回のキー不一致などが新ビルドで報告されているが、これまでのところパッチは提供されていない。さらに、fixCleanup3_2_0 というクリーンアップ用のアメンドメントがバリデータにより承認されれば、旧バージョンを使い続けるノードはアメンドメントによりブロックされた状態に陥るリスクもある。この変更には、進行中の投票の中で Ripple もすでに支持を表明している。