mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-20 11:45:50 +00:00
Update Japanese translation files
This commit is contained in:
mDuo13
@@ -11,23 +11,24 @@ XRP Ledgerのサーバーは、XRP Ledgerピアプロトコル（RTXP）を使
|
||||
|
||||
ピアツーピア接続を確立するには、サーバーどうしをHTTPSで接続し、一方のサーバーはRTXPへの切り替えのために[HTTPアップグレード](https://tools.ietf.org/html/rfc7230#section-6.7)を要求します。（詳細は、[`rippled`リポジトリ](https://github.com/ripple/rippled)の[Overlay Network](https://github.com/ripple/rippled/blob/906ef761bab95f80b0a7e0cab3b4c594b226cf57/src/ripple/overlay/README.md#handshake)を参照してください。）
|
||||
|
||||
## ピア発見
|
||||
## ピアの検出
|
||||
|
||||
**Note:** この部分は日本語ではまだ利用できません。助けたいと思うなら、[提供して下さい！](https://github.com/ripple/xrpl-dev-portal#contributing)
|
||||
XRP Ledgerでは、「ゴシップ」プロトコルを使用して、XRP Ledgerネットワーク内でサーバーが互いを識別できるようにします。サーバーは、起動するたびに、以前に接続したその他のあらゆるピアに再接続します。フォールバックとして、[ハードコーディングされた公開ハブ](https://github.com/ripple/rippled/blob/fa57859477441b60914e6239382c6fba286a0c26/src/ripple/overlay/impl/OverlayImpl.cpp#L518-L525)を使用します。サーバーがピアに正常に接続されると、ピアを探している他のXRP Ledgerサーバーの接続情報（通常はIPアドレスとポート）をそのピアに要求します。その後、サーバーはそれらのサーバーに接続し、ピア接続するXRP Ledgerサーバーの接続情報をさらに要求できます。このプロセスにより、サーバーは十分なピア接続を確立し、単一のピアへの接続が失われた場合でも、ネットワークの残りの部分にその後も接続されます。
|
||||
|
||||
The XRP Ledger uses a "gossip" protocol to help find servers find others to connect to in the XRP Ledger network. Whenever a server starts up, it reconnects to any other peers it previously connected to. As a fallback, it uses the [hardcoded public hubs](https://github.com/ripple/rippled/blob/fa57859477441b60914e6239382c6fba286a0c26/src/ripple/overlay/impl/OverlayImpl.cpp#L518-L525). After a server successfully connects to a peer, it asks that peer for the contact information (generally, IP address and port) of other XRP Ledger servers that may also be seeking peers. The server can then connect to those servers, and ask them for the contact information of yet more XRP Ledger servers to peer with. Through this process, the server establishes enough peer connections that it can remain reliably connected to the rest of the network even if it loses a connection to any single peer.
|
||||
通常、サーバーが公開ハブに接続する必要があるのは1回のみです。他のピアを見つけるために、短時間のみ接続します。そうすることで、ネットワーク接続の安定性、ハブのビジー状態、およびサーバーが検出する他の高品質ピアの数に応じて、ハブにサーバーを引き続き接続するかどうかが異なります。サーバーでは、これらの他のピアのアドレスを保存するため、ネットワークの停止後または再起動後、それらのピアへの直接再接続を試行できます。
|
||||
|
||||
Typically, a server needs to connect to a public hub only once, for a short amount of time, to find other peers. After doing so, the server may or may not remain connected to the hub, depending on how stable its network connection is, how busy the hub is, and how many other high-quality peers the server finds. The server saves the addresses of these other peers so it can try reconnecting directly to those peers later, after a network outage or a restart.
|
||||
[peersメソッド][]は、サーバーが現在接続しているピアのリストを示します。
|
||||
|
||||
The [peers method][] shows a list of peers your server is currently connected to.
|
||||
価値の高いサーバー（重要な[バリデータ](rippled-server-modes.html#rippledサーバーのモード)など）によっては、ピア検出プロセスを通じて、サーバーを信頼性の低いピアに接続しないようにする場合があります。この場合、[プライベートピア](#プライベートピア)のみを使用するようにサーバーを構成できます。
|
||||
|
||||
For certain high-value servers (such as important [validators](rippled-server-modes.html)) you may prefer not to have your server connect to untrusted peers through the peer discovery process. In this case, you can configure your server to use [private peers](#プライベートピア) only.
|
||||
|
||||
## ピアプロトコルポート
|
||||
|
||||
XRP Ledgerに参加するため、`rippled`サーバーはピアプロトコルを使用して任意のピアに接続します。（すべてのピアは、現行サーバーで[クラスター化されている](clustering.html)場合を除き、信頼できないものとして扱われます。）
|
||||
|
||||
サーバーがピアポートで接続を送信 _かつ_ 受信できることが理想的です。ピアプロトコルに使用するポートを、ファイアウォール経由で`rippled`サーバーに転送する必要があります。[デフォルトの`rippled`構成ファイル](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg)は、すべてのネットワークインターフェイスでポート51235で着信ピアプロトコル接続を待機します。使用するポートを変更するには、`rippled.cfg`ファイル内の該当するスタンザを編集します。
|
||||
サーバーがピアポートで接続を送信 _かつ_ 受信できることが理想的です。`rippled`サーバーに、[ファイアウォール経由でピアプロトコルに使用するポートを転送する](forward-ports-for-peering.html)必要があります。
|
||||
|
||||
[デフォルトの`rippled`構成ファイル](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg)は、すべてのネットワークインターフェイスにおいて、ポート51235で着信ピアプロトコル接続をリッスンします。使用するポートを変更するには、`rippled.cfg`ファイル内の該当するスタンザを編集します。
|
||||
|
||||
例:
|
||||
|
||||
@@ -46,45 +47,120 @@ protocol = peer
|
||||
|
||||
ノードキーペアはデータベースに保存され、サーバーの再起動時に再利用されます。サーバーのデータベースを削除すると、新しいノードキーペアが作成され、異なるアイデンティティでオンラインになります。データベースが削除されても同じキーペアを再利用するには、`[node_seed]`スタンザを使用してサーバーを設定できます。`[node_seed]`スタンザでの使用に適した値を生成するには、[validation_createメソッド][]を使用します。
|
||||
|
||||
ノードキーペアは、このサーバーと共に[クラスター化](clustering.html)されている他のサーバーも識別します。サーバークラスターを使用している場合、一意の`[node_seed]`設定を使用してクラスター内の各サーバーを構成する必要があります。クラスターの設定についての詳細は、[`rippled`サーバーのクラスター化](cluster-rippled-servers.html)を参照してください。
|
||||
また、ノードキーペアは、[ピアスロットの](#固定ピアとピアリザベーション)[クラスタリング](clustering.html)または[確保](#固定ピアとピアリザベーション)のために他のサーバーも識別します。サーバークラスターを使用している場合、一意の`[node_seed]`設定を使用してクラスター内の各サーバーを構成する必要があります。クラスターの設定についての詳細は、[`rippled`サーバーのクラスター化](cluster-rippled-servers.html)を参照してください。
|
||||
|
||||
|
||||
## Fixed Peers and Peer Reservations
|
||||
<a id="pros-and-cons-of-peering-configurations"></a> <!-- TODO: remove this anchor when the corresponding section is translated -->
|
||||
## 固定ピアとピアリザベーション
|
||||
|
||||
**注意:** 現在の所はこの部分は日本語では利用できません。[英語版](/{{currentpage.html}})をご覧下さい。
|
||||
通常、`rippled`サーバーでは多数のピアを維持するよう試みるため、信頼性の低いピアの最大数まで自動接続されます。特定のピアサーバーへの接続を維持するように`rippled`サーバーを構成するには、いくつかの方法があります。
|
||||
|
||||
- **固定ピア**を使用して、IPアドレスに基づき特定の他のピアへの接続を維持します。これは、ピアのIPアドレスが固定されている場合にのみ機能します。固定ピアを構成するには、構成スタンザ`[ips_fixed]`を使用します。これは、[クラスタリング](clustering.html)または[プライベートピア](#プライベートピア)の重要な部分です。固定ピアは構成ファイルで定義されているため、変更を適用するにはサーバーを再起動する必要があります。サーバーが同じユーザーまたは組織によって実行されている場合、固定ピアは、サーバーの接続状態を維持するのに最も有益です。
|
||||
- **ピアリザベーション**を使用して、特定のピアに優先順位を付けます。サーバーに特定のピアのピアリザベーションがある場合、既に最大数のピアに接続されていても、サーバーは常にそのピアからの接続要求を受け入れます。（これにより、サーバーでのピアの最大接続数を*超える*可能性があります。）[ノードキーペア](#ノードキーペア)によって確保済みピアを識別するため、可変IPアドレスを持つピアに対してもこれを行うことができます。ピアリザベーションは、管理コマンドを使用して構成され、サーバーデータベースに保存されるため、サーバーがオンラインの場合に調整することができ、再起動後も保存されます。ピアリザベーションは、さまざまなユーザーや組織が運営するサーバーを接続するのに最も有益です。[新規: rippled 1.4.0][]
|
||||
|
||||
次の場合、`rippled`サーバーは、信頼性の低いピアには接続されません。
|
||||
|
||||
- [プライベートピア](#プライベートピア)として構成されている場合、サーバーは固定ピアに _のみ_ 接続されます。
|
||||
- [スタンドアロンモード](rippled-server-modes.html#rippledサーバーをスタンドアロンモードで実行する理由)で実行されている場合、サーバーは _どの_ ピアにも接続されません。
|
||||
|
||||
|
||||
## プライベートピア
|
||||
|
||||
`rippled`サーバーが「プライベート」サーバーとして動作するように設定し、そのIPアドレスを非公開にすることができます。これは、信頼できるバリデータなどの重要な`rippled`サーバーへのサービス拒否攻撃や侵入の試みに対する予防対策として有用です。ピアツーピアネットワークに参加するには、プライベートサーバーは1つ以上の非プライベートサーバーに接続するように設定されている必要があります。この非プライベートサーバーにより、メッセージがネットワークのその他の部分へ中継されます。
|
||||
|
||||
**注意:** [固定ピア](#固定ピアとピアリザベーション)を使用せずにプライベートサーバーを構成すると、サーバーはネットワークに接続できないため、ネットワークの状態を認識したり、トランザクションをブロードキャストしたり、コンセンサスプロセスに参加したりすることができません。
|
||||
|
||||
サーバーをプライベートサーバーとして設定すると次のさまざまな影響が生じます。
|
||||
|
||||
- サーバーがピアツーピアネットワーク内の他のサーバーに接続するように明示的に設定されていない場合、サーバーは他のサーバーに発信接続しません。
|
||||
- サーバーは、他のサーバーからの接続を受け入れるように明示的に設定されていない場合、他のサーバーからの着信接続を受け入れません。
|
||||
- サーバーはそのダイレクトピアに対し、信頼できない通信（[ピアクローラーAPI応答](peer-crawler.html)を含む）の中ではサーバーのIPアドレスを公開しないように指示します。これは、[peers adminメソッド][peers method]などの信頼できる通信には影響しません。
|
||||
- サーバーはそのダイレクトピアに対し、信頼できない通信（[ピアクローラーAPI応答](peer-crawler.html)を含む）の中ではサーバーのIPアドレスを公開しないように指示します。これは、[peers adminメソッド][peersメソッド]などの信頼できる通信には影響しません。
|
||||
|
||||
プライベートサーバーの設定に関係なく、バリデータは常にそのピアに対し、バリデータのIPアドレスを非公開にするように指示します。これにより、バリデータがサービス拒否攻撃を受け過剰な負荷がかかることから保護されます。[新規: rippled 1.2.1][]
|
||||
|
||||
**注意:** サーバーのソースコードを改ざんして、サーバーがこの要求を無視し、直近のピアのIPアドレスを共有する可能性があります。プライベートサーバーを、このように改ざんされていないことが確認されているサーバーにのみ接続するように設定してください。
|
||||
|
||||
プライベートサーバーの設定に関係なく、バリデータは常にそのピアに対し、バリデータのIPアドレスを非公開にするように指示します。これにより、バリデータがサービス拒否攻撃を受け過剰な負荷がかかることから保護されます。[新規: rippled 1.2.1][]
|
||||
### ピア接続設定のメリットとデメリット
|
||||
|
||||
**注意:** サーバーのソースコードを改ざんして、サーバーがこの要求を無視し、直近のピアのIPアドレスを共有する可能性があります。プライベートサーバーを、このように改ざんされていないことが確認されているサーバーにのみ接続するように設定してください。
|
||||
XRP Ledgerで使用できるように、`rippled`サーバーをピアツーピアのオープンネットワークの残りの部分に接続する必要があります。大まかに言えば、`rippled`サーバーがネットワークに接続する方法には、次の3種類の構成があります。
|
||||
|
||||
- **検出されたピア**を使用します。サーバーは、検出された信頼の低いサーバーに接続し、それらのサーバーが適切に動作する限り接続を維持します。（たとえば、要求するデータはそれほど多くなく、ネットワーク接続は安定しているため、同じ[ネットワーク](parallel-networks.html)をフォローしているように見えます。）デフォルトでは、この構成に設定されています。
|
||||
- 同じユーザーまたは組織が実行する**プロキシを使用したプライベートサーバー**として使用します。プロキシは、プライベートサーバーとの固定ピア接続を維持するストック用の`rippled`サーバーです（検出されたピアにも接続されます）。
|
||||
- **公開ハブを使用するプライベートサーバー**として使用します。プロキシを使用する構成と似ていますが、サードパーティーによって異なります。
|
||||
|
||||
各構成のメリットとデメリットは次のとおりです。
|
||||
|
||||
|
||||
<table>
|
||||
<thead><tr>
|
||||
<th>設定</th> <th>メリット</th> <th>デメリット</th>
|
||||
</tr></thead>
|
||||
<tbody>
|
||||
<tr><th>検出されたピア</th>
|
||||
<td><ul>
|
||||
<li><p>最もシンプルな構成。メンテナンスの負担が抑えられます。</p></li>
|
||||
<li><p>ダイレクトピア接続の機会が多数得られます。ダイレクトピア接続には、いくつかのメリットがあります。サーバーは、複数のピアから並行して<a href="ledger-history.html#履歴の取得">履歴を取得</a>できます。同期時と履歴の埋め戻し時のいずれも可能です。履歴は、すべてのピアで完全に保持されているわけではないため、アクセスするピアを増やすことで、幅広い履歴データにアクセスすることもできます。</p></li>
|
||||
<li><p>切断されたピアを新しいピアに置き換えることができるため、サーバーがネットワークから切断される可能性を抑えることができます。</p></li>
|
||||
</ul></td>
|
||||
<td><ul>
|
||||
<li><p>サーバーのピアを選択することはできません。つまり、ピアによって悪意のある動作が行われるかどうかは不明です。「rippled」サーバーは悪意のあるピアから保護するように設計されていますが、悪意のあるピアがソフトウェアの欠陥を悪用してサーバーに影響を及ぼすリスクは常にあります。</p></li>
|
||||
<li><p>サーバーのピアは頻繁に切断または変更される場合があります。</p></li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
<tr><th>プロキシを使用したプライベートサーバー</th>
|
||||
<td><ul>
|
||||
<li><p>最も安全で信頼できる構成（効率的に実装された場合）。</p></li>
|
||||
<li><p>信頼性と冗長性を実現します。</p></li>
|
||||
<li><p><a href="clustering.html">クラスタリング</a>によって、プライベートサーバーのパフォーマンスを最適化できます。</p></li>
|
||||
<li><p>必要な数のダイレクトピア接続を作成できます。プライベートサーバーでは、複数のピアから並行して<a href="ledger-history.html#履歴の取得">履歴を取得</a>できます。複数のピアを実行するため、各ピアで保持するレジャー履歴の量も制御します。</p></li>
|
||||
</ul></td>
|
||||
<td><ul>
|
||||
<li><p>複数のサーバーを実行することで、メンテナンスの負担とコストは高くなります。</p></li>
|
||||
<li><p>ピア接続が停止する可能性が完全に排除されるわけではありません。実行するプロキシの数に関係なく、それらがすべて同じサーバーラックに存在する場合は、1つのネットワーク停止または停電によって、すべてのプロキシに影響が及ぶ可能性があります。</p></li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
<tr><th>公開ハブを使用するプライベートサーバー</th>
|
||||
<td><ul>
|
||||
<li><p>構成がシンプルでメンテナンスの負担を低減できます。</p></li>
|
||||
<li><p>安全なネットワーク接続に簡単にアクセスできます。</p></li>
|
||||
<li><p>プロキシを使用して接続する場合と比較して、同時ピア停止によりプライベートサーバーがネットワークから切断される可能性を低減できます。</p></li>
|
||||
</ul></td>
|
||||
<td><ul>
|
||||
<li><p>信頼性を維持できるように、評判の高いサードパーティー製品を使用します。</p></li>
|
||||
<li>
|
||||
<p>使用する公開ハブが混雑している場合、サーバーはネットワークから切断される可能性があります。公開ハブの性質上、ユーザー数が多いため、すべてのユーザーに安定した接続を確保することが困難な場合があります。</p>
|
||||
<p>この問題を回避するには、使用するハブを増やします。多いほど効果的です。また、デフォルト以外のハブを使用することをお勧めします。ビジー状態になる可能性が低くなります。</p>
|
||||
</li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### プライベートサーバーの設定
|
||||
|
||||
サーバーがプライベートピアとして動作するように設定するには、`rippled`構成ファイルの`[peer_private]`スタンザを使用します。`[ips_fixed]`を使用して、サーバーの接続先サーバーをリストします。（`[ips_fixed]`にアドレスを指定せずに`[peer_private]`を有効にすると、サーバーはネットワークに接続しません。）追加の予防対策として、ファイアウォールを使用して他のサーバーからの着信接続をブロックします。
|
||||
サーバーをプライベートサーバーとして設定するには、設定ファイルの`[peer_private]`を`1`に設定します。詳細な手順については、[プライベートサーバーの設定](configure-a-private-server.html)を参照してください。
|
||||
|
||||
設定例:
|
||||
|
||||
```
|
||||
# Configuration on a private server that only connects through
|
||||
# a second rippled server at IP address 10.1.10.55
|
||||
[ips_fixed]
|
||||
10.1.10.55
|
||||
## 関連項目
|
||||
|
||||
[peer_private]
|
||||
1
|
||||
```
|
||||
- **コンセプト:**
|
||||
- [コンセンサス](consensus.html)
|
||||
- [並列ネットワーク](parallel-networks.html)
|
||||
- **チュートリアル:**
|
||||
- [rippledサーバーのクラスター化](cluster-rippled-servers.html)
|
||||
- [プライベートサーバーの設定](configure-a-private-server.html)
|
||||
- [ピアクローラーの設定](configure-the-peer-crawler.html)
|
||||
- [ピアリングのポート転送](forward-ports-for-peering.html)
|
||||
- [特定のピアへの手動接続](manually-connect-to-a-specific-peer.html)
|
||||
- [ピアの最大数の設定](set-max-number-of-peers.html)
|
||||
- [ピアリザベーション](use-a-peer-reservation.html)
|
||||
- **リファレンス:**
|
||||
- [peersメソッド][]
|
||||
- [peer_reservations_addメソッド][]
|
||||
- [peer_reservations_delメソッド][]
|
||||
- [peer_reservations_listメソッド][]
|
||||
- [connectメソッド][]
|
||||
- [fetch_infoメソッド][]
|
||||
- [ピアクローラー](peer-crawler.html)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
|
||||
@@ -3,8 +3,8 @@
|
||||
`rippled`サーバーソフトウェアは、その設定に応じて以下のようなさまざまなモードで実行できます。
|
||||
|
||||
* ストックサーバー - レジャーのローカルコピーを保持し、ネットワークをフォローします。
|
||||
* 検証サーバー（_バリデータ_）- コンセンサスの参加者（ストックサーバーの処理もすべて行います）。
|
||||
* `rippled` スタンドアロンモードのサーバー - テスト用。他の`rippled`サーバーと通信しません。
|
||||
* 検証サーバー（ _バリデータ_ ）- コンセンサスの参加者（ストックサーバーの処理もすべて行います）。
|
||||
* `rippled`スタンドアロンモードのサーバー - テスト用。他の`rippled`サーバーと通信しません。
|
||||
|
||||
また、[`rippled` API](rippled-api.html)にローカルでアクセスするためのクライアントアプリケーションとして、`rippled`実行可能ファイルを実行できます。（この場合同じバイナリの2つのインスタンスを並列して実行できます。1つのインスタンスをサーバーとして実行し、もう1つのインスタンスをクライアントとして一時的に実行して終了します。）
|
||||
|
||||
@@ -15,7 +15,7 @@
|
||||
|
||||
独自の`rippled`サーバーを運用する理由は多数ありますが、その最たる理由として、独自サーバーが信頼できるものであり、自身でその負荷を管理でき、サーバーにアクセスするタイミングとアクセス方法を他のユーザーに依存せずに決めることができる点があげられます。もちろん、独自サーバーを不正使用者から保護するために適切なネットワークセキュリティ対策を講じなければなりません。
|
||||
|
||||
使用する`rippled`を信頼する必要があります。悪意のあるサーバーに接続してしまうと、そのサーバーはさまざまな方法であなたを利用して資金を失わせることができます。次に例を示します。
|
||||
使用する`rippled`を信頼する必要があります。悪意のあるサーバーに接続してしまうと、そのサーバーはさまざまな方法であなたを利用して資金を失わせることができます。例:
|
||||
|
||||
* 悪意のあるサーバーは、実際には行われていないあなたへの支払いが行われたと報告することがあります。
|
||||
* ペイメントパスと通貨取引オファーを選択的に表示または非表示にし、最適なディールをあなたに提示せずに不正使用者の利益になるようにします。
|
||||
@@ -27,15 +27,15 @@
|
||||
|
||||
### 公開ハブ
|
||||
|
||||
**Note:** この部分は日本語ではまだ利用できません。助けたいと思うなら、[提供して下さい！](https://github.com/ripple/xrpl-dev-portal#contributing)
|
||||
公開ハブは、他のサーバーへの[ピアプロトコル接続](peer-protocol.html)が多数あるストックサーバーを指します。ストックサーバーを公開ハブとして実行することで、XRP Ledgerネットワークの効率的な接続を維持できます。適切に運用されている公開ハブには、以下の特徴があります。
|
||||
|
||||
A public hub is a stock server with lots of [peer protocol connections](peer-protocol.html) to other servers. You can help the XRP Ledger network maintain efficient connectivity by running a stock server as a public hub. Successful public hubs embody the following traits:
|
||||
- 十分な帯域幅。
|
||||
|
||||
- Good bandwidth.
|
||||
- 多数の信頼できるピアとの接続。
|
||||
|
||||
- メッセージを確実に中継する能力。
|
||||
|
||||
- Connections with a lot of reliable peers.
|
||||
|
||||
- Ability to relay messages reliably.
|
||||
|
||||
## バリデータを運用する理由
|
||||
|
||||
@@ -60,8 +60,23 @@ XRP Ledgerの堅牢性は、バリデータが相互に接続されたネット
|
||||
|
||||
**注意:** スタンドアロンモードでは[レジャーを手動で進める](advance-the-ledger-in-stand-alone-mode.html)必要があります。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [コマンドライン使用リファレンス](commandline-usage.html) - すべての`rippled`サーバーモードのコマンドラインオプションに関する詳細情報。
|
||||
- **リファレンス:**
|
||||
- [コマンドライン使用リファレンス](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)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
|
||||
@@ -0,0 +1,72 @@
|
||||
# 取引検閲の検知
|
||||
|
||||
[新規: rippled 1.2.0][]
|
||||
|
||||
XRP Ledgerは、高い[検閲耐性](xrp-ledger-overview.html#耐検閲性のある取引処理)を実現できるように設計されています。この設計をサポートするために、XRP Ledgerでは、取引検閲の自動検知機能がすべての`rippled`サーバーで有効になっており、検閲によるネットワークへの影響の有無を、すべての参加者が確認できます。
|
||||
|
||||
`rippled`サーバーがネットワークと同期している間、検知機能は、`rippled`サーバーの観点から、[コンセンサス](intro-to-consensus.html)の最終ラウンドで受け入れられ、最後に検証されたレジャーに取り込まれるトランザクションをすべて追跡します。検知機能では、数回のコンセンサスラウンド後、検証済みのレジャーに取り込まれていないトランザクションの重大度が高くなるというログメッセージを発行します。
|
||||
|
||||
|
||||
|
||||
## 仕組み
|
||||
|
||||
取引検閲検知機能の仕組みの概要を以下に示します。
|
||||
|
||||
1. 検知機能は、`rippled`サーバーの最初のコンセンサス提案のすべてのトランザクションをトラッカーに追加します。
|
||||
|
||||
2. コンセンサスラウンドの終了時に、検知機能によって、検証済みのレジャーに取り込まれているトランザクションはすべて、トラッカーから削除されます。
|
||||
|
||||
3. 検知機能は、15個のレジャーのトラッカーに残っているトランザクションについて、ログで[警告メッセージ](#警告メッセージの例)を発行し、潜在的に検閲されたトランザクションとして表面化します。この時点でトラッカーにトランザクションが存在する場合は、15ラウンドのコンセンサスの後、検証済みのレジャーに取り込まれていないことを意味します。トランザクションが別の15個のレジャーのトラッカーに残っている場合は、検知機能によって、ログに別の警告メッセージが発行されます。
|
||||
|
||||
トランザクションがトラッカーに残っている限り、最大5つの警告メッセージに対して、検知機能は15個のレジャーごとにログに警告メッセージを発行し続けます。警告メッセージが5回発行されると、検知機能は、ログに最終的な[エラーメッセージ](#エラーメッセージの例)を発行し、警告およびエラーメッセージの発行を停止します。
|
||||
|
||||
`rippled`サーバーログにこれらのメッセージが表示される場合、他のサーバーでトランザクションを取り込むことができない理由を調査する必要があります。まず、原因が悪意のある検閲よりも[誤検知](#誤検知の可能性)（無害なバグ）である可能性が高いと仮定します。
|
||||
|
||||
|
||||
|
||||
## 警告メッセージの例
|
||||
|
||||
トランザクションE08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7がレジャー18851530～18851545までの15個のレジャーのトラッカーに残っている場合に、取引検閲検知機能によって発行される警告メッセージの例を次に示します。
|
||||
|
||||
```text
|
||||
LedgerConsensus:WRN Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851545.
|
||||
```
|
||||
|
||||
|
||||
## エラーメッセージの例
|
||||
|
||||
トランザクションE08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7がレジャー18851530～18851605までの75個のレジャー（15個のレジャーの5セット）のトラッカーに残っている場合に、取引検閲検知機能によって発行されるエラーメッセージの例を以下に示します。
|
||||
|
||||
```text
|
||||
LedgerConsensus:ERR Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851605.Additional warnings suppressed.
|
||||
```
|
||||
|
||||
|
||||
## 誤検知の可能性
|
||||
|
||||
シナリオによっては、取引検閲検知機能で誤検知が発生する場合があります。この場合、誤検知とは、15個以上のレジャーについてトラッカーに残っているトランザクションにフラグが立てられたことを意味しますが、これによる問題はありません。
|
||||
|
||||
検知機能で誤検知メッセージが発行される可能性のあるシナリオを次に示します。
|
||||
|
||||
- `rippled`サーバーでは、ネットワークの他の部分とは異なるコードでビルドを実行しています。そのため、トランザクションは`rippled`サーバー上で別の方法で適用され、結果として誤検知の原因になります。このような誤検知が発生することはほとんどありませんが、一般的に、正しいバージョンの`rippled`を実行することが重要です。
|
||||
|
||||
- `rippled`サーバーはネットワークと同期されていないため、現時点で認識されていません。
|
||||
|
||||
- ネットワーク内の`rippled`サーバー（自身のサーバーも含まれる可能性が高い）は、`rippled`サーバーがトランザクションをネットワーク内の他の`rippled`サーバーに一貫性なく中継するバグのクラスの影響を受けています。
|
||||
|
||||
現在、この予期しない動作の原因となる既知のバグはありません。ただし、バグの疑いがある影響を確認した場合は、[RippleのBug Bounty](https://ripple.com/bug-bounty/)プログラムへのご報告をお願いいたします。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [コンセンサスの原理とルール](consensus-principles-and-rules.html)
|
||||
- [トランザクションキュー](transaction-queue.html)
|
||||
- **チュートリアル:**
|
||||
- [信頼できるトランザクションの送信](reliable-transaction-submission.html)
|
||||
- [ログメッセージについて](understanding-log-messages.html)
|
||||
- **リファレンス:**
|
||||
- [トランザクションの結果](transaction-results.html)
|
||||
|
||||
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
Reference in New Issue
Block a user