Clean up unused / removed pages & images

- Delete folders for new pages that are handled by templates w/ no
  markdown source
- Fully remove "Use Cases", leaving redirects for deleted pages.
    - Move certain pages to new areas & remove Use Case markup
- Add "Contribute Code to the XRP Ledger" draft page
- Fix image paths in some Japanese-translated pages
This commit is contained in:
mDuo13
2020-09-17 22:17:06 -07:00
parent fee9d79a18
commit b1339f84c6
37 changed files with 200 additions and 833 deletions

View File

@@ -241,7 +241,7 @@ TrustSetAuth
- [Introduction to Consensus](intro-to-consensus.html)
- **Tutorials:**
- [Run rippled as a Validator](run-rippled-as-a-validator.html)
- [Contribute Code to rippled](contribute-code-to-rippled.html)
- [Contribute Code to the XRP Ledger](contribute-code.html)
- **References:**
- [Amendments ledger object](amendments-object.html)
- [EnableAmendment pseudo-transaction][]

View File

@@ -19,13 +19,13 @@ XRP Ledger上でアプリケーションを構築する場合は、XRP Ledger AP
レジャーバージョンに含まれるデータの詳細な技術説明については、[レジャーフォーマットのリファレンス](ledger-data-formats.html)を参照してください。
[![図1: XRP Ledgerの要素](img/anatomy-of-a-ledger-complete.png)](img/anatomy-of-a-ledger-complete.png)
[![図1: XRP Ledgerの要素](img/anatomy-of-a-ledger-complete.ja.png)](img/anatomy-of-a-ledger-complete.ja.png)
_図1: XRP Ledgerの要素_
XRP Ledgerでは、数秒ごとに新しいレジャーバージョンが作成されます。あるレジャーバージョンの内容にネットワークが同意すると、そのレジャーバージョンは _検証済み_ となり、その内容が変更されることはありません。それ以前の検証済みのレジャーバージョンによって、レジャー履歴が形成されます。検証済みの最新のレジャーも、少し前の時点のネットワークの状態を表しており、履歴の一部となります。現時点で、ネットワークは次のレジャーバージョンに適用されてファイナライズされる可能性のあるトランザクションを評価しています。この評価が行われている間、ネットワークには、検証前のレジャーバージョン候補が存在します。
[![図2: XRP Ledgerの履歴](img/ledger-history.png)](img/ledger-history.png)
[![図2: XRP Ledgerの履歴](img/ledger-history.ja.png)](img/ledger-history.ja.png)
_図2: XRP Ledgerの履歴_
@@ -37,7 +37,7 @@ _図2: XRP Ledgerの履歴_
各レジャーバージョンには、一連のトランザクションと、そのようなトランザクションに関するメタデータも含まれています。それらのトランザクションは、新しいレジャーバージョンを作成するために前のバージョンのレジャーに適用されたものです。メタデータには、レジャーの状態データに対する、トランザクションの影響が正確に記録されています。
[![図3: レジャーバージョンに適用されるトランザクション](img/ledger-changes.png)](img/ledger-changes.png)
[![図3: レジャーバージョンに適用されるトランザクション](img/ledger-changes.ja.png)](img/ledger-changes.ja.png)
_図3: レジャーバージョンに適用されるトランザクション_
@@ -57,7 +57,7 @@ _図3: レジャーバージョンに適用されるトランザクション_
ピアツーピアのXRP Ledgerネットワークは、トランザクションを承認して処理する多数の独立したXRP Ledgerサーバー通常、[`rippled`](the-rippled-server.html)を実行で構成されています。クライアントアプリケーションは、トランザクションに署名してXRP Ledgerサーバーに送信します。サーバーは、これらの候補トランザクションを処理するためにネットワーク内を中継します。クライアントアプリケーションには、モバイルおよびウェブウォレット、金融機関へのゲートウェイ、電子取引プラットフォームなどがあります。
[![図4: XRP Ledgerプロトコルの参加者](img/xrp-ledger-network.png)](img/xrp-ledger-network.png)
[![図4: XRP Ledgerプロトコルの参加者](img/xrp-ledger-network.ja.png)](img/xrp-ledger-network.ja.png)
_図4: XRP Ledgerプロトコルの参加者_
@@ -71,7 +71,7 @@ _図4: XRP Ledgerプロトコルの参加者_
コンセンサスの間、各サーバーは、そのサーバーの信頼できるバリデータ( _ユニークードリストUNL_ )と呼ばれる特定のサーバー群からの提案を評価します。<a href="#footnote_5" id="from_footnote_5"><sup>5</sup></a>信頼できるバリデータとは、提案を評価するサーバーを欺こうと共謀しない、全体として「信頼できる」ネットワークのサブセットを表します。この「信頼」の定義では、選択された個々のバリデータが信頼されている必要はありません。バリデータの選択は、ネットワークに中継されたデータを改ざんする組織的な試みで共謀しないという想定に基づいて行われます<a href="#footnote_6" id="from_footnote_6"><sup>6</sup></a><!-- STYLE_OVERRIDE: will -->
[![図5: バリデータによるトランザクションセットの提案と修正](img/consensus-rounds.png)](img/consensus-rounds.png)
[![図5: バリデータによるトランザクションセットの提案と修正](img/consensus-rounds.ja.png)](img/consensus-rounds.ja.png)
_図5: バリデータによるトランザクションセットの提案と修正 - コンセンサスの開始時点で、バリデータ毎に異なるトランザクションセットを持っている可能性があります。後のラウンドで、サーバーは現在の提案を信頼できるバリデータの提案と一致するように変更します。このプロセスでは、現在議論しているレジャーバージョンに適用するトランザクションと、それ以降のレジャーバージョンに適用するトランザクションを決定します。_
@@ -95,22 +95,22 @@ _図5: バリデータによるトランザクションセットの提案と修
1. 一つ前の検証済みのレジャーから始めます。
2. すべてのサーバーが同じ方法で処理できるように、合意済みのトランザクションセットを _正規順序_ で並べ変えます。
[正規順序](https://github.com/ripple/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/src/ripple/app/misc/CanonicalTXSet.cpp#L25-L36)は、トランザクションを受け取った順序ではありません(サーバーが同じトランザクションを異なる順序で受け取る可能性があるため)。参加者がトランザクションの順序付けで競合しないように、故意に操作するのが困難な正規順序を使います。
3. 指示に従って、各トランザクションを順番に処理します。それに応じてレジャーの状態データを更新します。
トランザクションを正常に実行できない場合は、[`tec`クラス結果コード](tec-codes.html)を持つトランザクションを含めます。<a href="#footnote_1" id="from_footnote_1"><sup>1</sup></a>
特定の「再試行可能な」トランザクションの失敗に対しては、同じレジャーバージョンの他のトランザクションが実行された後に再試行されるように、そのトランザクションを正規順序の最後に移動します。
4. 適切なメタデータでレジャーヘッダーを更新します。
これには、レジャーインデックス、前に検証済みのレジャーの識別ハッシュ(このレジャーの「親」)、このレジャーバージョンの予定終了時刻、このレジャーの内容の暗号化ハッシュなどのデータが含まれます。
5. 新しいレジャーバージョンの識別用ハッシュを計算します。
[![図7: XRP Ledgerサーバーでレジャー検証を計算する](img/consensus-calculate-validation.png)](img/consensus-calculate-validation.png)
[![図7: XRP Ledgerサーバーでレジャー検証を計算する](img/consensus-calculate-validation.ja.png)](img/consensus-calculate-validation.ja.png)
_図7: XRP Ledgerサーバーでレジャー検証を計算する - 各サーバーは、同意済みのトランザクションを前の検証済みレジャーに適用します。バリデータは結果をネットワーク全体に送信します。_
@@ -118,7 +118,7 @@ _図7: XRP Ledgerサーバーでレジャー検証を計算する - 各サーバ
バリデータはそれぞれ、計算したレジャーバージョンのハッシュを含む署名付きメッセージの形式で結果を中継します。 _検証_ と呼ばれるこれらのメッセージによって、各サーバーで計算したレジャーとそのピアのレジャーを比較することができます。
[![図8: 圧倒的多数のピアが同じ結果を計算するとレジャーが検証される](img/consensus-declare-validation.png)](img/consensus-declare-validation.png)
[![図8: 圧倒的多数のピアが同じ結果を計算するとレジャーが検証される](img/consensus-declare-validation.ja.png)](img/consensus-declare-validation.ja.png)
_図8: 圧倒的多数のピアが同じ結果を計算するとレジャーが検証される - 各サーバーは、計算されたレジャーを、選択されたバリデータから受け取ったハッシュと比較します。一致しない場合、サーバーは正しいレジャーを再計算または取得する必要があります。_