ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-04 11:55:50 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
10c974249fe1e1377f7b80cf1a3efb14aa8bb877
xrpl-dev-portal/@l10n/ja/docs/infrastructure/configuration/server-modes/run-rippled-as-a-validator.md
mDuo13 0e67c48fb8 Remove old/inadvertent TODOs 
Neither of these TODOs is relevant at the moment and they should not be
visible to readers (even in the HTML comments)
2025-08-29 13:45:43 -07:00

27 KiB
Raw Blame History

html, parent, seo, labels, top_nav_grouping, top_nav_name
html parent seo labels top_nav_grouping top_nav_name
run-rippled-as-a-validator.html server-modes.html
description
サーバがコンセンサスレジャーで投票できるようにします。
コアサーバ
ブロックチェーン
人気ページ UNLに参加しよう

バリデータとしてのrippledの実行

バリデータモードで実行されているrippledサーバは、ストックサーバが実行するあらゆる処理を実行します。

バリデータが 特異である のは、検証メッセージも発行するという点です。これらのメッセージは、コンセンサスプロセスの進行中、XRP Ledgerネットワークによる評価の対象となる候補のトランザクションです。

ただし、単に検証メッセージを発行するだけで、バリデータにコンセンサスプロセスでの発言権が自動的に付与されるわけではありません。他のサーバがバリデータ（モードのサーバ）を彼らのユニークノードリスト（UNL）に追加しない限り、彼らは（バリデータモードのサーバからの）検証メッセージを無視します。バリデータがUNLに含まれている場合、 信頼できる バリデータであり、その提案は、信頼する側のサーバによってコンセンサスプロセスで検討されます。

バリデータが 信頼できる バリデータではない場合も、ネットワークの全体的な健全性に関して、重要な役割を果たすことに変わりはありません。これらのバリデータは、信頼できるバリデータを評価するための基準の確立を支援します。例えば、信頼できるバリデータが、UNLに含まれていない多数のバリデータに対して異議を唱えている場合、問題があることを示しているおそれがあります。

{% admonition type="warning" name="注意" %}バリデータは外部からはアクセスするべきものではありません。バリデータサーバへの一般からのWebSocketアクセスやその他の一般からのアクセスを許可してはいけません。{% /admonition %}

1. 優れたバリデータの特徴の理解

バリデータ（サーバ）が以下の特質を常に備えるよう努めます。優れたバリデータであることは、rippledサーバの運用者やバリデータリスト発行者(https://vl.ripple.com や https://vl.xrplf.orgなど)が、バリデータを彼らのUNLに追加する際に、バリデータを信頼する上で後押しになります。

  • 可用性

    優れたバリデータは、常に稼働し、提案されるあらゆるレジャーについて検証投票を送信します。100%のアップタイムを実現するよう努めてください。

  • 合意

    優れたバリデータの投票は、可能な限り高い頻度で、コンセンサスプロセスの結果と合致します。これに該当しない場合は、バリデータのソフトウェアが最新のものではないか、不具合があるか、意図的な偏りがあることを示唆している可能性があります。常に最新のrippledリリースを、修正を加えることなく実行します。新規リリースについて知るために、rippledのリリースを確認してください。

  • 適時の投票

    優れたバリデータの投票は、コンセンサスラウンドが終了する前に、素早く届きます。適時の投票を維持するには、バリデータが推奨されるシステム要件を満たしていることを確認してください。これには、高速のインターネット接続が含まれます。

    バリデータを使って新しいトランザクションを送信したりデータを検索したりすることは可能ですが、APIクエリの負荷が高くなるとバリデータがコンセンサスに追いつけなくなる可能性があります。APIの負荷が十分軽ければ、サーバを両方の目的に使うことができます。理想的には、バリデータはコンセンサスに参加するために特化したものであるべきです。

  • 身元の確さ

    優れたバリデータには、身元が明確な所有者が存在します。ドメイン検証を提供することは、その第一歩になります。XRP LedgerネットワークのUNLに、多くの法的な管轄域および地域のさまざまな所有者によって運営されているバリデータが含まれていると理想的です。結果として、信頼できるバリデータの公正な運用が地域特有の事象によって損なわれるおそれが低減されます。

運用者はexampleファイルに存在するバリデータリストを使用することを強くお勧めします。

2. rippledサーバのインストール

詳細は、rippledのインストールをご覧ください。

3. rippledサーバで検証を有効化

rippledサーバで検証を有効にすることは、サーバのrippled.cfgファイルにあるバリデータトークンを提供することを意味します。バリデータキーとトークンを安全に生成して管理するために、validator-keysツール（rippled RPMに含まれる）を使用することをお勧めします。

バリデータ（サーバ）以外の場所で、以下の手順に従います。

  1. validator-keysツールをrippled RPMを通じてまだインストールしていない場合は、手動でビルドして実行します。

    validator-keysツールを手動でビルドして実行する方法については、validator-keys-toolをご覧ください。

  2. create_keysコマンドを使用して、バリデータキーペアを生成します。

    $ validator-keys create_keys

    Ubuntuでの出力の例:

    Validator keys stored in /home/my-user/.ripple/validator-keys.json

This file should be stored securely and not shared.

    macOSでの出力の例:

    Validator keys stored in /Users/my-user/.ripple/validator-keys.json

This file should be stored securely and not shared.

    {% admonition type="danger" name="警告" %}生成したvalidator-keys.jsonキーファイルは、暗号化されたUSBフラッシュドライブなど、安全かつ回復可能なオフラインの場所に保管してください。内容には修正を加えないでください。特に、キーの使用場所となるバリデータにキーファイルを保存しないようにします。バリデータのsecret_keyが悪用された場合は、ただちにキーを破棄します。{% /admonition %}

    validator-keysツールおよびツールで生成されるキーペアの詳細は、Validator Keys Tool Guideをご覧ください。

  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_token]
 eyJ2YWxpZGF0aW9uX3NlY3J|dF9rZXkiOiI5ZWQ0NWY4NjYyNDFjYzE4YTI3NDdiNT
 QzODdjMDYyNTkwNzk3MmY0ZTcxOTAyMzFmYWE5Mzc0NTdmYT|kYWY2IiwibWFuaWZl
 c3QiOiJKQUFBQUFGeEllMUZ0d21pbXZHdEgyaUNjTUpxQzlnVkZLaWxHZncxL3ZDeE
 hYWExwbGMyR25NaEFrRTFhZ3FYeEJ3RHdEYklENk9NU1l1TTBGREFscEFnTms4U0tG
 bjdNTzJmZGtjd1JRSWhBT25ndTlzQUtxWFlvdUorbDJWMFcrc0FPa1ZCK1pSUzZQU2
 hsSkFmVXNYZkFpQnNWSkdlc2FhZE9KYy9hQVpva1MxdnltR21WcmxIUEtXWDNZeXd1
 NmluOEhBU1FLUHVnQkQ2N2tNYVJGR3ZtcEFUSGxHS0pkdkRGbFdQWXk1QXFEZWRGdj
 VUSmEydzBpMjFlcTNNWXl3TFZKWm5GT3I3QzBrdzJBaVR6U0NqSXpkaXRROD0ifQ==

バリデータ（サーバ）で、以下の手順に従います。

  1. [validator_token]とその値を、バリデータの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 にする必要があります。

セキュリティのヒント: rippled.cfgファイルに対する権限をより制限的なものに変更します。Linuxでは、0600にすることを推奨します。chmod 0600 rippled.cfgを使用して変更できます。

4. ネットワークへの接続

このセクションでは、バリデータをXRP Ledgerネットワークに接続するために使用できる3種類の構成について説明します。ユースケースに最適な構成を使用してください。

  • 検出されたピア: ピアツーピアネットワーク内の任意のサーバに接続します。

  • プロキシ: ストックrippledサーバを、バリデータとピアツーピアネットワークの他の部分との間のプロキシとして実行します。

  • 公開ハブ: 評価の高い特定の公開サーバにのみ接続します。

これらのアプローチの違いについては、ピア接続設定のメリットとデメリットをご覧ください。

検出されたピアを使用した接続

この構成では、検出されたピアを使用してバリデータをXRP Ledgerネットワークに接続します。これはrippledサーバのデフォルトの動作です。

検出されたピアを使用してバリデータをXRP Ledgerネットワークに接続するには、 バリデータのrippled.cfgファイルで[peer_private]スタンザを省略するか、それを0に設定します。この構成のサンプルのrippled.cfgファイルが提供されています。

プロキシを使用した接続

この構成は、自社で運用するストックrippledサーバを通じてバリデータをネットワークに接続します。これらのプロキシサーバは、バリデータと発着信ネットワークトラフィックの間に設置します。

プロキシを使用してバリデータをXRP Ledgerネットワークに接続するには、次の手順を実行します。

  1. ストックrippledサーバを設置します。詳細は、rippledのインストールをご覧ください。

  2. バリデータとストックrippledサーバを設定して、クラスター内で実行します。

  3. バリデータのrippled.cfgファイルで、[peer_private]を1に設定します。そうすることで、バリデータのIPアドレスが転送されないようにします。詳細は、プライベートピアをご覧ください。また、これによりクラスター内でバリデータを実行するよう[ips_fixed]スタンザで定義したサーバ以外のサーバに、バリデータが接続しないようになります。

    {% admonition type="danger" name="警告" %}バリデータのIPアドレスを、その他の方法で公開していないことを確認してください。{% /admonition %}

  4. 以下のトラフィックのみを許可するように、バリデータのホストマシンのファイアウォールを構成します。

    • 着信トラフィック: 構成したクラスター内にあるストックrippledサーバのIPアドレスが発信元である場合のみ

    • 発信トラフィック: 構成したクラスター内にあるストックrippledサーバのIPアドレスおよびポート443経由のhttps://vl.ripple.comが送信先である場合のみ

  5. rippledを再起動します。

    $ sudo systemctl restart rippled.service

  6. いずれかのストックrippledサーバにあるピアクローラーエンドポイントを使用します。レスポンスには、バリデータが含まれていないはずです。これにより、バリデータの[peer_private]構成が機能していることが確認されます。バリデータの[peer_private]を有効にした場合の効果の1つは、バリデータのピアによって、ピアクローラーの結果にバリデータが含まれないことです。

    $ curl --insecure https://STOCK_SERVER_IP_ADDRESS_HERE:51235/crawl | python3 -m json.tool

公開ハブを使用した接続

この構成では、2つの公開ハブを使用してバリデータをネットワークに接続します。この構成は、自社で運用しているプロキシを使用した接続と似ていますが、公開ハブを通じて接続します。

公開ハブを使用してバリデータをネットワークに接続するには、次の手順を実行します。

  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

    {% admonition type="warning" name="注意" %}この構成では、デフォルトの公開ハブを使用してバリデータをネットワークに接続します。これらは デフォルト の公開ハブであるため、ビジー状態になってバリデータにネットワークへの接続を提供できない場合があります。この問題を避けるために、接続する公開ハブの数を増やすか、デフォルトでない公開ハブに接続するようにします。{% /admonition %}

    他のrippledサーバのIPアドレスをここに記述することもできますが、それらのサーバに対して以下の事項を期待できる場合に 限ります 。

    • メッセージを検閲することなく中継する。
    • オンライン状態を常に維持する。
    • サーバに対するDDoS攻撃を実行しない。
    • サーバをクラッシュさせようとしない。
    • 未知の相手にバリデータのIPアドレスを公開しない。

  2. また、バリデータのrippled.cfgファイルに、次の[peer_private]スタンザを含めて、それを1に設定します。それにより、バリデータのピアに対して、バリデータのIPアドレスをブロードキャストしないよう指示することになります。また、バリデータに対して、[ips_fixed]スタンザで設定されているピアにのみ接続するよう指示することになります。これにより、既知の信頼できるピアrippledサーバに対してのみ、バリデータが接続を確立し、IPアドレスを共有することが保証されます。

    [peer_private]
1

    {% admonition type="danger" name="警告" %}バリデータのIPアドレスを、その他の方法で公開していないことを確認してください。{% /admonition %}

    [peer_private]が有効になっている場合、rippledは、[ips]スタンザで指定されている接続をすべて無視します。現在[ips]スタンザにあるIPアドレスに接続する必要がある場合は、代わりにそれを[ips_fixed]スタンザに記述します。ただし、それらのIPアドレスに対して、ステップ1で説明した確実な挙動を期待できる場合に 限ります 。

  3. rippledを再起動します。

    $ sudo systemctl restart rippled.service

5. ネットワーク接続の確認

ここでは、バリデータがXRP Ledgerネットワークへの健全な接続を保持していることを検証する方法をいくつか紹介します。

  • peersコマンドを使用して、バリデータに接続しているすべてのrippledサーバのリストを取得します。peersの配列がnullである場合、ネットワークへの健全な接続が存在していません。このドキュメントの手順に従ってバリデータを設置した場合、peersの配列には、[ips_fixed]スタンザで定義されているピアの数と同数のオブジェクトが含まれています。

    公開ハブを[ips_fixed]スタンザに記述した場合、そのハブがビジーになっているときは、バリデータの接続が拒否されることがあります。この場合、接続の数は、[ips_fixed]スタンザで設定した数よりも最終的に少なくなることがあります。初めて拒否された場合、バリデータは接続を再試行します。

    ネットワークへの安全かつ信頼できる接続を維持することが困難であり、公開ハブまたはプロキシを使用して接続を設定していない場合、4. ネットワークへの接続をご覧ください。このセクションで説明されているいずれかの方法は、バリデータがネットワークへの健全な接続を維持する上で有用となる可能性があります。

  • server_infoコマンドを使用して、バリデータに関するいくつかの基本情報を取得します。server_stateは、proposingに設定されているはずです。fullまたはvalidatingに設定されている場合もありますが、proposingに移行するまでの数分間に限られます。

    server_stateがproposingに設定されている時間が大部分を占めていない場合、XRP Ledgerネットワークにバリデータが完全に参加できていないことを示している可能性があります。サーバの状態およびserver_infoエンドポイントを使用してバリデータの問題を診断する方法の詳細は、rippledサーバの状態およびserver_infoの取得をご覧ください。

  • validatorsコマンドを使用して、バリデータによって使用される、公開済みかつ信頼できるバリデータの最新リストを取得します。validator_list_expiresの値が、never（無期限）、期限が切れていない、または期限切れ間近のいずれかであることを確認してください。

6. ドメイン検証の提供

検証リスト発行者およびXRP Ledgerネットワーク内のその他の参加者がバリデータの運用元を把握しやすいようにするには、バリデータのドメイン検証を提供します。ドメイン検証とは、ハイレベルでは双方向リンクを指します。

  • ドメインを使用して、バリデータキーの所有権を主張します。

  • バリデータキーを使用して、ドメインの所有権を主張します。

このリンクを作成すると、バリデータキーとドメインの両方を所有しているという確固たる証拠が確立されます。この証拠を提供することは、優れたバリデータであることの側面の1つにすぎません。

ドメイン検証を提供するには、以下の手順に従います。

  1. バリデータと公に関連付ける、所有しているドメインの名前を選択します。そのドメインのポート443で外部に公開されるHTTPSサーバを実行中であり、そのサーバのTLS証明書に関連付けられている秘密鍵ファイルへのアクセス権を持っている必要があります。（注記: TLSの旧称はSSLです。）DDoS攻撃への対策として、ドメイン名によってバリデータのIPアドレスが解決されないようにする必要があります。

  2. バリデータの公開鍵を公開し、特に他のrippledオペレーターに知らせます。例えば、Webサイト、ソーシャルメディア、XRPChatコミュニティーフォーラム、またはプレスリリースでバリデータの公開鍵を公表できます。

  3. このGoogleフォームを使用して、自身のバリデータをXRP Chartsのバリデータレジストリーに登録するためのリクエストを送信します。バリデータをこのレジストリーに登録することは、そのバリデータとドメインを所有していることを示す、別の形での公的な証拠になります。フォームに漏れなく記入するには、以下の情報が必要です。

    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ツール（rippledのRPMに収録）を使用して、ドメイン名に署名します。

      $ validator-keys --keyfile /PATH/TO/YOUR/validator-keys.json sign YOUR_DOMAIN_NAME

      出力の例:

  E852C2FE725B64F353E19DB463C40B1ABB85959A63B8D09F72C6B6C27F80B6C72ED9D5ED6DC4B8690D1F195E28FF1B00FB7119C3F9831459F3C3DE263B73AC04

返された値を、Googleフォームの**Domain Signature**フィールドに入力します。

  4. 記入したGoogleフォームを送信すると、ドメイン検証の成否を通知するメールがXRP Chartsから送信されます。ドメイン検証が成功した場合は、XRP Chartsのバリデータレジストリーにバリデータとドメインが表示されます。

バリデータキーの破棄

バリデータのマスター秘密鍵が漏えいした場合は、ただちに永続的に破棄する必要があります。

validator-keysツールでバリデータ用に生成したマスターキーペアを破棄する方法については、Key Revocationをご覧ください。

関連項目

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