Update Japanese translation files

This commit is contained in:
mDuo13
2020-06-05 17:21:18 -07:00
parent 5d47d4f288
commit fcad9d0376
110 changed files with 9094 additions and 2955 deletions

View File

@@ -10,10 +10,10 @@
履歴シャードを保管できるように`rippled`サーバーを設定する前に、履歴シャードストアーに割り当てるディスク容量を決定する必要があります。これはまた、デフォルトのレジャーストアーに保持する履歴の量にも影響します。シャードストアーのサイズを設定する際には、以下の点を考慮してください。
- レジャーストアー(`[node_db]`スタンザにより定義される)は、履歴シャードストアーとは別のストアーです。レジャーストアーはすべてのサーバーに必要であり、そこには一定範囲の最近の履歴が保管されている _必要があります_ 。保管する範囲は、`online_delete`パラメーターに使用可能な状態で維持するレジャーの数によって定義されます。デフォルトの設定では、最新のレジャー2000個が保管されます。
- レジャーストアーに2^15個以上のレジャー32768が保持されている場合は、レジャーストアーからシャードストアーへ最近の履歴のグループを効率的にインポートできます。
- 履歴<sup></sup>シャードストアー(`[shard_db]`スタンザにより定義される)は、履歴シャードを保管する場合にのみ必要です。履歴シャードを保管しないサーバーではこの構成スタンザを省略する必要があります。履歴シャードストアーのサイズは`max_size_gb`パラメーターでギガバイト単位で定義されます。サーバーは完全なシャードを保管するため、この容量を最大限利用します。
- シャードには2^14個のレジャー16384が含まれており、シャードの経過期間に応じて約200 MB4 GBを専有します。古いシャードほどXRP Ledgerでのアクティビティが少ないため、サイズが小さくなります。
- レジャーストアー(`[node_db]`スタンザにより定義される)は、履歴シャードストアーとは別のストアーです。レジャーストアーはすべてのサーバーに必要であり、そこには一定範囲の最近の履歴が保管されている必要があります。保管する範囲は、`online_delete`パラメーターに使用可能な状態で維持するレジャーの数によって定義されます。デフォルトの設定では、最新のレジャー2000個が保管されます。
- レジャーストアーに2<sup>15</sup>個以上のレジャー32768が保持されている場合は、レジャーストアーからシャードストアーへ最近の履歴のグループを効率的にインポートできます。
- 履歴シャードストアー(`[shard_db]`スタンザにより定義される)は、履歴シャードを保管する場合にのみ必要です。履歴シャードを保管しないサーバーではこの構成スタンザを省略する必要があります。履歴シャードストアーのサイズは`max_size_gb`パラメーターでギガバイト単位で定義されます。サーバーは完全なシャードを保管するため、この容量を最大限利用します。履歴シャードストアーは、 _必ず_ ソリッドステートディスクまたは同様の高速なメディアに保管します。従来の回転式ハードディスクでは不十分です。
- シャードには2<sup>14</sup>個のレジャー16384が含まれており、シャードの経過期間に応じて約200MB4GBを専有します。古いシャードほどXRP Ledgerでのアクティビティが少ないため、サイズが小さくなります。
- 履歴シャードストアーとレジャーストアーはファイルパスを分けて保管する _必要があります_ 。必要に応じて、レジャーストアーと履歴ストアーをそれぞれ別のディスクやパーティションに配置するように設定できます。
- 完全なレジャー履歴をレジャーストアーと履歴シャードストアーの両方に保持できますが、冗長な処理となります。
- シャードの取得にかかる時間、`rippled`サーバーに必要なファイルハンドル数、およびメモリーキャッシュ使用率は、シャードのサイズの影響を直接受けます。
@@ -24,7 +24,7 @@
{% include '_snippets/conf-file-location.md' %}<!--_ -->
以下のスニペットに、`[shard_db]` スタンザの例を示します。
以下のスニペットに、`[shard_db]`スタンザの例を示します。
```
[shard_db]
@@ -33,9 +33,9 @@ path=/var/lib/rippled/db/shards/nudb
max_size_gb=50
```
**ヒント:** シャードストアーにはNuDB`type=NuDB`を使用することが推奨されます。NuDBはRocksDBに比べ、シャードあたりの使用ファイルハンドル数が少なくなります。RocksDBは、保管するデータのサイズに応じて拡張するメモリーを使用するため、大量のメモリーオーバーヘッドが必要になる可能性があります。ただし、NuDBはSSDドライブで使用するように設計されており、回転型ディスクでは機能しません。 <!-- NOTE: out of date; needs to be re-translated. NuDB is required as of v1.3.1. -->
`type`フィールドは省略できます。省略しない場合は、`NuDB`である _必要があります_ 。[新規: rippled 1.3.1][]
**注意:** 履歴シャーディングを有効にした後にシャードストアーのデータベースタイプを変更する場合は、パスを変更するか、または設定されているパスから既存のデータを削除する必要があります。`rippled`がシャードストアーパスで不適切なデータを検出すると、[起動できない](server-wont-start.html)可能性があります。
**注意:** `rippled`がシャードストアーパスで不適切なデータを検出すると、[起動できない](server-wont-start.html)可能性があります。シャードストアーには新しいフォルダーを使用する必要があります。以前にRocksDBシャードストアー`rippled` 1.2.x以前を使用していた場合は、別のパスを使用するか、RocksDBシャードデータを削除します。
詳細は、[rippled.cfgの設定例](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg)の`[shard_db]`の例を参照してください。
@@ -51,4 +51,26 @@ systemctl restart rippled
このフォルダーには、サーバーに保管されている各シャードのフォルダーが番号付きで保存されています。常に、最大で1つのフォルダーに、未完了であることを示す`control.txt`ファイルが保存されています。
<!-- TODO: add download_shard and crawl_shards commands when they get added. -->
[download_shardメソッド][]を使用して、サーバーにアーカイブファイルからシャードをダウンロードしてインポートするように指示できます。
サーバーとそのピアが使用できるシャードのリストを表示するには、[crawl_shardsメソッド][]か[ピアクローラー](peer-crawler.html)を使用します。
## 関連項目
- **コンセプト:**
- [レジャー履歴](ledger-history.html)
- [オンライン削除](online-deletion.html)
- **チュートリアル:**
- [オンライン削除の設定](configure-online-deletion.html)
- [ピアクローラーの設定](configure-the-peer-crawler.html)
- [容量の計画](capacity-planning.html)
- **リファレンス:**
- [download_shardメソッド][]
- [crawl_shardsメソッド][]
- [レジャーデータフォーマット](ledger-data-formats.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

View File

@@ -1,54 +1,112 @@
# XRP Test Netへのrippledの接続
# XRPL Altnetへのrippledの接続
Rippleは、XRP Ledgerのテストプラットフォームを提供するため[XRP Test Network](https://ripple.com/build/xrp-test-net/)を開発しました。XRP Test Netの資金は実際の資金ではなく、テスト専用の資金です。本番環境のXRP Ledger Networkに接続する前に、`rippled`サーバーをXRP Test Netに接続して、`rippled`の機能をテストして理解できます。また、XRP Test Netを使用して、作成したコードが`rippled`と正しくやり取りすることを検証できます。
Rippleは[代替となるテスト用および開発用ネットワーク](parallel-networks.html)を作成しており、開発者が最新のXRP Ledgerの非本番バージョンTestnetでアプリケーションをテストしたり、最新のベータバージョンDevnetで機能をテストして実験したりできるようにしています。 **これらのネットワークで使用する資金は実際の資金ではなく、テスト専用の資金です。** TestnetまたはDevnetの[`rippled`サーバー](the-rippled-server.html)に接続できます。
**注記:** XRP Test Netのレジャーと残高は定期的にリセットされます。
**注記:** XRP TestnetとDevnetのレジャーと残高は定期的にリセットされます。
`rippled`サーバーをXRP Test Netに接続するには、以下の構成を設定します。
`rippled`サーバーをXRP TestnetまたはDevnetに接続するには、以下の構成を設定します。
1. `rippled.cfg`ファイルで以下の手順に従います。
a. 以下のセクションのコメントを解除します。
a. [Testnet](xrp-testnet-faucet.html)に接続するには、以下のセクションのコメントを解除し、次のように追加します。
[ips]
r.altnet.rippletest.net 51235
b. 以下のセクションを次のようにコメントアウトします。
s.altnet.rippletest.net 51235
b. [Devnet](xrp-testnet-faucet.html)に接続するには、以下のセクションのコメントを解除し、次のように追加します。
[ips]
s.devnet.rippletest.net 51235
c. 以下のセクションを次のようにコメントアウトします。
# [ips]
# r.ripple.com 51235
2. `validators.txt`ファイルで以下の手順に従います。
2a. Altnetに接続するための変更
a. 以下のセクションのコメントを解除し、Altnetに接続するようにします。
[validator_list_sites]
https://vl.altnet.rippletest.net
[validator_list_keys]
ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
b. 以下のセクションを次のようにコメントアウトします。
# [validator_list_sites]
# https://vl.ripple.com
#
# [validator_list_keys]
# ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
2b. Devnetに接続するための変更
a. 以下のセクションをコメントアウトします。
# [validator_list_sites]
# https://vl.altnet.rippletest.net
# [validator_list_keys]
# ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
# [validator_list_sites]
# https://vl.ripple.com
#
# [validator_list_keys]
# ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
b. 次の信頼できるバリデータをvalidator.txtファイルに追加します。
# Hard-coded List of Devnet Validators
[validators]
n9Mo4QVGnMrRN9jhAxdUFxwvyM4aeE1RvCuEGvMYt31hPspb1E2c
n9MEwP4LSSikUnhZJNQVQxoMCgoRrGm6GGbG46AumH2KrRrdmr6B
n9M1pogKUmueZ2r3E3JnZyM3g6AxkxWPr8Vr3zWtuRLqB7bHETFD
n9MX7LbfHvPkFYgGrJmCyLh8Reu38wsnnxA4TKhxGTZBuxRz3w1U
n94aw2fof4xxd8g3swN2qJCmooHdGv1ajY8Ae42T77nAQhZeYGdd
n9LiE1gpUGws1kFGKCM9rVFNYPVS4QziwkQn281EFXX7TViCp2RC
n9Jq9w1R8UrvV1u2SQqGhSXLroeWNmPNc3AVszRXhpUr1fmbLyhS
a. 以下のセクションのコメントを解除します。
[validator_list_sites]
https://vl.altnet.rippletest.net
[validator_list_keys]
ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
b. 以下のセクションを次のようにコメントアウトします。
# [validator_list_sites]
# https://vl.ripple.com
#
# [validator_list_keys]
# ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
3. `rippled`を再起動します。
4. `rippled`がXRP Test Netに接続していることを確認するため、サーバーで[server_infoメソッド][]を使用して、その結果をTest Net のパブリックサーバーの結果と比較します。両方のサーバーで`validated_ledger`オブジェクトの`seq`フィールドが同一である必要があります確認中にこの数が変化した場合は、12の差が生じる可能性があります
以下のコマンドは、`s.altnet.rippletest.net` にあるTest Net サーバーの最新の検証済みレジャーをチェックします。
4. `rippled`がXRP TestnetまたはDevnetに接続していることを確認するため、サーバーで[server_infoメソッド][]を使用して、その結果をTestnetまたはDevnetの公開サーバーの結果と比較します。両方のサーバーで`validated_ledger`オブジェクトの`seq`フィールドが同一である必要があります確認中にこの数が変化した場合は、12の差が生じる可能性があります
以下のコマンドは、`s.altnet.rippletest.net`にあるTestnetサーバーの最新の検証済みレジャーをチェックします。
$ ./rippled --rpc_ip 34.210.87.206:51234 server_info | grep seq
以下のコマンドは、ローカルの `rippled` の最新検証済みレジャーシーケンスをチェックします。
以下のコマンドは、`s.devnet.rippletest.net`にあるDevnetサーバーの最新検証済みレジャーをチェックします。
$ ./rippled --rpc_ip 34.83.125.234:51234 server_info | grep seq
以下のコマンドは、ローカルの`rippled`の最新検証済みレジャーインデックスをチェックします。
$ ./rippled server_info | grep seq
## 関連項目
- **ツール:**
- [XRP Faucet](xrp-testnet-faucet.html)
- [WebSocket APIツール](websocket-api-tool.html) - 接続オプションで「Testnet公開サーバー」を選択します。
- **コンセプト:**
- [並列ネットワーク](parallel-networks.html)
- [コンセンサスについて](intro-to-consensus.html)
- **チュートリアル:**
- [バリデータとしてのrippledの実行](run-rippled-as-a-validator.html)
- [スタンドアロンモードでの`rippled`のオフラインテスト](use-stand-alone-mode.html)
- `rippled`の[トラブルシューティング](troubleshoot-the-rippled-server.html)
- **リファレンス:**
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

View File

@@ -1,12 +1,12 @@
# バリデータとしてのrippledの実行
バリデータモードで実行されている`rippled`サーバーは、ストックサーバーが実行するあらゆる処理を実行します。
[バリデータモード](rippled-server-modes.html)で実行されている[`rippled`サーバー](the-rippled-server.html)は、ストックサーバーが実行するあらゆる処理を実行します。
- ピアのネットワークへの接続
- [ピアのネットワーク](consensus-network.html)への接続
- 暗号署名されたトランザクションの中継
- 暗号署名された[トランザクション](transaction-basics.html)の中継
- 共有グローバル台帳全体のローカルコピーの維持
- 完全な共有グローバル[レジャー](ledgers.html)のローカルコピーの維持
バリデータが _特異である_ のは、検証メッセージも発行するという点です。これらのメッセージは、[コンセンサスプロセス](consensus-principles-and-rules.html#コンセンサスの仕組み)の進行中、XRP Ledgerネットワークによる評価の対象となる候補のトランザクションです。
@@ -21,20 +21,20 @@
バリデータ(サーバー)が以下の特質を常に備えるよう努めます。優れたバリデータであることは、`rippled`サーバーの運用者や[https://vl.ripple.com](https://vl.ripple.com)などのバリデータリスト発行者が、バリデータを彼らのUNLに追加する際に、バリデータを信頼する上で後押しになります。
- **可用性**
優れたバリデータは、常に稼働し、提案されるあらゆるレジャーについて検証投票を送信します。100%のアップタイムを実現するよう努めてください。
優れたバリデータは、常に稼働し、提案されるあらゆるレジャーについて検証投票を送信します。100%のアップタイムを実現するよう努めてください。
- **合意**
優れたバリデータの投票は、可能な限り高い頻度で、コンセンサスプロセスの結果と合致します。これに該当しない場合は、バリデータのソフトウェアが最新のものではないか、不具合があるか、意図的な偏りがあることを示唆している可能性があります。常に[最新の`rippled`リリース](https://github.com/ripple/rippled/tree/master)を、修正を加えることなく実行します。新規リリースについて知るために、[`rippled`のリリースを確認](https://github.com/ripple/rippled/releases)してください。
優れたバリデータの投票は、可能な限り高い頻度で、コンセンサスプロセスの結果と合致します。これに該当しない場合は、バリデータのソフトウェアが最新のものではないか、不具合があるか、意図的な偏りがあることを示唆している可能性があります。常に[最新の`rippled`リリース](https://github.com/ripple/rippled/tree/master)を、修正を加えることなく実行します。新規リリースについて知るために、[`rippled`のリリースを確認](https://github.com/ripple/rippled/releases)してください。
- **適時の投票**
優れたバリデータの投票は、コンセンサスラウンドが終了する前に、素早く届きます。適時の投票を維持するには、バリデータが推奨される[システム要件](system-requirements.html)を満たしていることを確認してください。これには、高速のインターネット接続が含まれます。
優れたバリデータの投票は、コンセンサスラウンドが終了する前に、素早く届きます。適時の投票を維持するには、バリデータが推奨される[システム要件](system-requirements.html)を満たしていることを確認してください。これには、高速のインターネット接続が含まれます。
- **身元の確さ**
優れたバリデータには、身元が明確な所有者が存在します。[ドメイン検証](#6-ドメイン検証の提供)を提供することは、その第一歩になります。XRP LedgerネットワークのUNLに、多くの法的な管轄域および地域のさまざまな所有者によって運営されているバリデータが含まれていると理想的です。結果として、信頼できるバリデータの公正な運用が地域特有の事象によって損なわれるおそれが低減されます。
優れたバリデータには、身元が明確な所有者が存在します。[ドメイン検証](#6-ドメイン検証の提供)を提供することは、その第一歩になります。XRP LedgerネットワークのUNLに、多くの法的な管轄域および地域のさまざまな所有者によって運営されているバリデータが含まれていると理想的です。結果として、信頼できるバリデータの公正な運用が地域特有の事象によって損なわれるおそれが低減されます。
Ripple社は、推奨される一連のバリデータを記載した[バリデータリスト](https://github.com/ripple/rippled/blob/develop/cfg/validators-example.txt)を公開しています。本番環境のサーバーでは、このリストを使用することを強くお勧めします。
@@ -42,7 +42,7 @@ Ripple社は、推奨される一連のバリデータを記載した[バリデ
## 2. `rippled`サーバーのインストール
詳細については、[`rippled`のインストール](install-rippled.html)を参照してください。
詳細は、[`rippled`のインストール](install-rippled.html)を参照してください。
@@ -50,42 +50,42 @@ Ripple社は、推奨される一連のバリデータを記載した[バリデ
`rippled`サーバーで検証を有効にすることは、サーバーの`rippled.cfg`ファイルにあるバリデータトークンを提供することを意味します。バリデータキーとトークンを安全に生成して管理するために、`validator-keys`ツール(`rippled` RPMに含まれるを使用することをお勧めします。
バリデータ(サーバー)**以外の** 場所で、以下の手順に従います。
バリデータ(サーバー)**以外の**場所で、以下の手順に従います。
1. `validator-keys`ツールを`rippled` RPMを通じてまだインストールしていない場合は、手動でビルドして実行します。
`validator-keys`ツールを手動でビルドして実行する方法については、[validator-keys-tool](https://github.com/ripple/validator-keys-tool)を参照してください。
`validator-keys`ツールを手動でビルドして実行する方法については、[validator-keys-tool](https://github.com/ripple/validator-keys-tool)を参照してください。
2. `create_keys`コマンドを使用して、バリデータキーペアを生成します。
$ validator-keys create_keys
Ubuntuでの出力の例:
Ubuntuでの出力の例:
Validator keys stored in /home/my-user/.ripple/validator-keys.json
This file should be stored securely and not shared.
macOSでの出力の例:
macOSでの出力の例:
Validator keys stored in /Users/my-user/.ripple/validator-keys.json
This file should be stored securely and not shared.
**警告:** 生成した`validator-keys.json`キーファイルは、暗号化されたUSBフラッシュドライブなど、安全かつ回復可能なオフラインの場所に保管してください。内容には修正を加えないでください。特に、キーの使用場所となるバリデータにキーファイルを保存しないようにします。バリデータの`secret_key`が悪用された場合は、ただちに[キーを破棄](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md#key-revocation)します。
`validator-keys`ツールおよびツールで生成されるキーペアの詳細は、[Validator Keys Tool Guide](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)を参照してください。
**警告:** 生成した`validator-keys.json`キーファイルは、暗号化されたUSBフラッシュドライブなど、安全かつ回復可能なオフラインの場所に保管してください。内容には修正を加えないでください。特に、キーの使用場所となるバリデータにキーファイルを保存しないようにします。バリデータの`secret_key`が悪用された場合は、ただちに[キーを破棄](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md#key-revocation)します。
`validator-keys`ツールおよびツールで生成されるキーペアの詳細は、[Validator Keys Tool Guide](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)を参照してください。
3. `create_token`コマンドを使用して、バリデータトークンを生成します。
$ validator-keys create_token --keyfile /PATH/TO/YOUR/validator-keys.json
出力の例:
出力の例:
Update rippled.cfg file with these values:
# validator public key: nHUtNnLVx7odrz5dnfb2xpIgbEeJPbzJWfdicSkGyVw1eE5GpjQr
# validator public key: nHUtNnLVx7odrz5dnfb2xpIgbEeJPbzJWfdicSkGyVw1eE5GpjQr
[validator_token]
eyJ2YWxpZGF0aW9uX3NlY3J|dF9rZXkiOiI5ZWQ0NWY4NjYyNDFjYzE4YTI3NDdiNT
QzODdjMDYyNTkwNzk3MmY0ZTcxOTAyMzFmYWE5Mzc0NTdmYT|kYWY2IiwibWFuaWZl
@@ -99,100 +99,109 @@ Ripple社は、推奨される一連のバリデータを記載した[バリデ
バリデータ(サーバー)で、以下の手順に従います。
1. `[validator_token]`とその値を、バリデータの`rippled.cfg`ファイルに追加します。
以前に、`validator-keys`ツールを使用せずにバリデータを設定している場合は、`[validation_seed]`とその値を`rippled.cfg`ファイルから削除します。これにより、バリデータの公開鍵が変更されます。
以前に、`validator-keys`ツールを使用せずにバリデータを設定している場合は、`[validation_seed]`とその値を`rippled.cfg`ファイルから削除します。これにより、バリデータの公開鍵が変更されます。
2. `rippled`を再起動します。
$ sudo systemctl restart rippled.service
3. `server_info`コマンドを使用してバリデータの情報を取得し、バリデータとして実行されていることを確認します。
$ rippled server_info
- 応答に含まれている`pubkey_validator`の値は、バリデータで使用するために生成した`validator-keys.json`ファイルの`public_key`と一致している必要があります。
- `server_state`の値は、 _**proposing**_ にする必要があります。
- 応答に含まれている`pubkey_validator`の値は、バリデータで使用するために生成した`validator-keys.json`ファイルの`public_key`と一致している必要があります。
- `server_state`の値は、 _**proposing**_ にする必要があります。
**セキュリティのヒント:** `rippled.cfg`ファイルに対する権限をより制限的なものに変更します。Linuxでは、`0600`にすることを推奨します。`chmod 0600 rippled.cfg`を使用して変更できます。
## 4. ネットワークへの接続
バリデータのオペレーターが果たすべき重要な責任の1つは、信頼できる安全な接続によってバリデータXRP Ledgerネットワークに接続されるようにすることです。ネットワーク上の潜在的に悪意のあるピアに無作為に接続するのではなく、以下のいずれかの方法でネットワークに接続するようにバリデータに指示できます
このセクションでは、バリデータXRP Ledgerネットワークに接続するために使用できる3種類の構成について説明します。ユースケースに最適な構成を使用してください
- [公開ハブ](#公開ハブを使用した接続)
- [プロキシ](#プロキシを使用した接続)
- [検出されたピア](#検出されたピアを使用した接続): ピアツーピアネットワーク内の任意のサーバーに接続します。
これらのいずれかの構成を使用すると、[DDoS](https://en.wikipedia.org/wiki/Denial-of-service_attack)攻撃からバリデータを保護するとともに、ネットワークへの信頼できる接続をバリデータに提供する上で役立ちます。
- [プロキシ](#プロキシを使用した接続): ストック`rippled`サーバーを、バリデータとピアツーピアネットワークの他の部分との間のプロキシとして実行します。
- [公開ハブ](#公開ハブを使用した接続): 評価の高い特定の公開サーバーにのみ接続します。
これらのアプローチの違いについては、[ピア接続設定のメリットとデメリット](peer-protocol.html#ピア接続設定のメリットとデメリット)を参照してください。
### 公開ハブを使用した接続
### 検出されたピアを使用した接続
この構成では、ネットワークに接続している1つ以上の公開ハブにバリデータを接続します。適切に運用されている公開ハブには、以下の特徴があります。
この構成では、[検出されたピア](peer-protocol.html#ピアの検出)を使用してバリデータをXRP Ledgerネットワークに接続します。これは`rippled`サーバーのデフォルトの動作です。
- 十分な帯域幅
- 多数の信頼できるピアとの接続。
- メッセージを確実に中継する能力。
公開ハブに接続することの利点は、安全かつ信頼できる多くのネットワーク接続にアクセスしやすいことです。このような接続は、バリデータの健全性の維持に役立ちます。
公開ハブを使用してバリデータをネットワークに接続するには、バリデータの`rippled.cfg`ファイルで以下の構成を設定します。
1. 以下の`[ips_fixed]`スタンザを記述します。2つの値`r.ripple.com 51235``zaphod.alloy.ee 51235`が公開ハブです。このスタンザは、これらの公開ハブとのピア接続を常に維持するよう`rippled`に指示します。
[ips_fixed]
r.ripple.com 51235
zaphod.alloy.ee 51235
他の`rippled`サーバーのIPアドレスをここに記述することもできますが、それらのサーバーに対して以下の事項を期待できる場合に _**限ります**_
- メッセージを検閲することなく中継する。
- オンライン状態を常に維持する。
- サーバーに対するDDoS攻撃を実行しない。
- サーバーをクラッシュさせようとしない。
- 未知の相手にバリデータのIPアドレスを公開しない。
2. 以下の`[peer_private]`スタンザを記述し、`1`に設定します。この設定を有効にすると、バリデータのピアに対して、バリデータのIPアドレスをブロードキャストしないよう指示することになります。また、バリデータに対して、`[ips_fixed]`スタンザで設定されているピアにのみ接続するよう指示することになります。これにより、既知の信頼できるピア`rippled`サーバーに対してのみ、バリデータが接続を確立し、IPアドレスを共有することが保証されます。
**警告:** バリデータのIPアドレスを、その他の方法で公開していないことを確認してください。
[peer_private]
1
`[peer_private]`が有効になっている場合、`rippled`は、`[ips]`スタンザで指定されている接続をすべて無視します。現在`[ips]`スタンザにあるIPアドレスに接続する必要がある場合は、代わりに`[ips_fixed]`スタンザに記述します。ただし、それらのIPアドレスに対して、ステップ1で説明した挙動を期待できる場合に _**限ります**_
_**検出されたピアを使用してバリデータをXRP Ledgerネットワークに接続するには、**_ バリデータの`rippled.cfg`ファイルで`[peer_private]`スタンザを省略するか、それを`0`に設定します。この構成の[サンプルのrippled.cfgファイル](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg)が提供されています
### プロキシを使用した接続
この構成では、バリデータと発着信ネットワークトラフィックの間でプロキシとして使用するストック`rippled`サーバーを実行します。
この構成は、自社で運用するストック`rippled`サーバーを通じてバリデータをネットワークに接続します。これらのプロキシサーバーは、バリデータと発着信ネットワークトラフィックの間に設置します。
**注記:** これらのサーバーはプロキシとして動作しますが、HTTP(S)トラフィック用のWebプロキシではありません。
_**プロキシを使用してバリデータをXRP Ledgerネットワークに接続するには、次の手順を実行します。**_
この設定の利点は、自社で運用するプロキシサーバーを通じて、安全かつ信頼できる多くのネットワークへの接続の冗長性やアクセス性が高まることです。このような接続は、バリデータの健全性の維持に役立ちます
1. ストック`rippled`サーバーを設置します。詳細は、[rippledのインストール](install-rippled.html)を参照してください
2. バリデータとストック`rippled`サーバーを設定して、[クラスター](cluster-rippled-servers.html)内で実行します。
3. バリデータの`rippled.cfg`ファイルで、`[peer_private]``1`に設定します。そうすることで、バリデータのIPアドレスが転送されないようにします。詳細は、[プライベートピア](peer-protocol.html#プライベートピア)を参照してください。また、これによりクラスター内でバリデータを実行するよう`[ips_fixed]`スタンザで定義したサーバー以外のサーバーに、バリデータが接続しないようになります。
**警告:** バリデータのIPアドレスを、その他の方法で公開していないことを確認してください。
4. 以下のトラフィックのみを許可するように、バリデータのホストマシンのファイアウォールを構成します。
- 着信トラフィック: 構成したクラスター内にあるストック`rippled`サーバーのIPアドレスが発信元である場合のみ
- 発信トラフィック: 構成したクラスター内にあるストック`rippled`サーバーのIPアドレスおよびポート443経由の<https://vl.ripple.com>が送信先である場合のみ
5. `rippled`を再起動します。
$ sudo systemctl restart rippled.service
6. いずれかのストック`rippled`サーバーにある[ピアクローラー](peer-crawler.html)エンドポイントを使用します。応答には、バリデータが含まれていないはずです。これにより、バリデータの`[peer_private]`構成が機能していることが確認されます。バリデータの`[peer_private]`を有効にした場合の効果の1つは、バリデータのピアによって、ピアクローラーの結果にバリデータが含まれないことです。
$ curl --insecure https://STOCK_SERVER_IP_ADDRESS_HERE:51235/crawl | python3 -m json.tool
<!-- { TODO: Future: add a recommended network architecture diagram to represent the proxy, clustering, and firewall setup: https://ripplelabs.atlassian.net/browse/DOC-2046 }-->
1. `rippled`サーバーで[検証を有効に](#3-rippledサーバーで検証を有効化)します。
2. ストック`rippled`サーバーを設置します。詳細については、[rippledのインストール](install-rippled.html)を参照してください。
### 公開ハブを使用した接続
3. バリデータとストック`rippled`サーバーを設定して、[クラスター](cluster-rippled-servers.html)内で実行します。
この構成では、2つの[公開ハブ](rippled-server-modes.html#公開ハブ)を使用してバリデータをネットワークに接続します。この構成は、[自社で運用しているプロキシを使用した接続](#プロキシを使用した接続)と似ていますが、公開ハブを通じて接続します。
4. バリデータの`rippled.cfg`ファイルで、`[peer_private]``1`に設定してバリデータのIPアドレスが転送されないようにします。詳細については、[プライベートピア](peer-protocol.html#プライベートピア)を参照してください。
_**公開ハブを使用してバリデータをネットワークに接続するには、次の手順を実行します。**_
**警告:** バリデータのIPアドレスを、その他の方法で公開していないことを確認してください
1. バリデータの`rippled.cfg`ファイルに、次の`[ips_fixed]`スタンザを含めます。2つの値`r.ripple.com 51235``zaphod.alloy.ee 51235`がデフォルトの公開ハブです。このスタンザは、これらの公開ハブとのピア接続を常に維持するよう`rippled`に指示します
[ips_fixed]
r.ripple.com 51235
zaphod.alloy.ee 51235
**注意:** この構成では、デフォルトの公開ハブを使用してバリデータをネットワークに接続します。これらは _デフォルト_ の公開ハブであるため、ビジー状態になってバリデータにネットワークへの接続を提供できない場合があります。この問題を避けるために、接続する公開ハブの数を増やすか、デフォルトでない公開ハブに接続するようにします。
他の`rippled`サーバーのIPアドレスをここに記述することもできますが、それらのサーバーに対して以下の事項を期待できる場合に _**限ります**_
- メッセージを検閲することなく中継する。
- オンライン状態を常に維持する。
- サーバーに対するDDoS攻撃を実行しない。
- サーバーをクラッシュさせようとしない。
- 未知の相手にバリデータのIPアドレスを公開しない。
5. 以下のトラフィックのみを許可するように、バリデータのホストマシンのファイアウォールを構成します。
- 着信トラフィック: 構成したクラスター内にあるストック`rippled`サーバーのIPアドレスが発信元である場合のみ
- 発信トラフィック: 構成したクラスター内にあるストック`rippled`サーバーのIPアドレスおよびポート443経由の<https://vl.ripple.com>が送信先である場合のみ
6. `rippled`を再起動します。
2. また、バリデータの`rippled.cfg`ファイルに、次の`[peer_private]`スタンザを含めて、それを`1`に設定します。それにより、バリデータのピアに対して、バリデータのIPアドレスをブロードキャストしないよう指示することになります。また、バリデータに対して、`[ips_fixed]`スタンザで設定されているピアにのみ接続するよう指示することになります。これにより、既知の信頼できるピア`rippled`サーバーに対してのみ、バリデータが接続を確立し、IPアドレスを共有することが保証されます。
[peer_private]
1
**警告:** バリデータのIPアドレスを、その他の方法で公開していないことを確認してください。
`[peer_private]`が有効になっている場合、`rippled`は、`[ips]`スタンザで指定されている接続をすべて無視します。現在`[ips]`スタンザにあるIPアドレスに接続する必要がある場合は、代わりにそれを`[ips_fixed]`スタンザに記述します。ただし、それらのIPアドレスに対して、ステップ1で説明した確実な挙動を期待できる場合に _**限ります**_
3. `rippled`を再起動します。
$ sudo systemctl restart rippled.service
7. いずれかのストック`rippled`サーバーにある[ピアクローラー](peer-crawler.html)エンドポイントを使用します。応答には、バリデータが含まれていないはずです。これにより、バリデータの`[peer_private]`構成が機能していることが確認されます。バリデータの`[peer_private]`を有効にした場合の効果の1つは、バリデータのピアによって、ピアクローラーの結果にバリデータが含まれないことです。
## 5. ネットワーク接続の確認
@@ -200,14 +209,14 @@ Ripple社は、推奨される一連のバリデータを記載した[バリデ
ここでは、バリデータがXRP Ledgerネットワークへの健全な接続を保持していることを検証する方法をいくつか紹介します。
- [`peers`](peers.html)コマンドを使用して、バリデータに接続しているすべての`rippled`サーバーのリストを取得します。`peers`の配列が`null`である場合、ネットワークへの健全な接続が存在していません。このドキュメントの手順に従ってバリデータを設置した場合、`peers`の配列には、`[ips_fixed]`スタンザで定義されているピアの数と同数のオブジェクトが含まれています。
公開ハブを`[ips_fixed]`スタンザに記述した場合、そのハブがビジーになっているときは、バリデータの接続が拒否されることがあります。この場合、接続の数は、`[ips_fixed]`スタンザで設定した数よりも最終的に少なくなることがあります。初めて拒否された場合、バリデータは接続を再試行します。
ネットワークへの安全かつ信頼できる接続を維持することが困難であり、公開ハブまたはプロキシを使用して接続を設定していない場合、[4. ネットワークへの接続](#4-ネットワークへの接続)を参照してください。このセクションで説明されているいずれかの方法は、バリデータがネットワークへの健全な接続を維持する上で有用となる可能性があります。
公開ハブを`[ips_fixed]`スタンザに記述した場合、そのハブがビジーになっているときは、バリデータの接続が拒否されることがあります。この場合、接続の数は、`[ips_fixed]`スタンザで設定した数よりも最終的に少なくなることがあります。初めて拒否された場合、バリデータは接続を再試行します。
ネットワークへの安全かつ信頼できる接続を維持することが困難であり、公開ハブまたはプロキシを使用して接続を設定していない場合、[4. ネットワークへの接続](#4-ネットワークへの接続)を参照してください。このセクションで説明されているいずれかの方法は、バリデータがネットワークへの健全な接続を維持する上で有用となる可能性があります。
- [`server_info`](server_info.html)コマンドを使用して、バリデータに関するいくつかの基本情報を取得します。`server_state`は、`proposing`に設定されているはずです。`full`または`validating`に設定されている場合もありますが、`proposing`に移行するまでの数分間に限られます。
`server_state``proposing`に設定されている時間が大部分を占めていない場合、XRP Ledgerネットワークにバリデータが完全に参加できていないことを示している可能性があります。サーバーの状態および`server_info`エンドポイントを使用してバリデータの問題を診断する方法の詳細は、[`rippled`サーバーの状態](rippled-server-states.html)および[`server_info`の取得](diagnosing-problems.html#server_infoの取得)を参照してください。
`server_state``proposing`に設定されている時間が大部分を占めていない場合、XRP Ledgerネットワークにバリデータが完全に参加できていないことを示している可能性があります。サーバーの状態および`server_info`エンドポイントを使用してバリデータの問題を診断する方法の詳細は、[`rippled`サーバーの状態](rippled-server-states.html)および[`server_info`の取得](diagnosing-problems.html#server_infoの取得)を参照してください。
- [`validators`](validators.html)コマンドを使用して、バリデータによって使用される、公開済みかつ信頼できるバリデータの最新リストを取得します。`validator_list_expires`の値が、`never`(無期限)、期限が切れていない、または期限切れ間近のいずれかであることを確認してください。
@@ -225,37 +234,37 @@ Ripple社は、推奨される一連のバリデータを記載した[バリデ
ドメイン検証を提供するには、以下の手順に従います。
1. バリデータと公に関連付ける、所有しているドメインの名前を選択します。そのドメインのポート443で外部に公開されるHTTPSサーバーを実行中であり、そのサーバーのTLS証明書に関連付けられている秘密鍵ファイルへのアクセス権を持っている必要があります。注記: [TLSの旧称はSSLです](https://en.wikipedia.org/wiki/Transport_Layer_Security)
1. バリデータと公に関連付ける、所有しているドメインの名前を選択します。そのドメインのポート443で外部に公開されるHTTPSサーバーを実行中であり、そのサーバーのTLS証明書に関連付けられている秘密鍵ファイルへのアクセス権を持っている必要があります。注記: [TLSの旧称はSSLです](https://en.wikipedia.org/wiki/Transport_Layer_Security)DDoS攻撃への対策として、ドメイン名によってバリデータのIPアドレスが解決されないようにする必要があります
2. バリデータの公開鍵を公開し、特に他の`rippled`オペレーターに知らせます。例えば、Webサイト、ソーシャルメディア、[XRPChatコミュニティーフォーラム](https://www.xrpchat.com/)、またはプレスリリースでバリデータの公開鍵を公表できます。
3. この[Googleフォーム](https://docs.google.com/forms/d/e/1FAIpQLScszfq7rRLAfArSZtvitCyl-VFA9cNcdnXLFjURsdCQ3gHW7w/viewform)を使用して、自身のバリデータをXRP Chartsの[バリデータレジストリー](https://xrpcharts.ripple.com/#/validators)に登録するための要求を送信します。バリデータをこのレジストリーに登録することは、そのバリデータとドメインを所有していることを示す、別の形での公的な証拠になります。フォームに漏れなく記入するには、以下の情報が必要です。
1. バリデータのサーバーで以下のコマンドを実行して、バリデータの公開鍵を検出します。
$ /opt/ripple/bin/rippled server_info | grep pubkey_validator
返された値を、Googleフォームの**Validator Public Key**フィールドに入力します。
2. WebドメインのTLS秘密鍵を使用して、バリデータの公開鍵に署名します。TLS秘密鍵ファイルをバリデータのサーバーに保存する必要はありません。
$ openssl dgst -sha256 -hex -sign /PATH/TO/YOUR/TLS.key <(echo YOUR_VALIDATOR_PUBLIC_KEY_HERE)
出力の例:
1. バリデータのサーバーで以下のコマンドを実行して、バリデータの公開鍵を検出します。
$ /opt/ripple/bin/rippled server_info | grep pubkey_validator
返された値を、Googleフォームの**Validator Public Key**フィールドに入力します。
2. WebドメインのTLS秘密鍵を使用して、バリデータの公開鍵に署名します。TLS秘密鍵ファイルをバリデータのサーバーに保存する必要はありません。
$ openssl dgst -sha256 -hex -sign /PATH/TO/YOUR/TLS.key <(echo YOUR_VALIDATOR_PUBLIC_KEY_HERE)
出力の例:
4a8b84ac264d18d116856efd2761a76f3f4544a1fbd82b9835bcd0aa67db91c53342a1ab197ab1ec4ae763d8476dd92fb9c24e6d9de37e3594c0af05d0f14fd2a00a7a5369723c019f122956bf3fc6c6b176ed0469c70c864aa07b4bf73042b1c7cf0b2c656aaf20ece5745f54ab0f78fab50ebd599e62401f4b57a4cccdf8b76d26f4490a1c51367e4a36faf860d48dd2f98a6134ebec1a6d92fadf9f89aae67e854f33e1acdcde12cfaf5f5dbf1b6a33833e768edbb9ff374cf4ae2be21dbc73186a5b54cc518f63d6081919e6125f7daf9a1d8e96e3fdbf3b94b089438221f8cfd78fd4fc85c646b288eb6d22771a3ee47fb597d28091e7aff38a1e636b4f
返された値を、Googleフォームの**SSL Signature**フィールドに入力します。
3. [`validator-keys`ツール](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)`rippled`のRPMに収録を使用して、ドメイン名に署名します。
$ validator-keys --keyfile /PATH/TO/YOUR/validator-keys.json sign YOUR_DOMAIN_NAME
出力の例:
返された値を、Googleフォームの**SSL Signature**フィールドに入力します。
3. [`validator-keys`ツール](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)`rippled`のRPMに収録を使用して、ドメイン名に署名します。
$ validator-keys --keyfile /PATH/TO/YOUR/validator-keys.json sign YOUR_DOMAIN_NAME
出力の例:
E852C2FE725B64F353E19DB463C40B1ABB85959A63B8D09F72C6B6C27F80B6C72ED9D5ED6DC4B8690D1F195E28FF1B00FB7119C3F9831459F3C3DE263B73AC04
返された値を、Googleフォームの**Domain Signature**フィールドに入力します。
返された値を、Googleフォームの**Domain Signature**フィールドに入力します。
4. 記入したGoogleフォームを送信すると、ドメイン検証の成否を通知するメールがXRP Chartsから送信されます。ドメイン検証が成功した場合は、XRP Chartsの[バリデータレジストリー](https://xrpcharts.ripple.com/#/validators)にバリデータとドメインが表示されます。
@@ -268,3 +277,27 @@ Ripple社は、推奨される一連のバリデータを記載した[バリデ
バリデータのマスター秘密鍵が漏えいした場合は、ただちに永続的に破棄する必要があります。
`validator-keys`ツールでバリデータ用に生成したマスターキーペアを破棄する方法については、[Key Revocation](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md#key-revocation)を参照してください。
## 関連項目
- **コンセプト:**
- [XRP Ledgerの概要](xrp-ledger-overview.html)
- [コンセンサスネットワーク](consensus-network.html)
- [`rippled`サーバー](the-rippled-server.html)
- **チュートリアル:**
- [rippledサーバーのクラスター化](cluster-rippled-servers.html)
- [`rippled`のインストール](install-rippled.html)
- [容量の計画](capacity-planning.html)
- [XRP Ledgerのビジネス](xrp-ledger-businesses.html)
- **リファレンス:**
- [Validator Keysツールガイド](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)
- [consensus_infoメソッド][]
- [validator_list_sitesメソッド][]
- [validatorsメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}