ローカルPCでDockerを使ってRippledサーバーを構築し、XRPL Testnetに接続する

ローカルPCでDockerを使ってRippledサーバーを構築し、XRPL Testnetに接続する手順 Docker
2025.06.09

XRPLプライベートネットワークをDockerで構築で、プライベートネットワーク上でrippledサーバーを構築してテスト送金まで行いましたが、外部環境との接続を確認したいために、今回は、XRPLのTestnetへの接続を試みました。

この記事では、Windows 11上でWSL2とDockerを使い、ローカルPCでRippledサーバーを稼働させてXRPLのTestnetに接続する方法を説明しています。
現時点では、XRPL Testnetへの接続まで確認できましたが、同期まで確認できおらず、問題判別中です。

ローカルPC上にRippledサーバーを構築する

Windows 11にDocker Desktopをインストール後、WSL2の環境にUbuntuをセットアップして、Dockerを使ってRippledサーバーを構築します。

全体の流れ

Windows 11でRippledサーバーを構築するには、主に以下の3つのステップを踏みます。

  1. Docker Desktopのインストール:
    まず、Windows 11にDocker Desktopというソフトウェアをインストールします。
    これは、アプリケーションを「コンテナ」という独立した環境で動かすためのツールです。
    参考リンク：WindowsにDocker Desktopをインストールする
  2. WSL2とUbuntuの準備:
    Docker Desktopは、その動作にWSL2 (Windows Subsystem for Linux 2)という技術を利用します。
    WSL2はWindows上でLinux環境を動かすためのもので、この中にUbuntuというLinuxディストリビューションをセットアップします。
    基本的に、Docker Desktopをインストールする過程でこれらは自動的に設定されます。
    参考リンク：WSL を使用して Windows に Linux をインストールする方法
  3. Rippledサーバーの構築:
    準備が整ったら、Dockerを使ってRippledサーバーを動かします。
    これにより、Rippledサーバーがコンテナとして隔離された環境で動作するため、Windowsのシステムに影響を与えることなく、安定してサーバーを運用できます。

要するに、Windows 11にDockerを導入し、その上でRippledサーバーを「コンテナ」として実行するという流れになります。

以下のRippledサーバーの構築手順に進む前に、参考リンクを参照して、Docker Desktopをインストールし、WSL2環境にUbuntuをセットアップしてください。

Rippledサーバーの構築

WSLのUbuntuターミナルを開き作業を行います。

Rippled Dockerイメージを入手する

$ docker pull xrpllabsofficial/xrpld:latest

latest: Pulling from xrpllabsofficial/xrpld
312dda0739a2: Pull complete
0ed828415ce4: Pull complete
d100128a81a6: Pull complete
4f4fb700ef54: Pull complete
Digest: sha256:1b636a71bccf7b08b3771db9c9c98d6e7f74d88ff4d88267b5d9b4afb3190d96
Status: Downloaded newer image for xrpllabsofficial/xrpld:latest
docker.io/xrpllabsofficial/xrpld:latest

Rippledの設定ファイルを準備する

最初に、作業ディレクトリを作成し移動します。

$ mkdir -p ~/xrpl/testnet && cd ~/xrpl/testnet

nanoエディタを使って、設定ファイル(rippled.cfg)を作成します。

#rippled.cfgの作成
$ nano rippled.cfg

#rippled.cfgの内容を確認
$ cat rippled.cfg
[server]
port_rpc

[port_rpc]
ip = 0.0.0.0
port = 5005
protocol = http

[ips]
s.altnet.rippletest.net 51235

[network_id]
testnet

[validator_list_sites]
https://vl.altnet.rippletest.net

[validators_file]
validators.txt

[node_size]
small

[node_db]
type=NuDB
path=/var/lib/rippled/db/nudb
online_delete=2000
advisory_delete=0

$ ls
rippled.cfg
rippled.cfg設定内容

以下をコピー&ペーストして使います。

[server]
port_rpc

[port_rpc]
ip = 0.0.0.0
port = 5005
protocol = http

[ips]
s.altnet.rippletest.net 51235

[network_id]
testnet

[validator_list_sites]
https://vl.altnet.rippletest.net

[validators_file]
validators.txt

[node_size]
small

[node_db]
type=NuDB
path=/var/lib/rippled/db/nudb
online_delete=2000
advisory_delete=0

rippled.cfg内容の解説

[server] セクション
port_rpc
Rippled の RPC（Remote Procedure Call）サーバー機能を有効化します。
以降の [port_rpc] セクションでポート番号やプロトコル等を指定できるようになります。

[port_rpc] セクション
RPC インターフェイスの詳細設定をまとめる箇所です。
ip = 0.0.0.0
RPC サーバーがバインド（待ち受け）する IP アドレスを指定。
0.0.0.0 は「全てのネットワークインターフェイス」で待ち受け、ローカル PC 上のどのアドレス宛でもアクセスを受け付けます。
port = 5005
RPC リクエストを受け取る TCP ポート番号。
デフォルトでは 5005 を使うことが多く、curl や外部プログラムから http://<ホスト>:5005 でアクセスします。

protocol = http
RPC 通信に利用するプロトコル。
http の他に証明書を使った https を指定することも可能ですが、ローカル開発用途では http で十分です。

[ips] セクション
ピアノード（接続先ノード）のアドレスを列挙します。
s.altnet.rippletest.net 51235
Testnet のブートストラップノード（最初に接続して台帳情報を取得するノード）のホスト名と接続ポート。
これを足がかりに Testnet の他ノードとピア接続を確立し、台帳同期を行います。

[network_id] セクション
testnet
ノードを接続するネットワーク種別を指定します。
mainnet （本番）、testnet（テスト環境）、devnet（開発者向け）などがあり、ここでは Testnet を指定しています。

[validator_list_sites] セクション
https://vl.altnet.rippletest.net
信頼可能なバリデータ一覧（validator list）をホストするサイトの URL。
定期的にこの URL を参照し、最新のバリデータセットを取得して「どのバリデータを信頼して合意形成に参加するか」を制御します。

[validators_file] セクション
validators.txt
上記サイトからダウンロードしたバリデータ一覧をローカルに保存するファイル名。
ファイルが存在すると優先的にこちらを読み込み、リモートフェッチを減らせます。

[node_size] セクション
small
ノードの“規模”を示す設定で、内部的なキャッシュサイズやリソース使用量を調整します。
small, medium, large の３段階があり、開発／テスト用途なら small が推奨されます。

[node_db] セクション
ノードが利用する台帳データベースの種類と管理方針を設定します。
type=NuDB
データベースエンジンとして「NuDB」を利用する指定。
高速かつディスク利用に最適化されたキー・バリュー型ストレージです。
path=/var/lib/rippled/db/nudb
NuDB のデータファイルを保存するディレクトリパス。
コンテナ内の標準パスですが、必要に応じてホスト側へマウントして永続化できます。
online_delete=2000
ノード起動中に、確定済み（古い）台帳を自動的に削除する「最大保持数」を指定。
2000 なら最新の2000台帳だけを保持し、それ以前は不要と判断して削除します。
advisory_delete=0
オンライン時に削除可能な古い台帳の閾値。
0 は「オンライン削除は行わない」ことを意味します。
台帳保持に関して細かく制御したい場合に調整します。

DockerでRippledコンテナを起動する

以下のコマンド入力し、コンテナを起動する。

docker run -d \
  --name xrpl-testnet \
  -p 5005:5005 \
  -v ~/xrpl/testnet/rippled.cfg:/etc/opt/ripple/rippled.cfg \
  xrpllabsofficial/xrpld:latest
  • -d：バックグラウンドで起動
  • --name xrpl-testnet：コンテナ名
  • -p 5005:5005：RPCポートの公開
  • -v ~/xrpl/testnet/rippled.cfg:/etc/opt/ripple/rippled.cfg：設定ファイルのマウント

以下は、Ubuntuターミナル画面。

#コンテナの起動
$ docker run -d \
  --name xrpl-testnet \
  -p 5005:5005 \
  -v ~/xrpl/testnet/rippled.cfg:/etc/opt/ripple/rippled.cfg \
  xrpllabsofficial/xrpld:latest
87a0e91e35415b136e0fed4582f9142b3a8c07914ce033f381f4db737fdcc263

コンテナの起動確認を行う

#コンテナの起動確認
$ docker ps -a
CONTAINER ID   IMAGE                           COMMAND            CREATED          STATUS          PORTS                                                          NAMES
87a0e91e3541   xrpllabsofficial/xrpld:latest   "/entrypoint.sh"   58 seconds ago   Up 58 seconds   80/tcp, 443/tcp, 6006/tcp, 51235/tcp, 0.0.0.0:5005->5005/tcp   xrpl-testnet

Rippledサーバーへのアクセス確認

curlを用いて以下のコマンドを入力してRPCへのアクセスを確認します。

curl -X POST \
  -H 'Content-Type: application/json' \
  -d '{"method":"server_info"}' \
  http://localhost:5005

レスポンスの成功例

{
  "result": {
    "info": {
      "build_version": "...",
      "complete_ledgers": "...",
      "server_state": "full",
      "validated_ledger": {
        "age": 3,
        "base_fee_xrp": 1e-05,
        "ledger_hash": "...",
        "ledger_index": "...",
        "reserve_base_xrp": 20,
        "reserve_inc_xrp": 5,
        "seq": ...
      }
    },
    "status": "success"
  }
}

以下は、実際のUbuntuターミナル画面。

#Rippledサーバーへのアクセス確認

$ curl -X POST \
  -H 'Content-Type: application/json' \
  -d '{"method":"server_info"}' \
  http://localhost:5005
{"result":{"info":{"build_version":"2.4.0","closed_ledger":{"age":26,"base_fee_xrp":1e-05,"hash":"55F85B193A7F86245B0DE3B17F7EE3EAB32A49CD3D292E147EA00D258DABCCE0","reserve_base_xrp":10,"reserve_inc_xrp":2,"seq":69},"complete_ledgers":"empty","fetch_pack":536,"hostid":"SURF","io_latency_ms":1,"jq_trans_overflow":"0","last_close":{"converge_time_s":15.007,"proposers":0},"load_factor":1,"network_id":1,"peer_disconnects":"2","peer_disconnects_resources":"0","peers":1,"ports":[{"port":"5005","protocol":["http"]}],"pubkey_node":"n9JmrsFnAUVxic8yYoKcU2qcMAyNrw3uLvHexj1pLjKHztNgh3bZ","published_ledger":"none","server_state":"connected","server_state_duration_us":"129478167","state_accounting":{"connected":{"duration_us":"1330816495","transitions":"4"},"disconnected":{"duration_us":"121148709","transitions":"4"},"full":{"duration_us":"0","transitions":"0"},"syncing":{"duration_us":"0","transitions":"0"},"tracking":{"duration_us":"0","transitions":"0"}},"time":"2025-Jun-08 20:50:06.808097 UTC","uptime":1465,"validation_quorum":28},"status":"success"}}

XRPL Testnetとの同期確認

以下のコマンドで、Rippledサーバーの状態を確認する。

curl -X POST http://localhost:5005 \
-H 'Content-Type: application/json' \
-d '{"method":"server_info","params":[{}]}'

レスポンス例（server_info (rippled)）

{
  "result": {
    "info": {
      "build_version": "1.12.0", // Rippledサーバーのバージョン
      "complete_ledgers": "32570-82521701", // サーバーが保持しているレジャーの範囲
      "hostid": "LEST", // ホストのID（サーバー名など）
      "initial_sync_duration_us": "190181187", // 初回同期にかかった時間（マイクロ秒）
      "io_latency_ms": 1, // I/Oレイテンシ（ミリ秒）
      "jq_trans_overflow": "0", // 処理待ちトランザクションのオーバーフロー回数
      "last_close": { // 最後にレジャーがクローズされた情報
        "converge_time_s": 3.001, // 収束にかかった時間（秒）
        "proposers": 35 // プロポーザの数
      },
      "load_factor": 1, // 現在の負荷係数
      "network_id": 0, // ネットワークID
      "peer_disconnects": "4", // ピアとの切断回数
      "peers": 42, // 接続されているピアの数
      "server_state": "full", // サーバーの現在の状態 (e.g., "full", "syncing", "tracking")
      "state_accounting": { // サーバーの状態遷移に関する統計
        "connected": {
          "duration_us": "10000000",
          "transitions": 1
        },
        "full": {
          "duration_us": "50000000",
          "transitions": 1
        }
      },
      "uptime": 86400, // サーバーの稼働時間（秒）
      "validated_ledger": { // 最新の検証済みレジャーの情報
        "age": 3, // レジャーがクローズされてからの時間（秒）
        "base_fee_xrp": 0.00001, // 基本手数料（XRP）
        "hash": "DF8467D2B9F4C0D4A8E0A0C0A0A0C0A0A0C0A0A0C0A0A0C0A0A0C0A0A0C0A0A0", // レジャーのハッシュ
        "reserve_base_xrp": 20, // アカウントの最低準備金（XRP）
        "reserve_inc_xrp": 5, // オブジェクトごとに増える準備金（XRP）
        "seq": 82521701 // レジャーシーケンス番号
      },
      "validation_quorum": 25 // 検証クォーラム
    }
  },
  "status": "success",
  "type": "response"
}
同期の進行状況確認

Server State の値と意味
正常な順序ではdisconnected → connected → syncing → tracking → fullの順で進行します。

disconnected（切断状態）
オフラインモードで動作中、またはネットワークアクセスができない状態
サーバーがXRP Ledgerのピアツーピアネットワークに接続されていない
connected（接続状態）
ピアツーピアネットワークと通信できるが、共有レジャー状態を追跡するのに十分なデータをまだ持っていない
サーバーがネットワークに接続されていると認識している状態
syncing（同期中）
通常、起動後にレジャーの状態に同期するまで約5-15分かかる
サーバーが現在レジャーバージョンで遅れている状態
tracking（追跡中）
ネットワークの現在状態に追いついている
サーバーがネットワークと合意している状態
full（完全状態）
バリデーターとして設定されていない可能性
サーバーがネットワークと完全に同期しており、バリデーションに参加できるが、実際には参加していない状態
validating（バリデーション中）
サーバーが現在レジャーのバリデーションに参加している状態
proposing（提案中）
サーバーがレジャーのバリデーションに参加し、現在独自のバージョンを提案している状態

以下は、実際のUbuntuターミナル画面。

$ curl -X POST http://localhost:5005 -H 'Content-Type: application/json' -d '{"method":"server_info","params":[{}]}'

{"result":{"info":{"build_version":"2.4.0","closed_ledger":{"age":23,"base_fee_xrp":1e-05,"hash":"F236E8031F63FE232E92A6CF712224264E66D69D57B9E909F9CE2F34EE45126A","reserve_base_xrp":10,"reserve_inc_xrp":2,"seq":9},"complete_ledgers":"empty","fetch_pack":266,"hostid":"SURF","io_latency_ms":1,"jq_trans_overflow":"0","last_close":{"converge_time_s":15.003,"proposers":0},"load_factor":1,"network_id":1,"peer_disconnects":"0","peer_disconnects_resources":"0","peers":1,"ports":[{"port":"5005","protocol":["http"]}],"pubkey_node":"n9JmrsFnAUVxic8yYoKcU2qcMAyNrw3uLvHexj1pLjKHztNgh3bZ","published_ledger":"none","server_state":"connected","server_state_duration_us":"156462390","state_accounting":{"connected":{"duration_us":"157462914","transitions":"2"},"disconnected":{"duration_us":"1104369","transitions":"2"},"full":{"duration_us":"0","transitions":"0"},"syncing":{"duration_us":"0","transitions":"0"},"tracking":{"duration_us":"0","transitions":"0"}},"time":"2025-Jun-08 23:11:03.172224 UTC","uptime":159,"validation_quorum":28},"status":"success"}}

実際には、長時間待っても、server_stateがconnectedのままで、XRPL Testnetへの同期は確認できませんでした。

リップルの問題診断

Diagnosing Problems with rippledで、問題を判別します。

サーバーがconnected数時間にわたってこの状態のままであったり、または
connected状態から元の状態に戻ったりする場合は、通常、サーバーがネットワークの他の部分に対応できていないことを示しています。
最も一般的なボトルネックは、ディスクI/O、ネットワーク帯域幅、およびRAMです。

システム要件

Recommended Specificationsを参照。

最小仕様
テスト目的で、次の最小要件を満たす市販ハードウェア上で XRP Ledger サーバーを実行できます。RAM: 16 GB以上。
オペレーティング システム: macOS、Windows (64 ビット)、またはほとんどの Linux ディストリビューション (Red Hat、Ubuntu、Debian をサポート)。
CPU: 64 ビット x86_64、4 コア以上。
ディスク：SSD / NVMe（持続10,000 IOPS以上 – バーストやピーク時を除く）。
データベースパーティション用に最低50GB。
Amazon Elastic Block Store（AWS EBS）はレイテンシが高すぎて安定した同期が不可能なため、使用しないでください。

タイトルとURLをコピーしました