本記事は2025年9月18日投稿のXRPL公式ブログ"Default UNL Migration“の和訳です。
以前お知らせしたとおり、XRP Ledgerの運営は新しいXRPLファウンデーションへ移行しています。 この移行の一環として、XRP LedgerサーバーのデフォルトUNLの配信元URLが新しくなり、新しい鍵ペアで署名されるようになりました。 XRP Ledgerメインネット上でサーバーを運用していて、デフォルトUNLを使用している皆さんは、サービスを継続するため、旧UNLパブリッシャーが停止される2025年9月30日までに、新しいUNL設定への移行が必要となります。
背景
XRP Ledgerのコンセンサスプロセスの一環として、各サーバーには Unique Node List (UNL) が設定されます。 UNLは、互いに結託しないと信頼できるバリデーターの集合です。 ネットワークに必要な安全性を維持しつつ、UNL内のバリデーターのオーバーラップ(重複)と独立性のバランスを取るため、XRP Ledger Foundationは、十分に審査され、国・データセンターなどが多様な独立したノード運用者で構成されるデフォルトUNL (dUNL) を公開しています。 ノード運用者がXRP Ledgerに同期し続けるためにdUNLを使うことは必須ではありませんが、信頼すべきバリデーター集合として、もっとも安全で信頼できる選択肢として広く推奨されています。 dUNLの完全性を保証するため、dUNLはXRP Ledger Foundationが管理する暗号鍵ペアで署名されています。
旧XRP Ledger Foundationから新Foundationへの移行の一環として、新Foundationは新しいURLから新しい鍵ペアでデフォルトUNLの公開を開始しました。 旧Foundationは新たなdUNLの更新を行わなくなっており、旧dUNLを配信していたURLは今月末、2025年9月30日に停止される予定です。
必要な対応
旧dUNLを使用しているノード(rippledのようなコアXRPLサーバー)を運用されている場合は、設定を新しい鍵ペアとURLに更新する必要があります。 これは、XRP Ledger Mainnetに接続しているサーバーのうち、rippled 2.3.x 以下からアップグレードしてきたほとんどのサーバーが該当します。rippledバージョン 2.4.0 以上で新規インストールを行い、新しい設定ファイルを使っている場合は、設定ファイルにすでに新Foundationの鍵とURLが含まれているはずなので、更新は不要です。
警告 通常のパッケージインストールでは既存の設定ファイルが上書きされません。 そのため、サーバーソフトウェアをアップグレードしていても、古いバージョンで作成された設定ファイルを引き継いでいる場合は、以下の手順での対応が必要です。
このプロセスは2つのステップで構成されます。
- サーバーの
validators.txtファイルを編集します。 このファイルは通常/etc/opt/ripple/validators.txtにあります。 構成によっては、$HOME/.config/ripple/validators.txt($HOMEはrippledを実行しているユーザーのホームディレクトリ)、$HOME/.local/ripple/validators.txt、もしくはrippledサーバーを起動した際のカレントディレクトリにある場合もあります。 設定ファイルの[validator_list_keys]および[validator_list_sites]セクションを更新し、旧Foundationの鍵とURLを削除して、新Foundationの鍵とURLを追加します。具体的には次の表のとおりです。
[validator_list_sites]内のURL |
[validator_list_keys]内の鍵 |
|
|---|---|---|
| 旧(削除) | https://vl.xrplf.org |
ED45D1840EE724BE327ABE9146503D5848EFD5F38B6D5FEDE71E80ACCE5E6E738B |
| 新(追加) | https://unl.xrplf.org |
ED42AEC58B701EEBB77356FFFEC26F83C1F0407263530F068C7C73D392C7E06FD1 |
vl.ripple.comなど、その他のバリデーターパブリッシャーの鍵とURLは、そのままで構いません。
URLは、TLS証明書に問題がある場合に備えて、暗号化されていないhttp://を使うこともできます。 バリデーターリストの中身は上記の鍵によって暗号学的に署名されているため、内容の完全性を保証するうえでSSL/TLSは厳密には必須ではありません。
- サーバーを再起動します。
sudo systemctl restart rippled.service
- 新しい設定を確認します。
再起動後、
validators管理コマンドを使って新しい設定を確認できます。
/opt/ripple/bin/rippled validators
デフォルト以外の構成を使用している場合は、必要に応じてrippled実行ファイルへのパスを変更してください。
レスポンスのpublisher_listsキーに、更新後の値が表示されるはずです。 新しいリストは2026年2月13日 (2026-02-13) を有効期限として利用可能になります。 例(レスポンスは長さの都合で省略しています):
{
"result": {
"local_static_keys": [],
"publisher_lists": [
{
"available": true,
"expiration": "2026-Feb-13 14:15:03.000000000 UTC",
...
"list": [
...
],
"pubkey_publisher": "ED42AEC58B701EEBB77356FFFEC26F83C1F0407263530F068C7C73D392C7E06FD1",
"seq": 1,
"uri": "https://unl.xrplf.org",
"version": 1
},
...
]
...
}
詳細情報やトラブルシューティングについては、新UNLを利用するための設定ガイダンス(rippled GitHubのディスカッション)をご覧ください。
設定を更新しなかった場合の影響
新しい設定に変更しないままにしていると、旧URLが停止される2025年9月30日にノードがXRPLファウンデーションの信頼済みバリデーターリストの読み込みを停止する可能性があり、ノードに設定されているUNLは2026年1月18日 (2026-01-18) に有効期限を迎えます。 リストの有効期限切れ後はサーバーがネットワークと同期できなくなりますが、他の要因によっては早ければ2025年9月30日の時点で同期を失う可能性もあります。
[validator_list_threshold]を設定している場合、バリデーターは設定された複数のリストのうち過半数に含まれている場合にのみ信頼されます。 他のリストの変更状況によっては、サーバーがネットワークの他のノードとコンセンサスを形成するために必要な数のバリデーターを信頼できなくなる可能性があります。- サーバーがXRPLファウンデーションのリストにのみ依存しており、旧リストをキャッシュしていない場合、起動時にネットワークと同期するための信頼済みバリデーター集合を決定できなくなる可能性があります。
ログメッセージ
サーバーログに次のようなメッセージが表示されることがあります。
WRN:Ignored 1 stale validator list(s) from https://vl.ripple.com
WRN:Ignored 1 untrusted validator list(s) from https://unl.ripple.com
新しい鍵とサイトで設定を更新すれば、これらのログメッセージは止まるか減少するはずです。
バリデーターがfull状態のままになる
サーバー状態がproposingにならずfullのままになっているバリデーターがある場合、それは設定が適切に更新されていない兆候である可能性があります。 この場合、server_infoコマンドのレスポンスで、validation quorumの値が極端に大きく表示されます。
"validation_quorum": 4294967295,
新しい鍵とサイトで設定を更新すれば、この問題は解消されるはずです。
次のステップ
詳細情報やトラブルシューティングについては、新UNLを利用するための設定ガイダンス(rippled GitHubのディスカッション)をご覧ください。
