mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-20 11:45:50 +00:00
Merge pull request #1830 from develoQ/ja-servers
[JA] concept XRP Ledger Servers
This commit is contained in:
Rome Reginelli
@@ -17,7 +17,7 @@ Amendmentが有効になると、そのAmendmentが含まれているバージ
|
||||
|
||||
## 背景
|
||||
|
||||
トランザクション処理に変更があると、サーバーで同じトランザクションのセットを使用して別のレジャーが作成される場合があります。一部の _バリデータ_ （[コンセンサスに参加している](rippled-server-modes.html#バリデータを運用する理由)`rippled`サーバー）が古いバージョンのソフトウェアを使用している状態で、他のバリデータが新しいバージョンのソフトウェアにアップグレードすると、ごく小さな問題から、場合によっては完全機能停止などの問題が生じる可能性があります。希なケースでは、少数のサーバーにおいて、実際のコンセンサスレジャーを取得するために、より多くの時間と帯域幅が使用される場合があります。既知のトランザクションの処理ルールを使ってレジャーを構築できないためです。最悪の場合、異なるルールを使用するサーバー間で当該レジャーについてコンセンサスに達することができないため、[コンセンサスプロセス][]により新しいレジャーバージョンを検証できない可能性があります。
|
||||
トランザクション処理に変更があると、サーバーで同じトランザクションのセットを使用して別のレジャーが作成される場合があります。一部の _バリデータ_ （[コンセンサスに参加している](rippled-server-modes.html#バリデータ)`rippled`サーバー）が古いバージョンのソフトウェアを使用している状態で、他のバリデータが新しいバージョンのソフトウェアにアップグレードすると、ごく小さな問題から、場合によっては完全機能停止などの問題が生じる可能性があります。希なケースでは、少数のサーバーにおいて、実際のコンセンサスレジャーを取得するために、より多くの時間と帯域幅が使用される場合があります。既知のトランザクションの処理ルールを使ってレジャーを構築できないためです。最悪の場合、異なるルールを使用するサーバー間で当該レジャーについてコンセンサスに達することができないため、[コンセンサスプロセス][]により新しいレジャーバージョンを検証できない可能性があります。
|
||||
|
||||
Amendmentはこの問題を解決し、十分なバリデータがそれらの機能をサポートしている場合にのみ新しい機能を有効にします。
|
||||
|
||||
@@ -228,7 +228,7 @@ Amendment blockedは、XRP Ledgerに依存するアプリケーションを保
|
||||
|
||||
Amendmentが有効になっている場合の`rippled`の動作を確認するには、そのAmendmentが実稼働ネットワークで有効になる前に、`rippled`の構成ファイルを実行して強制的に機能を有効にします。これは、開発目的でのみサポートされています。
|
||||
|
||||
コンセンサスネットワークの他のメンバーはこの機能を有効にしていない可能性があるため、実稼働ネットワークに接続されている間はこの機能を使用しないでください。機能を強制的に有効にしてテストしている間は、[スタンドアロンモード](rippled-server-modes.html#rippledサーバーをスタンドアロンモードで実行する理由)で`rippled`を実行する必要があります。
|
||||
コンセンサスネットワークの他のメンバーはこの機能を有効にしていない可能性があるため、実稼働ネットワークに接続されている間はこの機能を使用しないでください。機能を強制的に有効にしてテストしている間は、[スタンドアロンモード](rippled-server-modes.html#スタンドアロンモード)で`rippled`を実行する必要があります。
|
||||
|
||||
機能を強制的に有効にするには、`[features]`スタンザを`rippled.cfg`ファイルに追加します。このスタンザで、有効にする機能の名前の短縮名を1行に1つずつ追加します。例:
|
||||
|
||||
|
||||
@@ -24,7 +24,7 @@ XRP Ledgerは、「価値のインターネット」を推進および実現可
|
||||
|
||||
XRP Ledgerの中心であるピアツーピアネットワークは、コンセンサスとトランザクションプロセスのルールを実行するために、信頼性が高く、効率のよいサーバーを必要とします。Rippleでは、このサーバーソフトウェアのリファレンス実装である[**`rippled`**](xrpl-servers.html)（発音は「リップルディー」）を管理および公開しています。このサーバーは、[一般利用が可能なオープンソースライセンス](https://github.com/ripple/rippled/blob/develop/LICENSE.md)の下で使用できるため、誰でもこのサーバーの自身のインスタンスを検証し、変更することができます。また、いくつかの制限の下でそれを再公開することができます。
|
||||
|
||||
`rippled`の各インスタンスは、（[Test Netなどの並列ネットワーク](parallel-networks.html)に従うように構成されていない限り）同じネットワークに同期され、ネットワーク全体のあらゆる通信にアクセスできます。ネットワーク上の各`rippled`サーバーは、最近のトランザクションの一部と、それらのトランザクションで行われた変更の記録とともに、XRP Ledger全体の最新の状態データの完全なコピーを保持します。また、各サーバーは各トランザクションを単独で処理すると同時に、そのトランザクションの結果が残りのネットワークに一致するか検証します。サーバーは、より多くの[レジャー履歴](ledger-history.html)を保持したり、[バリデータ](rippled-server-modes.html#バリデータを運用する理由)としてコンセンサスプロセスに参加するように構成することができます。
|
||||
`rippled`の各インスタンスは、（[Testnetなどの並列ネットワーク](parallel-networks.html)に従うように構成されていない限り）同じネットワークに同期され、ネットワーク全体のあらゆる通信にアクセスできます。ネットワーク上の各`rippled`サーバーは、最近のトランザクションの一部と、それらのトランザクションで行われた変更の記録とともに、XRP Ledger全体の最新の状態データの完全なコピーを保持します。また、各サーバーは各トランザクションを単独で処理すると同時に、そのトランザクションの結果が残りのネットワークに一致するか検証します。サーバーは、より多くの[レジャー履歴](ledger-history.html)を保持したり、[バリデータ](rippled-server-modes.html#バリデータ)としてコンセンサスプロセスに参加するように構成することができます。
|
||||
|
||||
このサーバーは、データの検索、サーバーの管理、トランザクションの送信を行うための[`rippled` API](http-websocket-apis.html)をユーザーに公開します。
|
||||
|
||||
|
||||
@@ -48,7 +48,7 @@ labels:
|
||||
|
||||
- 送金元に十分な資金がないために一時的に失敗した[Paymentトランザクション][]は、必要な資金を送金する別の取引が正規の順序で先に行われることにより、後で成功する可能性があります。逆も同様です。一時的に成功したトランザクションは、必要な資金を送金するトランザクションが標準的な順序に入れられたものの先に来なかったために失敗する可能性があります。
|
||||
|
||||
**ヒント:** 上記の理由により、XRP Ledgerに対してテストを実行しており、同じデータに影響する複数のアカウントがある場合、必ずトランザクション間のレジャーが閉じられるまでお待ちください。[スタンドアロンモード](rippled-server-modes.html#rippledサーバーをスタンドアロンモードで実行する理由)のサーバーに対してテストを実行する場合は、[レジャーを手動で閉じる](advance-the-ledger-in-stand-alone-mode.html)必要があります。
|
||||
**ヒント:** 上記の理由により、XRP Ledgerに対してテストを実行しており、同じデータに影響する複数のアカウントがある場合、必ずトランザクション間のレジャーが閉じられるまでお待ちください。[スタンドアロンモード](rippled-server-modes.html#スタンドアロンモード)のサーバーに対してテストを実行する場合は、[レジャーを手動で閉じる](advance-the-ledger-in-stand-alone-mode.html)必要があります。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
@@ -62,7 +62,7 @@ XRP Ledgerにトランザクションを送信するには、いくつかの手
|
||||
3. `rippled`サーバーにトランザクションを送信します。トランザクションが適切に作成されている場合、サーバーはそのトランザクションを現行バージョンのレジャーに暫定的に適用し、そのトランザクションをピアツーピアネットワークの他のメンバーに中継します。
|
||||
4. [コンセンサスプロセス](consensus.html)によって、次の検証済みレジャーに含まれる暫定的なトランザクションが決定されます。
|
||||
5. `rippled`サーバーはそれらのトランザクションを正規順序で前のレジャーに適用し、それらの結果を共有します。
|
||||
6. 十分に[信頼できるバリデータ](rippled-server-modes.html#バリデータを運用する理由) がまったく同じレジャーを作成した場合、そのレジャーは _検証済み_ であると宣言され、そのレジャーの[トランザクションの結果](transaction-results.html)は不変となります。
|
||||
6. 十分に[信頼できるバリデータ](rippled-server-modes.html#バリデータ)がまったく同じレジャーを作成した場合、そのレジャーは _検証済み_ であると宣言され、そのレジャーの[トランザクションの結果](transaction-results.html)は不変となります。
|
||||
|
||||
XRP決済の送信に関する対話型チュートリアルについては、[Send XRP](send-xrp.html)を参照してください。
|
||||
|
||||
|
||||
@@ -71,7 +71,7 @@ Escrowは、少量の大口決済に適した大きな保証を提供してい
|
||||
|
||||
条件付き決済は、2017-03-31以降XRP Ledgerコンセンサスプロトコルに対する[「Escrow」Amendment](known-amendments.html#escrow)により利用可能になりました。同機能の以前のバージョンは、2016年に「Suspended Payments」（SusPay）という名称で[XRP Ledger Testnet](xrp-testnet-faucet.html)で利用可能になりました。
|
||||
|
||||
[スタンドアロンモード](rippled-server-modes.html#rippledサーバーをスタンドアロンモードで実行する理由)でのテストの際には、Amendmentのステータスに関係なく、Escrow機能をローカルで強制的に有効にできます。次のスタンザを`rippled.cfg`に追加してください。
|
||||
[スタンドアロンモード](rippled-server-modes.html#スタンドアロンモード)でのテストの際には、Amendmentのステータスに関係なく、Escrow機能をローカルで強制的に有効にできます。次のスタンザを`rippled.cfg`に追加してください。
|
||||
|
||||
[features]
|
||||
Escrow
|
||||
|
||||
@@ -29,22 +29,25 @@ labels:
|
||||
|
||||
`rippled`サーバーは起動されると、最優先で最新の検証済みレジャーの完全なコピーを取得します。その後、サーバーは常にレジャーの進行状況を把握します。レジャー履歴を埋め戻すように設定されているサーバーでは、レジャー履歴が設定量に達するまで埋め戻されます。この設定量は、オンライン削除による削除が開始されるカットオフ値以下でなければなりません。
|
||||
|
||||
サーバーは同期される前から履歴の埋め戻しを行い、同期後にも収集した履歴のギャップを埋めることができます。（レジャー履歴のギャップは、サーバーの使用率が一時的に高くなりネットワークと同期をとることができない場合、ネットワークとの接続が失われた場合、またはその他の一時的な問題の影響を受けた場合に発生する可能性があります。）履歴を埋め戻すため、サーバーはピア`rippled`サーバーにデータを要求します。サーバーが埋め戻す量は、`[ledger_history]`設定で定義されます。
|
||||
履歴の埋め戻しは、サーバーの最も低い優先順位の1つであるため、特にサーバーが忙しい場合や、ハードウェアやネットワークのスペックが十分でない場合、不足する履歴を埋めるのに長い時間がかかることがあります。ハードウェアのスペックに関する推奨事項は、[容量計画](capacity-planning.html)を参照してください。また、履歴を埋め戻すには、サーバーのダイレクトピアのうち少なくとも1つが該当する履歴を持っていることが必要です。サーバーのピアツーピア接続の管理については、[ピアリングの設定](configure-peering.html)を参照してください。
|
||||
|
||||
XRP Ledgerは、コンテンツの一意のハッシュを使用して（さまざまなレベルの）データを識別します。XRP Ledgerの状態データには、レジャーの履歴の概要が[LedgerHashesオブジェクトタイプ](ledgerhashes.html)の形式で含まれています。サーバーはLedgerHashesオブジェクトを使用して取得するレジャーバージョンを認識し、受信するレジャーデータが正しく完全であることを確認します。
|
||||
|
||||
履歴の埋め戻しは、サーバーでは最も優先度の低い処理の1つであるため、サーバーの使用率が高い場合やハードウェアとネットワークのスペックが十分ではない場合には、欠落している履歴を埋めるのに時間がかかることがあります。推奨されるハードウェアスペックについては、[容量の計画](capacity-planning.html)を参照してください。履歴の埋め戻しでは、サーバーのダイレクトピアの1つ以上に当該の履歴が保持されている必要もあります。 <!--{# TODO: link some info for managing your peer connections when that exists #}-->
|
||||
|
||||
### 指示による削除の使用
|
||||
<a id="with-advisory-deletion"></a>
|
||||
### 履歴の埋め戻し
|
||||
[新規: rippled 1.6.0][]
|
||||
|
||||
[オンライン削除](online-deletion.html)と指示による削除の両方が有効な場合、サーバーでは、まだ削除が許可されていない最も古いレジャーまでのデータが自動的に埋め戻されます。これにより、`[ledger_history]`設定と`online_delete`設定で構成されているレジャーバージョンの数よりも多いデータが取得されることがあります。[can_deleteメソッド][]を実行すると、削除可能なレジャーバージョンがサーバーに通知されます。
|
||||
サーバーがダウンロードしようとする履歴の量は、その設定に依存します。サーバーは自動的に、**最も古い台帳までの履歴**をダウンロードしてギャップを埋めようとします。`[ledger_history]`設定を使用すると、サーバーがそれ以降の履歴を埋め戻すようにすることができます。ただし、[削除](online-deletion.html)が予定されている台帳は、サーバーがダウンロードすることはありません。
|
||||
|
||||
`[ledger_history]`設定は、現在有効な台帳の前から蓄積する台帳の最小数を定義します。ネットワークの[完全な履歴](#すべての履歴)をダウンロードするには、特別な値`full`を使用します。`[ledger_history]`設定を使用して、サーバーに _より少ない_ 履歴をダウンロードさせることはできません。サーバーが保存する履歴の量を減らすには、代わりに[オンライン削除](online-deletion.html)設定を変更してください。
|
||||
|
||||
## すべての履歴
|
||||
|
||||
XRP Ledgerネットワーク内の一部のサーバーは、「すべての履歴が記録される」サーバーとして設定されています。これらのサーバーは、使用可能なすべてのXRP Ledgerの履歴を収集しますが、**オンライン削除は使用しません**。このため他の追跡サーバーよりもかなり多くのディスク容量が必要です。
|
||||
|
||||
Rippleは、`s2.ripple.com`ですべての履歴が記録される一連の公開サーバーを公開サービスとして提供しています。このサービスは、より大きなXRPコミュニティーのために提供されています。Rippleは、サーバーを悪用するユーザーや、公平な量を超えるサーバーのリソースを使用するユーザーをブロックする権利を留保しています。
|
||||
XRP Ledger財団は、コミュニティメンバーが運営する一連の全履歴サーバーへのアクセスを提供しています（詳細は[xrplcluster.com](https://xrplcluster.com)を参照）。
|
||||
また、Ripple社は公開サービスとして、`s2.ripple.com`に一連の公開全履歴サーバーを提供しています。
|
||||
|
||||
**ヒント:** 一部の暗号資産ネットワークとは異なり、XRP Ledgerのサーバーは、現在の状態を認識して最新のトランザクションを把握するのにすべての履歴を必要としません。
|
||||
|
||||
@@ -58,6 +61,23 @@ XRP Ledgerのすべての履歴を1台の高価なマシンに保管する代わ
|
||||
|
||||
詳細は、[履歴シャーディングの設定](configure-history-sharding.html)を参照してください。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [レジャー](ledgers.html)
|
||||
- [コンセンサスの紹介](intro-to-consensus.html)
|
||||
- **チュートリアル:**
|
||||
- [`rippled`の設定](configure-rippled.html)
|
||||
- [オンライン削除の設定](configure-online-deletion.html)
|
||||
- [指示による削除の設定](configure-advisory-deletion.html)
|
||||
- [履歴シャーディングの設定](configure-history-sharding.html)
|
||||
- [全履歴の設定](configure-full-history.html)
|
||||
- **リファレンス:**
|
||||
- [ledgerメソッド][]
|
||||
- [server_infoメソッド][]
|
||||
- [ledger_requestメソッド][]
|
||||
- [can_deleteメソッド][]
|
||||
- [ledger_cleanerメソッド][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
|
||||
@@ -68,7 +68,7 @@ protocol = peer
|
||||
次の場合、`rippled`サーバーは、信頼性の低いピアには接続されません。
|
||||
|
||||
- [プライベートピア](#プライベートピア)として構成されている場合、サーバーは固定ピアに _のみ_ 接続されます。
|
||||
- [スタンドアロンモード](rippled-server-modes.html#rippledサーバーをスタンドアロンモードで実行する理由)で実行されている場合、サーバーは _どの_ ピアにも接続されません。
|
||||
- [スタンドアロンモード](rippled-server-modes.html#スタンドアロンモード)で実行されている場合、サーバーは _どの_ ピアにも接続されません。
|
||||
|
||||
|
||||
## プライベートピア
|
||||
|
||||
@@ -9,32 +9,41 @@ labels:
|
||||
|
||||
`rippled`サーバーソフトウェアは、その設定に応じて以下のようなさまざまなモードで実行できます。
|
||||
|
||||
* ストックサーバー - レジャーのローカルコピーを保持し、ネットワークをフォローします。
|
||||
* 検証サーバー（ _バリデータ_ ）- コンセンサスの参加者（ストックサーバーの処理もすべて行います）。
|
||||
* `rippled`スタンドアロンモードのサーバー - テスト用。他の`rippled`サーバーと通信しません。
|
||||
- [**P2Pモード**](#p2pモード) - ピアツーピアネットワークをフォローし、トランザクションを処理し、ある程度の[レジャー履歴](ledger-history.html)を維持します。このモードは、以下の役割のいずれか、またはすべてを行うように設定することができます。
|
||||
- [**バリデータ**](#バリデータ) - コンセンサスに参加することで、ネットワークの安全確保に貢献します。
|
||||
- [**APIサーバー**](#apiサーバー) - 共有レジャーからデータを読み込んだり、トランザクションを送信したり、レジャーのアクティビティを監視するための[APIアクセス](get-started-using-http-websocket-apis.html)を提供します。オプションとして、トランザクションやレジャーの履歴を完全に記録する [**全履歴サーバー**](#全履歴サーバー) とすることができます。
|
||||
- [**ハブサーバー**](#公開ハブ) - ピアツーピアネットワークの他の多くのメンバー間のメッセージを中継します。
|
||||
- [**レポートモード**](#レポートモード) - リレーショナルデータベースからのAPIリクエストに対応するための専用モードです。ピアツーピアネットワークには参加しないため、P2Pモードサーバーを実行し、信頼できるgRPC接続を使用してレポートモードサーバーに接続する必要があります。 [新規: rippled 1.7.0][]
|
||||
- [**スタンドアロンモード**](#スタンドアロンモード) - テスト用のオフラインモードです。ピアツーピアネットワークに接続せず、コンセンサスも使用しません。
|
||||
|
||||
また、[`rippled` API](http-websocket-apis.html)にローカルでアクセスするためのクライアントアプリケーションとして、`rippled`実行可能ファイルを実行できます。（この場合同じバイナリの2つのインスタンスを並列して実行できます。1つのインスタンスをサーバーとして実行し、もう1つのインスタンスをクライアントとして一時的に実行して終了します。）
|
||||
|
||||
各モードでrippledを実行するためのコマンドについては、[rippledコマンドライン使用リファレンス](commandline-usage.html)を参照してください。
|
||||
各モードで`rippled`を実行するためのコマンドについては、[rippledコマンドライン使用リファレンス](commandline-usage.html)を参照してください。
|
||||
|
||||
|
||||
## ストックサーバーを運用する理由
|
||||
## P2Pモード
|
||||
|
||||
独自の`rippled`サーバーを運用する理由は多数ありますが、その最たる理由として、独自サーバーが信頼できるものであり、自身でその負荷を管理でき、サーバーにアクセスするタイミングとアクセス方法を他のユーザーに依存せずに決めることができる点があげられます。もちろん、独自サーバーを不正使用者から保護するために適切なネットワークセキュリティ対策を講じなければなりません。
|
||||
P2Pモードは`rippled`サーバーのメインかつデフォルトのモードで、サーバーが行うべきほぼ全てのことを処理することができます。これらのサーバーは、トランザクションを処理し、XRP Ledgerの共有状態を維持するピアツーピア・ネットワークを形成しています。トランザクションを送信したり、レジャーデータを読んだり、その他ネットワークに参加したい場合、リクエストはどこかでP2Pモードのサーバーを経由しなければなりません。
|
||||
|
||||
使用する`rippled`を信頼する必要があります。悪意のあるサーバーに接続してしまうと、そのサーバーはさまざまな方法であなたを利用して資金を失わせることができます。例:
|
||||
P2Pモードのサーバーは、追加機能を提供するためにさらに細かく設定することができます。P2Pモードで動作し、設定ファイルを最小限に変更したサーバーは、_ストックサーバー_ とも呼ばれます。その他の構成は以下の通りです。
|
||||
|
||||
* 悪意のあるサーバーは、実際には行われていないあなたへの支払いが行われたと報告することがあります。
|
||||
* ペイメントパスと通貨取引オファーを選択的に表示または非表示にし、最適なディールをあなたに提示せずに不正使用者の利益になるようにします。
|
||||
* 悪意のあるサーバーにアドレスのシークレットキーを送信すると、このサーバーがあなたの代理として任意のトランザクションを実行し、アドレスが保有する資金全額を送金または消却することがあります。
|
||||
- [バリデータ](#バリデータ)
|
||||
- [APIサーバー](#apiサーバー)
|
||||
- [公開ハブ](#公開ハブ)
|
||||
|
||||
さらに、独自サーバーを運用することでサーバーを制御できるようになり、重要な管理者専用コマンドや負荷の高いコマンドを実行できます。共有サーバーを使用する場合は、同じサーバーを利用する他のユーザーとサーバーのコンピューティング能力をめぐって競合することに注意する必要があります。WebSocket APIのコマンドの多くは、サーバーに大きな負荷をかけるため、`rippled`には必要に応じてその応答を縮小できるオプションがあります。サーバーを他のユーザーと共有する場合には、常に最適の結果を得られるとは限りません。
|
||||
P2Pモードのサーバーは、デフォルトで[Mainnet](parallel-networks.html)に接続します。
|
||||
|
||||
最後に、各自で検証サーバーを運用する場合には、ストックサーバーをパブリックネットワークへのプロキシとして使用し、ストックサーバー経由でのみ外部にアクセス可能なプライベートサブネット上で検証サーバーを維持することができます。これにより、検証サーバーの整合性を危うくすることはさらに難しくなります。
|
||||
### APIサーバー
|
||||
|
||||
全てのP2Pモードサーバーは、トランザクションの送信、残高や設定の確認、サーバーの管理などの目的で、[API](http-websocket-apis.html)を提供しています。もしあなたがXRP Ledgerにデータを照会したり、ビジネス用途でトランザクションを送信するのであれば、[独自サーバーを運営する](xrpl-servers.html#独自サーバーを運用する理由)ことが有効でしょう。
|
||||
|
||||
#### 全履歴サーバー
|
||||
|
||||
他のいくつかのブロックチェーンとは異なり、XRP Ledgerは、現在のステートの把握や新しいトランザクションの処理のために、サーバーが完全なトランザクション履歴を持つことを必要としません。サーバーの運用者は、一度にどれだけの[レジャー履歴](ledger-history.html)を保存するかを決めることができます。ただし、P2PモードサーバーがAPIリクエストに答えられるのは、ローカルで利用可能なレジャー履歴のみです。例えば、6ヶ月分の履歴を保存している場合、サーバーは1年前のトランザクションの結果を示すことはできません。[すべての履歴](ledger-history.html#すべての履歴)を持つAPIサーバーは、XRP Ledgerの開始以降のすべてのトランザクションと残高を報告できます。
|
||||
|
||||
### 公開ハブ
|
||||
|
||||
公開ハブは、他のサーバーへの[ピアプロトコル接続](peer-protocol.html)が多数あるストックサーバーを指します。ストックサーバーを公開ハブとして実行することで、XRP Ledgerネットワークの効率的な接続を維持できます。適切に運用されている公開ハブには、以下の特徴があります。
|
||||
公開ハブは、他のサーバーへの[ピアプロトコル接続](peer-protocol.html)が多数あるストックサーバーを指します。ストックサーバーを _公開ハブ_ として実行することで、XRP Ledgerネットワークの効率的な接続を維持できます。適切に運用されている公開ハブには、以下の特徴があります。
|
||||
|
||||
- 十分な帯域幅。
|
||||
|
||||
@@ -42,56 +51,45 @@ labels:
|
||||
|
||||
- メッセージを確実に中継する能力。
|
||||
|
||||
サーバーをハブとして設定するには、許可される最大ピア数を増やし、ファイアウォールやNAT（ネットワークアドレス変換）ルーターで[適切なポートを転送](forward-ports-for-peering.html)していることを確認する必要があります。
|
||||
|
||||
## バリデータ
|
||||
|
||||
## バリデータを運用する理由
|
||||
XRP Ledgerの堅牢性は、他のバリデータが共謀しないことをそれぞれが信頼している、相互接続されたバリデータのネットワークに依存しています。他のP2Pモードサーバーと同様に、各トランザクションを処理し、レジャーの状態を計算することに加え、バリデータは[コンセンサスプロトコル](consensus.html)に積極的に参加しています。もしあなたやあなたの組織がXRP Ledgerにアクセスするのであれば、バリデータとして1台のサーバーを稼働させ、コンセンサスプロセスに貢献することが望ましいでしょう。
|
||||
|
||||
XRP Ledgerの堅牢性は、バリデータが相互に接続されたネットワークに依存しています。各バリデータは、他の何人かのバリデータが _共謀しない_ と信頼しています。利害の異なるバリデータ運用オペレーターが増えるほど、ネットワークの各メンバーは、ネットワークが引き続き公平に運営されることに確信が持てるようになります。XRP Ledgerを使用している組織や個人の場合、コンセンサスプロセスへ参加することが自らの利益につながります。
|
||||
バリデーションはわずかな計算資源しか使用しませんが、1つの組織や団体が複数のバリデータを運用しても、共謀に対する保護が強化されるわけではないので、あまりメリットはないでしょう。各バリデータは一意の暗号鍵ペアで識別されるので、慎重に管理しなければいけません。複数のバリデータが鍵ペアを共有してはいけません。このような理由から、バリデーションはデフォルトで無効になっています。
|
||||
|
||||
すべての`rippled`サーバーをバリデータとする必要はありません。信頼する同一オペレーターのサーバーの数が増えても、共謀の発生をよりよく防止できるわけではありません。組織が自然災害などの緊急事態に備えて冗長性を保つために、複数の地域でバリデータを運用することがあります。
|
||||
|
||||
組織が検証サーバーを運用している場合は、1つ以上のストックサーバーを実行して、APIアクセスの計算負荷のバランスを取ったり、それらを検証サーバーと外部ネットワーク間のプロキシとすることもできます。
|
||||
他の目的にも使用されているサーバーで、安全にバリデーションを有効にすることができます。このような構成は _汎用サーバー_ と呼ばれます。あるいは、他のタスクを実行しない _専用バリデータ_ を、P2Pモードの他の`rippled`サーバーと一緒に[クラスタ](clustering.html)で実行することもできます。
|
||||
|
||||
バリデータの実行についての詳細は、[バリデータとしての`rippled`の実行](run-rippled-as-a-validator.html)を参照してください。
|
||||
|
||||
|
||||
|
||||
## `rippled`サーバーをスタンドアロンモードで実行する理由
|
||||
## レポートモード
|
||||
[新規: rippled 1.7.0][]
|
||||
|
||||
信頼できるサーバーのコンセンサスなしでも、`rippled`をスタンドアロンモードで実行できます。スタンドアロンモードでは、`rippled`はXRP Ledgerピアツーピアネットワーク内のその他のサーバーとは通信しませんが、同じ操作のほとんどをローカルサーバーのみで実行できます。スタンドアロンでは、本番環境ネットワークに接続せずに`rippled`の動作をテストできます。たとえば、分散型ネットワークにAmendmentが反映される前に、[Amendmentの効果をテスト](amendments.html#amendmentのテスト)できます。
|
||||
レポートモードは、APIリクエストをより効率的に処理するために特化したモードです。このモードでは、サーバーは[gRPC](configure-grpc.html)を介して、P2Pモードで動作する別の`rippled`サーバーから最新の検証済みレジャーデータを取得し、そのデータをリレーショナルデータベース([PostgreSQL](https://www.postgresql.org/))にロードします。レポートモードサーバはピアツーピアネットワークに直接参加しませんが、トランザクションの送信などの要求を、使用しているP2Pモードサーバに転送することはできます。
|
||||
|
||||
`rippled`をスタンドアロンモードで実行する場合、どのレジャーバージョンから開始するかを指示する必要があります。
|
||||
複数のレポートモードサーバーは、PostgreSQLデータベースと[Apache Cassandra](https://cassandra.apache.org/)クラスタへのアクセスを共有し、各サーバーがすべてのデータの冗長コピーを必要とせずに大量の履歴を提供できます。レポートモードサーバは、基礎となるデータの保存方法の違いに対応するため、若干の変更を加えた同じ[`rippled` API](http-websocket-apis.html)を使ってこのデータを提供します。
|
||||
|
||||
* [新しいジェネシスレジャー](start-a-new-genesis-ledger-in-stand-alone-mode.html)を最初から作成する。
|
||||
* ディスクから[既存のレジャーバージョンを読み込む](load-a-saved-ledger-in-stand-alone-mode.html)。
|
||||
最も注目すべきは、レポートモードのサーバーは、保留中や未検証のレジャーデータまたはトランザクションをレポートしないことです。この制限は、[分散型取引所](decentralized-exchange.html)での裁定取引の実行など、流動的なデータへの迅速なアクセスに依存する特定の使用事例に関連しています。
|
||||
|
||||
|
||||
## スタンドアロンモード
|
||||
|
||||
スタンドアロンモードでは、サーバーはネットワークに接続せず、コンセンサスプロセスにも参加せずに動作します。コンセンサスプロセスがなければ、手動で台帳を進める必要があり、「closedレジャー」と「validatedレジャー」の区別はありません。しかし、サーバーは依然としてAPIアクセスを提供し、トランザクションを同じように処理します。これにより、以下のことが可能になります。
|
||||
|
||||
- 分散型ネットワーク上でAmendmentsが有効になる前に、[Amendmentsの影響をテストする](test-amendments.html)。
|
||||
- [新しいジェネシスレジャー](start-a-new-genesis-ledger-in-stand-alone-mode.html)を最初から作成する。
|
||||
- ディスクから[既存のレジャーバージョンを読み込み](load-a-saved-ledger-in-stand-alone-mode.html)、特定のトランザクションを再生して、その結果を再現したり、他の可能性をテストする。
|
||||
|
||||
**注意:** スタンドアロンモードでは[レジャーを手動で進める](advance-the-ledger-in-stand-alone-mode.html)必要があります。
|
||||
|
||||
## レポーティングモード
|
||||
[導入: rippled 1.7.0][][]
|
||||
|
||||
<!-- TODO: translate this section -->
|
||||
Reporting mode is specialized mode for serving API requests more efficiently. In this mode, the server gets the latest validated ledger data over [gRPC](https://xrpl.org/configure-grpc.html) from a separate `rippled` server running in P2P Mode, then loads that data into a relational database ([PostgreSQL](https://www.postgresql.org/)). The reporting mode server does not directly participate in the peer-to-peer network, though it can forward requests such as transaction submission to the P2P Mode server it uses.
|
||||
|
||||
Multiple reporting mode servers can share access to a PostgreSQL database and [Apache Cassandra](https://cassandra.apache.org/) cluster to serve a large amount of history without each server needing a redundant copy of all the data. Reporting mode servers provide this data through the same [`rippled` APIs](http-websocket-apis.html) with some slight changes to accommodate for the differences in how they store the underlying data.
|
||||
|
||||
Most notably, reporting mode servers do not report pending, non-validated ledger data or transactions. This limitation is relevant to certain use cases that rely on rapid access to in-flux data, such as performing arbitrage in the [decentralized exchange](decentralized-exchange.html).
|
||||
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **リファレンス:**
|
||||
- [コマンドライン使用リファレンス](commandline-usage.html) - すべての`rippled`サーバーモードのコマンドラインオプションに関する詳細情報。
|
||||
- [ledger_acceptメソッド][] - スタンドアロンモードでレジャーを手動で進めます。
|
||||
- [featureメソッド][] - 現在有効になっている既知の[Amendment](amendments.html)を確認します。
|
||||
- **チュートリアル:**
|
||||
- [`rippled`の構成](configure-rippled.html)
|
||||
- [バリデータとしての`rippled`の実行](run-rippled-as-a-validator.html)
|
||||
- [スタンドアロンモードでのrippledの使用](use-stand-alone-mode.html):
|
||||
- [スタンドアロンモードでの新しいジェネシスレジャーの開始](start-a-new-genesis-ledger-in-stand-alone-mode.html)
|
||||
- [スタンドアロンモードでの保存済みレジャーの読み込み](load-a-saved-ledger-in-stand-alone-mode.html)
|
||||
- [スタンドアロンモードでレジャーを進める](advance-the-ledger-in-stand-alone-mode.html)
|
||||
- [スタンドアロンモードでのrippledの使用](use-stand-alone-mode.html)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
|
||||
@@ -10,7 +10,7 @@ labels:
|
||||
The `rippled` server software can run in several modes depending on its configuration, including:
|
||||
|
||||
- [**P2P Mode**](#p2p-mode) - This is the main mode of the server: it follows the peer-to-peer network, processes transactions, and maintains some amount of [ledger history](ledger-history.html). This mode can be configured to do any or all of the following roles:
|
||||
- [**Validator**](#validators) - Helps secure the network by participating in consensus
|
||||
- [**Validator**](#validators) - Helps secure the network by participating in consensus.
|
||||
- [**API Server**](#api-servers) - Provides [API access](get-started-using-http-websocket-apis.html) to read data from the shared ledger, submit transactions, and watch activity in the ledger. Optionally, this can be a [**Full History Server**](#full-history-servers), which keeps a complete record of transaction and ledger history.
|
||||
- [**Hub Server**](#public-hubs) - Relays messages between many other members of the peer-to-peer network.
|
||||
- [**Reporting mode**](#reporting-mode) - A specialized mode for serving API requests from a relational database. It does not participate in the peer-to-peer network, so you need to run a P2P Mode server and connect the reporting mode server using a trusted gRPC connection. [New in: rippled 1.7.0][]
|
||||
|
||||
44
content/concepts/xrpl-servers/the-clio-server.ja.md
Normal file
44
content/concepts/xrpl-servers/the-clio-server.ja.md
Normal file
@@ -0,0 +1,44 @@
|
||||
---
|
||||
html: the-clio-server.html
|
||||
parent: xrpl-servers.html
|
||||
blurb: Clioは、API呼び出しに最適化されたXRP Ledgerサーバーです。
|
||||
---
|
||||
# Clioサーバー
|
||||
|
||||
Clioは、検証済みの台帳データに対するWebSocketまたはHTTP API呼び出しに最適化されたXRP Ledger APIサーバーです。
|
||||
|
||||
ClioサーバはP2Pネットワークに接続しません。代わりに、P2Pネットワークに接続されている指定された`rippled`サーバからデータを抽出します。APIコールを効率的に処理することで、ClioサーバーはP2Pモードで動作する`rippled`サーバーの負荷を軽減することができます。
|
||||
|
||||
Clioは、検証済みの過去の台帳とトランザクションデータをスペース効率の良いフォーマットで保存し、`rippled`に比べて最大4倍少ないスペースで保存できます。ClioはCassandraまたはScyllaDBを使用し、スケーラブルな読み取りスループットを可能にします。複数のClioサーバーが同じデータセットへのアクセスを共有できるため、冗長なデータストレージや計算を必要とせず、Clioサーバーの高可用性クラスタを構築することが可能です。
|
||||
|
||||
Clioは`rippled`サーバーにアクセスする必要があり、このサーバーはClioと同じマシン上で実行することも、別々に実行することも可能です。
|
||||
|
||||
Clioは完全な[HTTP / WebSocket API](http-websocket-apis.html)を提供していますが、デフォルトでは、検証済みのデータのみを返します。P2Pネットワークへのアクセスを必要とするリクエストに対しては、Clioは自動的にP2Pネットワーク上の`rippled`サーバにリクエストを転送し、レスポンスを返します。
|
||||
|
||||
## Clioサーバーを運用する理由
|
||||
|
||||
独自のClioサーバーを運用する理由には様々なものがありますが、その多くは、P2Pネットワークに接続している`rippled`サーバーの負荷軽減、メモリ使用量とストレージのオーバーヘッドの低減、水平スケーリングの容易さ、APIリクエストのスループットの向上などに集約されるのではないでしょうか。
|
||||
|
||||
* `rippled`サーバーの負荷軽減 - Clioサーバーはピアツーピア・ネットワークに接続しません。P2Pネットワークに接続されている1つ以上の信頼できる`rippled`サーバーから検証済みのデータを取得するためにgRPCを使用します。したがって、Clioサーバーはリクエストをより効率的に処理し、P2Pモードで動作する`rippled`サーバーの負荷を軽減することができます。
|
||||
|
||||
* メモリ使用量とストレージのオーバーヘッドの低減 - ClioはデータベースとしてCassandraを使用し、データをスペース効率の良いフォーマットで保存するため、`rippled`に比べて最大4倍少ないスペースで保存できます。
|
||||
|
||||
* 容易な水平スケーリング - 複数のClioサーバーが同じデータセットへのアクセスを共有できるため、Clioサーバーの高可用性クラスターを構築することが可能です。
|
||||
|
||||
* APIリクエストのスループットの向上 - Clioサーバーは、1つまたは複数の信頼できる`rippled`サーバーから検証済みのデータを抽出し、このデータを効率的に保存します。そのため、APIコールを効率的に処理することができ、結果としてスループットが向上し、場合によってはレイテンシーも低下します。
|
||||
|
||||
|
||||
## Clioサーバーの仕組み
|
||||
|
||||
{{ include_svg("img/clio-basic-architecture.svg", "図1: Clioサーバーの仕組み") }}
|
||||
|
||||
Clioサーバーは、トランザクションメタデータ、アカウントステート、台帳ヘッダーなどの有効な台帳データを永続的なデータストアに保存します。
|
||||
|
||||
ClioサーバーはAPIリクエストを受信すると、これらのデータストアからデータを検索します。P2Pネットワークからのデータを必要とするリクエストについては、ClioサーバーはリクエストをP2Pサーバーに転送し、レスポンスをクライアントに返します。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [Clio ソースコード](https://github.com/XRPLF/clio)
|
||||
- **チュートリアル:**
|
||||
- [UbuntuにClioサーバーをインストールする](install-clio-on-ubuntu.html)
|
||||
39
content/concepts/xrpl-servers/xrpl-servers.ja.md
Normal file
39
content/concepts/xrpl-servers/xrpl-servers.ja.md
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
html: xrpl-servers.html
|
||||
parent: concepts.html
|
||||
blurb: rippledは、XRP Ledgerを管理するコアとなるピアツーピアサーバーです。
|
||||
template: pagetype-category.html.jinja
|
||||
---
|
||||
# XRP Ledger サーバー
|
||||
|
||||
XRP Ledgerを動かすサーバーソフトウェアは、主に2種類あります。
|
||||
|
||||
- コアサーバーである`rippled`は、トランザクションを処理し、その結果についてコンセンサスを得るピアツーピアネットワークを実行します。
|
||||
- APIサーバーである[Clio](the-clio-server.html)は、台帳からデータをフェッチしたりクエリしたりするための強力なインターフェイスを提供します。
|
||||
|
||||
誰でも必要に応じて、これらのタイプのサーバーの1つまたは両方のインスタンスを実行することができます。
|
||||
|
||||
## 独自サーバーを運用する理由
|
||||
|
||||
簡単なユースケースや個別のサーバーであれば、無料の[公開サーバー][]を利用することも多いでしょう。しかし、XRP Ledgerの利用が本格化すればするほど、独自のインフラを持つことが重要になってきます。
|
||||
|
||||
独自のサーバーを運用したいと思う理由はたくさんありますが、そのほとんどは、「自分のサーバーを信頼できる」「ワークロードをコントロールできる」「いつ、どのようにアクセスできるかを他人の判断に左右されない」ということに集約されます。もちろん、悪意のあるハッカーからサーバーを守るために、優れたネットワークセキュリティを実践する必要があります。
|
||||
|
||||
利用しているサーバーを信頼する必要があります。悪意のあるサーバーに接続すると、そのサーバーに利用されたり、損害を受けたりする可能性があります。例えば、以下のようなことです。
|
||||
|
||||
* 悪意のあるサーバーは、支払いを行っていないにもかかわらず、支払いを受けたと報告する可能性があります。
|
||||
* 選択的に支払いパスや通貨交換のオファーを表示または非表示にすることができ、最良の取引を提供せず、彼ら自身の利益を確保する可能性があります。
|
||||
* もし、アドレスの秘密鍵を送信してしまった場合、サーバーの管理者はあなたに代わって任意のトランザクションを実行し、アドレスが保有するすべての資金を転送または破棄する可能性があります。
|
||||
|
||||
さらに、独自のサーバーを運営することで、[管理者アクセス権限](get-started-using-http-websocket-apis.html#管理者アクセス権限)が与えられ、重要な管理者専用コマンドや負荷の高いコマンドを実行することができます。共有サーバーを使用する場合、同じサーバーの他のユーザーとサーバーの計算能力を共有することを考慮しなければいけません。WebSocket APIのコマンドの多くはサーバーに大きな負担をかけるので、サーバーには必要なときに応答を縮小するオプションがあります。サーバーを他人と共有する場合、常に最良の結果を得られるとは限りません。
|
||||
|
||||
最後に、バリデーションサーバーを運用する場合、パブリックネットワークへのプロキシとしてストックサーバーを使用し、バリデーションサーバーをプライベートネットワークに置いて、ストックサーバーを通してのみ外部にアクセスできるようにすることができます。これにより、バリデーションサーバに侵入することがより困難になります。
|
||||
|
||||
## サーバーの機能とトピックス
|
||||
|
||||
<!-- provided by the auto-generated table of children -->
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -107,7 +107,7 @@ targets:
|
||||
"partial-payments.html#the-delivered_amount-field": "partial-payments.html#delivered_amountフィールド"
|
||||
"partial-payments.html#partial-payments-exploit": "partial-payments.html#partial-paymentの悪用"
|
||||
# nearest approximation. this translation is also out of date
|
||||
"rippled-server-modes.html#validators": "rippled-server-modes.html#バリデータを運用する理由"
|
||||
"rippled-server-modes.html#validators": "rippled-server-modes.html#バリデータ"
|
||||
# Fix links from untranslated open-a-payment-channel-to-enable-an-inter-exchange-network.html
|
||||
"use-payment-channels.html#1-the-payer-creates-a-payment-channel-to-a-particular-recipient": "use-payment-channels.html#1-支払人が特定の受取人へのpayment-channelを作成します"
|
||||
"use-payment-channels.html#2-the-payee-checks-specifics-of-the-payment-channel": "use-payment-channels.html#2-受取人がpayment-channelの特性を確認します"
|
||||
@@ -134,14 +134,14 @@ targets:
|
||||
# Fix link from untranslated peer-crawler.html:
|
||||
"peer-protocol.html#private-peers": "peer-protocol.html#プライベートピア"
|
||||
# Fix links from untranslated health-check.html:
|
||||
"rippled-server-modes.html#stand-alone-mode": "rippled-server-modes.html#rippledサーバーをスタンドアロンモードで実行する理由"
|
||||
"rippled-server-modes.html#stand-alone-mode": "rippled-server-modes.html#スタンドアロンモード"
|
||||
"server-doesnt-sync.html#normal-syncing-behavior": "server-doesnt-sync.html#通常の同期動作"
|
||||
# Fix link from untranslated negativeunl.html and ledgers.html:
|
||||
"consensus.html#validation": "consensus.html#検証"
|
||||
# Fix link from untranslated manifest.html:
|
||||
"rippled-server-modes.html#reporting-mode": "rippled-server-modes.html#レポーティングモード"
|
||||
"rippled-server-modes.html#reporting-mode": "rippled-server-modes.html#レポートモード"
|
||||
# Fix links for untranslated get-started-using-python.html:
|
||||
"xrpl-servers.html#reasons-to-run-your-own-server": "rippled-server-modes.html#ストックサーバーを運用する理由"
|
||||
"xrpl-servers.html#reasons-to-run-your-own-server": "xrpl-servers.html#独自サーバーを運用する理由"
|
||||
"cryptographic-keys.html#key-components": "cryptographic-keys.html#キーの生成"
|
||||
"accounts.html#addresses": "accounts.html#アドレス"
|
||||
"cryptographic-keys.html#private-key": "cryptographic-keys.html#キーの生成"
|
||||
@@ -1085,12 +1085,7 @@ pages:
|
||||
targets:
|
||||
- en
|
||||
|
||||
# old translation
|
||||
- name: rippledサーバー
|
||||
html: xrpl-servers.html
|
||||
parent: concepts.html
|
||||
template: pagetype-category.html.jinja
|
||||
blurb: rippledは、XRP Ledgerを管理するコアのP2Pサーバーです。このセクションではコンセプトについて説明します。XRP Ledgerの基本的な部分の背景に「何があるか」、「なぜなのか」を学ぶことができます。
|
||||
- md: concepts/xrpl-servers/xrpl-servers.ja.md
|
||||
targets:
|
||||
- ja
|
||||
|
||||
@@ -1098,7 +1093,6 @@ pages:
|
||||
targets:
|
||||
- en
|
||||
|
||||
# TODO: Update this translation for the latest English version
|
||||
- md: concepts/xrpl-servers/rippled-server-modes.ja.md
|
||||
targets:
|
||||
- ja
|
||||
@@ -1151,10 +1145,12 @@ pages:
|
||||
targets:
|
||||
- ja
|
||||
|
||||
# TODO: translate
|
||||
- md: concepts/xrpl-servers/the-clio-server.md
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/xrpl-servers/the-clio-server.ja.md
|
||||
targets:
|
||||
- ja
|
||||
|
||||
# Redirect for "Interoperability" landing page
|
||||
|
||||
Reference in New Issue
Block a user