---
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/http-websocket-apis/build-apps/get-started.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)、特定のトランザクションを再生して、その結果を再現したり、他の可能性をテストする。

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

## 関連項目

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

{% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}