新たに提出されたバグ報告によると、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パーペチュアルの投げ売りはPre-IPO暗号資産投資への警鐘か？
バリデータアイデンティティはネットワーク合意の要
バリデータのアイデンティティは、XRPレジャーが各レジャーに合意する仕組みの中心に位置している。ノードの提案に重みが付くのは、他のサーバーがユニークノードリストを通じてそのキーを信頼している場合に限られるため、古い、あるいは不整合なアイデンティティは、そのマシンを検証しようとする誰かを混乱させかねない。ログが混乱していれば、その信頼プロセスを遅らせる要因ともなりうる。
現時点では、この不整合が原因の停止は発生していない。それでも、開発者たちが月半ばのリリース以降に指摘してきた一連の欠陥──同期失敗や設定パーサーのクラッシュなど──をさらに長引かせる結果となっている。
報告者は修正案も提示しており、サービスログにはサーバーが実際に使用しているキーを出力するか、導出キーと実際に稼働中のキーの両方を同時に表示するべきだと提案している。現時点では、まだどのメンテナーもこの報告にアサインされていない。これより前に提出された複数の報告については、既にバグとして確認されレビュー待ちキューに入っている一方、別の報告はコントリビューターが検討を続ける中でオープンのままとなっている。
採用は低迷、アメンドメント投票は継続中
新バージョンの導入ペースは鈍いままだ。公開ネットワークデータによると、現時点で約30%のノードがバージョン3.2.0を稼働させているものの、大半のオペレーターはいまだ旧バージョンである3.1.3ビルドを利用している。
ロールアウトが始まったのは6月15日で、このアップデートではコアソフトウェアの名称を rippled から xrpld に変更し、30〜40%のメモリ節約を約束していた。その後オペレーターからは、同期の途切れ、リレー計算の誤り、そして今回のキー不整合など、新ビルドに関する問題が報告されているが、これまでのところパッチは提供されていない。さらに、fixCleanup3_2_0 と呼ばれるクリーンアップ変更がバリデータによって承認されれば、旧バージョンのままのノードはアメンドメントブロック状態に陥るリスクもある。この変更については、進行中の投票の中で Ripple がすでに支持を表明している。