xrpl-dev-portal/content/concepts/networks-and-servers/rippled-server-modes.ja.md

html, parent, blurb, labels

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

rippledサーバーのモード

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

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

また、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の実行を参照してください。

レポートモード

[新規: rippled 1.7.0][]

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

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

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

スタンドアロンモード

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

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

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

関連項目

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

{% include '_snippets/rippled-api-links.md' %} {% include '_snippets/tx-type-links.md' %} {% include '_snippets/rippled_versions.md' %}