rippledサーバのモード

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

• P2Pモード - ピアツーピアネットワークをフォローし、トランザクションを処理し、ある程度のレジャー履歴を維持します。このモードは、以下の役割のいずれか、またはすべてを行うように設定することができます。
  • バリデータ - コンセンサスに参加することで、ネットワークの安全確保に貢献します。
  • APIサーバ - 共有レジャーからデータを読み込んだり、トランザクションを送信したり、レジャーのアクティビティを監視するためのAPIアクセスを提供します。オプションとして、トランザクションやレジャーの履歴を完全に記録する 全履歴サーバ とすることができます。
  • ハブサーバ - ピアツーピアネットワークの他の多くのメンバー間のメッセージを中継します。
• レポートモード - リレーショナルデータベースからのAPIリクエストに対応するための専用モードです。ピアツーピアネットワークには参加しないため、P2Pモードサーバを実行し、信頼できるgRPC接続を使用してレポートモードサーバに接続する必要があります。
• スタンドアロンモード - テスト用のオフラインモードです。ピアツーピアネットワークに接続せず、コンセンサスも使用しません。

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

各モードでrippledを実行するためのコマンドについては、rippledコマンドライン使用リファレンスをご覧ください。

P2Pモード

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

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

• バリデータ
• APIサーバ
• 公開ハブ

P2Pモードのサーバは、デフォルトでMainnetに接続します。

APIサーバ

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

全履歴サーバ

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

公開ハブ

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

• 十分な帯域幅。

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

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

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

バリデータ

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

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

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

バリデータの実行についての詳細は、バリデータとしてのrippledの実行をご覧ください。

レポートモード

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

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

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

スタンドアロンモード

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

• 分散型ネットワーク上でAmendmentsが有効になる前に、Amendmentsの影響をテストする。
• 新しいジェネシスレジャーを最初から作成する。
• ディスクから既存のレジャーバージョンを読み込み、特定のトランザクションを再生して、その結果を再現したり、他の可能性をテストする。

注意: スタンドアロンモードではレジャーを手動で進める必要があります。

関連項目

• チュートリアル:
  • rippledの構成
  • スタンドアロンモードでのrippledの使用