---
html: rippled-server-modes.html
parent: networks-and-servers.html
seo:
    description: ストックサーバー、バリデータサーバー、スタンドアロンモードで運用されるrippledサーバーなど、rippledサーバーのモードについて説明します。
labels:
  - コアサーバー
---
# rippledサーバーのモード

`rippled`サーバーソフトウェアは、その設定に応じて以下のようなさまざまなモードで実行できます。

- [**P2Pモード**](#p2pモード) - ピアツーピアネットワークをフォローし、トランザクションを処理し、ある程度の[レジャー履歴](ledger-history.md)を維持します。このモードは、以下の役割のいずれか、またはすべてを行うように設定することができます。
    - [**バリデータ**](#バリデータ) - コンセンサスに参加することで、ネットワークの安全確保に貢献します。
    - [**APIサーバー**](#apiサーバー) - 共有レジャーからデータを読み込んだり、トランザクションを送信したり、レジャーのアクティビティを監視するための[APIアクセス](../../tutorials/get-started/get-started-using-http-websocket-apis.md)を提供します。オプションとして、トランザクションやレジャーの履歴を完全に記録する [**全履歴サーバー**](#全履歴サーバー) とすることができます。
    - [**ハブサーバー**](#公開ハブ) - ピアツーピアネットワークの他の多くのメンバー間のメッセージを中継します。
- [**レポートモード**](#レポートモード) - リレーショナルデータベースからのAPIリクエストに対応するための専用モードです。ピアツーピアネットワークには参加しないため、P2Pモードサーバーを実行し、信頼できるgRPC接続を使用してレポートモードサーバーに接続する必要があります。 {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.7.0" %}新規: rippled 1.7.0{% /badge %}
- [**スタンドアロンモード**](#スタンドアロンモード) - テスト用のオフラインモードです。ピアツーピアネットワークに接続せず、コンセンサスも使用しません。

また、[`rippled` API](../../references/http-websocket-apis/index.md)にローカルでアクセスするためのクライアントアプリケーションとして、`rippled`実行可能ファイルを実行できます。（この場合同じバイナリの2つのインスタンスを並列して実行できます。1つのインスタンスをサーバーとして実行し、もう1つのインスタンスをクライアントとして一時的に実行して終了します。）

各モードで`rippled`を実行するためのコマンドについては、[rippledコマンドライン使用リファレンス](../../infrastructure/commandline-usage.md)を参照してください。


## P2Pモード

P2Pモードは`rippled`サーバーのメインかつデフォルトのモードで、サーバーが行うべきほぼ全てのことを処理することができます。これらのサーバーは、トランザクションを処理し、XRP Ledgerの共有状態を維持するピアツーピア・ネットワークを形成しています。トランザクションを送信したり、レジャーデータを読んだり、その他ネットワークに参加したい場合、リクエストはどこかでP2Pモードのサーバーを経由しなければなりません。

P2Pモードのサーバーは、追加機能を提供するためにさらに細かく設定することができます。P2Pモードで動作し、設定ファイルを最小限に変更したサーバーは、_ストックサーバー_ とも呼ばれます。その他の構成は以下の通りです。

- [バリデータ](#バリデータ)
- [APIサーバー](#apiサーバー)
- [公開ハブ](#公開ハブ)

P2Pモードのサーバーは、デフォルトで[Mainnet](parallel-networks.md)に接続します。

### APIサーバー

全てのP2Pモードサーバーは、トランザクションの送信、残高や設定の確認、サーバーの管理などの目的で、[API](../../references/http-websocket-apis/index.md)を提供しています。もしあなたがXRP Ledgerにデータを照会したり、ビジネス用途でトランザクションを送信するのであれば、[独自サーバーを運営する](index.md#独自サーバーを運用する理由)ことが有効でしょう。

#### 全履歴サーバー

他のいくつかのブロックチェーンとは異なり、XRP Ledgerは、現在のステートの把握や新しいトランザクションの処理のために、サーバーが完全なトランザクション履歴を持つことを必要としません。サーバーの運用者は、一度にどれだけの[レジャー履歴](ledger-history.md)を保存するかを決めることができます。ただし、P2PモードサーバーがAPIリクエストに答えられるのは、ローカルで利用可能なレジャー履歴のみです。例えば、6ヶ月分の履歴を保存している場合、サーバーは1年前のトランザクションの結果を示すことはできません。[すべての履歴](ledger-history.md#すべての履歴)を持つAPIサーバーは、XRP Ledgerの開始以降のすべてのトランザクションと残高を報告できます。

### 公開ハブ

公開ハブは、他のサーバーへの[ピアプロトコル接続](peer-protocol.md)が多数あるストックサーバーを指します。ストックサーバーを _公開ハブ_ として実行することで、XRP Ledgerネットワークの効率的な接続を維持できます。適切に運用されている公開ハブには、以下の特徴があります。

- 十分な帯域幅。

- 多数の信頼できるピアとの接続。

- メッセージを確実に中継する能力。

サーバーをハブとして設定するには、許可される最大ピア数を増やし、ファイアウォールやNAT（ネットワークアドレス変換）ルーターで[適切なポートを転送](../../infrastructure/configuration/peering/forward-ports-for-peering.md)していることを確認する必要があります。

## バリデータ

XRP Ledgerの堅牢性は、他のバリデータが共謀しないことをそれぞれが信頼している、相互接続されたバリデータのネットワークに依存しています。他のP2Pモードサーバーと同様に、各トランザクションを処理し、レジャーの状態を計算することに加え、バリデータは[コンセンサスプロトコル](../consensus-protocol/index.md)に積極的に参加しています。もしあなたやあなたの組織がXRP Ledgerにアクセスするのであれば、バリデータとして1台のサーバーを稼働させ、コンセンサスプロセスに貢献することが望ましいでしょう。

バリデーションはわずかな計算資源しか使用しませんが、1つの組織や団体が複数のバリデータを運用しても、共謀に対する保護が強化されるわけではないので、あまりメリットはないでしょう。各バリデータは一意の暗号鍵ペアで識別されるので、慎重に管理しなければいけません。複数のバリデータが鍵ペアを共有してはいけません。このような理由から、バリデーションはデフォルトで無効になっています。

他の目的にも使用されているサーバーで、安全にバリデーションを有効にすることができます。このような構成は _汎用サーバー_ と呼ばれます。あるいは、他のタスクを実行しない _専用バリデータ_ を、P2Pモードの他の`rippled`サーバーと一緒に[クラスタ](clustering.md)で実行することもできます。

バリデータの実行についての詳細は、[バリデータとしての`rippled`の実行](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md)を参照してください。



## レポートモード
{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.7.0" %}新規: rippled 1.7.0{% /badge %}

レポートモードは、APIリクエストをより効率的に処理するために特化したモードです。このモードでは、サーバーは[gRPC](../../infrastructure/configuration/configure-grpc.md)を介して、P2Pモードで動作する別の`rippled`サーバーから最新の検証済みレジャーデータを取得し、そのデータをリレーショナルデータベース([PostgreSQL](https://www.postgresql.org/))にロードします。レポートモードサーバはピアツーピアネットワークに直接参加しませんが、トランザクションの送信などのリクエストを、使用しているP2Pモードサーバに転送することはできます。

複数のレポートモードサーバーは、PostgreSQLデータベースと[Apache Cassandra](https://cassandra.apache.org/)クラスタへのアクセスを共有し、各サーバーがすべてのデータの冗長コピーを必要とせずに大量の履歴を提供できます。レポートモードサーバは、基礎となるデータの保存方法の違いに対応するため、若干の変更を加えた同じ[`rippled` API](../../references/http-websocket-apis/index.md)を使ってこのデータを提供します。

最も注目すべきは、レポートモードのサーバーは、保留中や未検証のレジャーデータまたはトランザクションをレポートしないことです。この制限は、[分散型取引所](../tokens/decentralized-exchange/index.md)での裁定取引の実行など、流動的なデータへの迅速なアクセスに依存する特定の使用事例に関連しています。


## スタンドアロンモード

スタンドアロンモードでは、サーバーはネットワークに接続せず、コンセンサスプロセスにも参加せずに動作します。コンセンサスプロセスがなければ、手動で台帳を進める必要があり、「closedレジャー」と「validatedレジャー」の区別はありません。しかし、サーバーは依然としてAPIアクセスを提供し、トランザクションを同じように処理します。これにより、以下のことが可能になります。

- 分散型ネットワーク上でAmendmentsが有効になる前に、[Amendmentsの影響をテストする](../../infrastructure/testing-and-auditing/test-amendments.md)。
- [新しいジェネシスレジャー](../../infrastructure/testing-and-auditing/start-a-new-genesis-ledger-in-stand-alone-mode.md)を最初から作成する。
- ディスクから[既存のレジャーバージョンを読み込み](../../infrastructure/testing-and-auditing/load-a-saved-ledger-in-stand-alone-mode.md)、特定のトランザクションを再生して、その結果を再現したり、他の可能性をテストする。

**注意:** スタンドアロンモードでは[レジャーを手動で進める](../../infrastructure/testing-and-auditing/advance-the-ledger-in-stand-alone-mode.md)必要があります。

## 関連項目

- **チュートリアル:**
  - [`rippled`の構成](../../infrastructure/configuration/index.md)
  - [スタンドアロンモードでのrippledの使用](../../infrastructure/testing-and-auditing/index.md)

{% raw-partial file="/_snippets/common-links.md" /%}