mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-20 19:55:54 +00:00
[JA] update concepts/ledgers
This commit is contained in:
tequ
40
content/concepts/ledgers/ledger-close-times.ja.md
Normal file
40
content/concepts/ledgers/ledger-close-times.ja.md
Normal file
@@ -0,0 +1,40 @@
|
||||
---
|
||||
html: ledger-close-times.html
|
||||
parent: ledgers.html
|
||||
blurb: XRP Ledgerが、レジャーバージョンごとに一意の閉鎖時刻を計算する方法。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
---
|
||||
# レジャーの閉鎖時刻
|
||||
|
||||
レジャーバージョンの閉鎖時刻は、[レジャーヘッダー](ledger-header.html)の`close_time`フィールドに記録されます。ネットワークの正確な閉鎖時刻についてコンセンサスを得やすくするため、この値は閉鎖時刻の精度に基づく秒数に丸められます(現在は10秒)。丸めによってレジャーの閉鎖時刻が親レジャーの閉鎖時刻と同じになる(または早くなる)場合、子レジャーの閉鎖時刻は親レジャーの閉鎖時刻に1を足した時刻に設定されます。これにより、有効なレジャーの閉鎖時刻が確実に増加することが保証されます。
|
||||
|
||||
通常、新しいレジャーバージョンは約3～5秒ごとに閉鎖するため、これらのルールの結果、レジャーの閉鎖時刻は、:00、:01、:02、:10、:11、:20、:21、...で終わるような、あいまいなパターンになります。2で終わることはあまりなく、3で終わることは非常にまれですが、どちらも、より多くのレジャーが10秒の時間内にランダムに閉鎖した場合にランダムに発生します。
|
||||
|
||||
一般的に、レジャーは閉鎖時刻よりも正確な時刻計測を行うことはできません。例えば、あるオブジェクトが有効期限を過ぎているかどうかを確認するには、親レジャーの閉鎖時刻と比較するルールになっています。(レジャーの閉鎖時刻は、そのレジャーに登録されるトランザクションの実行時点では確定していません)。これは、例えば[Escrow](escrow.html)が、Escrowオブジェクトで指定された時間ベースの有効期限より最大で約10秒遅い実世界の時刻に終了する可能性があることを意味します。
|
||||
|
||||
### 例
|
||||
|
||||
以下の例は、バリデータの観点から、レジャーの閉鎖時刻**12:00:00**の丸め動作を示しています。
|
||||
|
||||
**現在のコンセンサスラウンド**
|
||||
|
||||
1. バリデータは、レジャーが閉鎖してコンセンサスに達したのが**12:00:03**であったことを記録します。バリデータはこの閉鎖時刻を自分の提案に含めます。
|
||||
2. バリデータは、(そのUNL上の)大多数のバリデータが閉鎖時刻を12:00:02と提案し、 残りのバリデータが閉鎖時刻を12:00:03と提案したことを確認します。そのバリデータは、提案された閉鎖時刻をコンセンサスの**12:00:02**に合わせます。
|
||||
3. バリデータはこの値を最も近い時間に丸め、**12:00:00** とします。
|
||||
4. 12:00:00は前のレジャーの閉鎖時刻より大きくないので、バリデータは閉鎖時刻を前のレジャーの閉鎖時刻のちょうど1秒後に調整します。その結果、調整後の閉鎖時刻は **12:00:01** となります。
|
||||
5. バリデータはこれらの詳細情報を使ってレジャーを作成し、ハッシュを計算します。
|
||||
|
||||
検証を行わないサーバは、記録した閉鎖時刻をネットワークの他のサーバに提案しないことを除いて、すべて同じ手順を踏みます。
|
||||
|
||||
**次のコンセンサスラウンド**
|
||||
|
||||
1. 大多数のバリデータによると、次のレジャーは**12:00:04**にコンセンサスに入ります。
|
||||
2. 閉鎖時刻は再び切り捨てられ、**12:00:00**となります。
|
||||
3. これは前のレジャーの閉鎖時刻12:00:01より大きくないため、調整後の閉鎖時刻は**12:00:02**となります。
|
||||
|
||||
**その次のコンセンサスラウンド**
|
||||
|
||||
1. 大多数のバリデータによると、この次のレジャーは**12:00:05**にコンセンサスに入ります。
|
||||
2. これは、閉鎖時刻の制度に基づいて、**12:00:10**に切り上げられます。
|
||||
3. この値は前のレジャーの閉鎖時刻より大きいので、調整する必要はありません。**12:00:10**が正式な閉鎖時刻となります。
|
||||
68
content/concepts/ledgers/ledger-structure.ja.md
Normal file
68
content/concepts/ledgers/ledger-structure.ja.md
Normal file
@@ -0,0 +1,68 @@
|
||||
---
|
||||
html: ledger-structure.html
|
||||
parent: ledgers.html
|
||||
blurb: 個別のレジャーブロックの要素を詳しく見てみましょう。
|
||||
---
|
||||
# レジャーの構成要素
|
||||
|
||||
XRP Ledgerはブロックチェーンであり、データブロックの履歴を順番に並べたものです。XRP Ledgerブロックチェーンのブロックは、 _レジャーバージョン_ または略して _レジャー_ と呼ばれます。
|
||||
|
||||
コンセンサスプロトコルは、以前のレジャーバージョンを起点として、次に適用するトランザクションのセットについてバリデータ間の合意を形成し、それらのトランザクションを適用することで全員が同じ結果を得たことを確認します。これが成功すると、結果として新しいレジャーバージョンが作成されます。そこから、次のレジャーバージョンを構築するプロセスが繰り返されます。
|
||||
|
||||
各レジャーバージョンには、 _状態データ_ 、 _トランザクションセット_ 、メタデータを含む _ヘッダー_ が含まれます。
|
||||
|
||||
{{ include_svg("img/ledger.svg", "図: レジャーはヘッダー、トランザクションセット、状態データから構成されます。") }}
|
||||
|
||||
|
||||
## 状態データ
|
||||
|
||||
{{ include_svg("img/ledger-state-data.svg", "図: レジャーの状態データは、さまざまなオブジェクトで構成され、グラフのようにリンクされていることもあります。") }}
|
||||
|
||||
_状態データ_ とは、そのレジャーバージョンにおけるすべてのアカウント、残高、設定、その他の情報のスナップショットを表します。サーバがネットワークに接続すると、最初に行うことの1つは、新しいトランザクションを処理し、現在の状態に関するクエリに答えることができるように、現在の状態データの完全なセットをダウンロードすることです。ネットワーク内のすべてのサーバが状態データの完全なコピーを持っているため、すべてのデータは公開され、どのコピーも同じように有効です。
|
||||
|
||||
状態データは _レジャーエントリ_ と呼ばれる個別のオブジェクトで構成され、ツリー形式で保存されます。各レジャーエントリには一意の256ビットのIDがあり、それを使用して状態ツリーから検索することができます。
|
||||
|
||||
## トランザクションセット
|
||||
|
||||
{{ include_svg("img/ledger-transaction-set.svg", "図: レジャーのトランザクションセット、正規の順序で並べられたトランザクションのグループ") }}
|
||||
|
||||
レジャーに加えられたすべての変更は、トランザクションの結果です。各レジャーバージョンには、特定の順序で新たに適用されたトランザクションのグループである _トランザクションセット_ が含まれています。あるレジャーのトランザクションセットを前のレジャーバージョンの状態データに適用すると、結果としてそのレジャーの状態データが得られます。
|
||||
|
||||
レジャーのトランザクションセット内のすべてのトランザクションは、以下の両方の要素を持ちます。
|
||||
|
||||
- 送信者がレジャーに何を指示したかを示す _トランザクションの内容_ 。
|
||||
- トランザクションがどのように処理され、レジャーの状態データにどのような影響を与えたかを正確に示す _トランザクションのメタデータ_ 。
|
||||
|
||||
|
||||
## レジャーヘッダー
|
||||
|
||||
_レジャーヘッダー_ は、レジャーバージョンの概略を示すデータのブロックです。レポートの表紙のように、レジャーバージョンを一意に識別し、その内容を記載し、他の注意事項とともに作成時刻を表しています。レジャーヘッダーには以下の情報が含まれます。
|
||||
|
||||
<!-- Note: the alt text for the diagrams is intentionally empty because any caption would be redundant with the text. -->
|
||||
|
||||
- {{include_svg("img/ledger-index-icon.svg", "", classes="floating-diagram")}} チェーン内でのレジャーの位置を示す _レジャーインデックス_ 。レジャーは、1つ小さいインデックスを持つレジャーの上に構築され、 _ジェネシスレジャー_ として知られるスタート地点に戻ります。これは、すべてのトランザクションと結果の公開履歴を形成します。
|
||||
- {{include_svg("img/ledger-hash-icon.svg", "", classes="floating-diagram")}} レジャーの内容を一意に識別する _レジャーハッシュ_ 。ハッシュは、レジャーバージョンの内容が変更された場合、ハッシュが完全に異なるものになるように計算されます。これは、レジャーのデータが消失、変更、破損していないことを示すチェックサムのようなものでもあります。
|
||||
- {{include_svg("img/ledger-parent-icon.svg", "", classes="floating-diagram")}} 親レジャーのハッシュ。レジャーバージョンは、その前の _親レジャー_ との違いによって定義されることが多く、ヘッダーには親レジャーの一意なハッシュも含まれます。
|
||||
- {{include_svg("img/ledger-timestamp-icon.svg", "", classes="floating-diagram")}} このレジャーの内容が確定した正式なタイムスタンプとなる _閉鎖時刻_ 。この数値は秒数(一の位)が四捨五入され、通常は10です。
|
||||
- {{include_svg("img/ledger-state-data-hash-icon.svg", "", classes="floating-diagram")}} このレジャーの状態データのチェックサムとして機能する _状態データのハッシュ_ 。
|
||||
- {{include_svg("img/ledger-tx-set-hash-icon.svg", "", classes="floating-diagram")}} このレジャーのトランザクションセットのデータのチェックサムとして機能する _トランザクションセットのハッシュ_。
|
||||
- {{include_svg("img/ledger-notes-icon.svg", "", classes="floating-diagram")}} その他、存在するXRPの総量や、閉鎖時刻が四捨五入された値など、いくつかのメモがあります。
|
||||
|
||||
レジャーのトランザクションセットと状態データのサイズは無制限ですが、レジャーヘッダーは常に固定サイズです。レジャーヘッダーの正確なデータとバイナリ形式については、[レジャーヘッダー](ledger-header.html)を参照してください。
|
||||
|
||||
|
||||
## バリデーションの状況
|
||||
|
||||
{{ include_svg("img/ledger-validated-mark.svg", "Diagram: レジャーのバリデーション(検証)状況。レジャーの上に追加され、レジャー自体の一部ではありません。") }}
|
||||
|
||||
サーバの Unique Node List のバリデータのコンセンサスがレジャーバージョンの内容に合意すると、そのレジャーバージョンは検証済みであり、変更不可であるとみなされます。レジャーの内容は、後続のトランザクションが新しいレジャーバージョンを作成し、チェーンを更新することによってのみ変更できます。
|
||||
|
||||
レジャーバージョンが新しく作成された時点では、まだ未検証です。候補となるトランザクションが異なるサーバに到着するタイミングが異なるため、ネットワークはチェーンの次のステップとなる複数の異なるレジャーバージョンを構築し、提案する可能性があります。[コンセンサスプロトコル](consensus.html)は、そのうちのどれを有効化するかを決定します。(検証済みのレジャーバージョンに存在しなかったトランザクション候補は、通常、次のレジャーバージョンのトランザクションセットに含まれます)。
|
||||
|
||||
|
||||
## レジャーインデックスとレジャーハッシュ
|
||||
レジャーバージョンを識別する方法には、 _レジャーインデックス_ と _レジャーハッシュ_ の2種類があります。この2つのフィールドはどちらもレジャーを識別しますが、その目的は異なります。レジャーインデックスはチェーン内でのレジャーの位置を表し、レジャーハッシュはレジャーの内容を表します。
|
||||
|
||||
異なるチェーンのレジャーは、レジャーインデックスは同じでもハッシュが異なることがあります。また、検証されていないレジャーバージョンを扱う場合、インデックスが同じでも内容が異なるため、ハッシュが異なる複数のレジャー候補が存在する可能性があります。
|
||||
|
||||
同じレジャーハッシュを持つ2つのレジャーは、常に完全に同一です。
|
||||
@@ -1,93 +1,35 @@
|
||||
---
|
||||
html: ledgers.html
|
||||
parent: concepts.html
|
||||
blurb: XRP Ledgerは、rippledによって内部データベースに保持されている一連の個別レジャー（レジャーバージョン）で構成されています。これらのレジャーの構造と内容について説明します。
|
||||
blurb: XRP Ledgerは、rippledによって内部データベースに保持されている一連の個別レジャー(レジャーバージョン)で構成されています。これらのレジャーの構造と内容について説明します。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
- データ保持
|
||||
---
|
||||
# レジャー
|
||||
|
||||
XRP Ledgerは完全にオープンな共有グローバルレジャーです。個々の参加者はこのレジャーを管理する個々の機関を信頼しなくても、レジャーの整合性を信頼できます。`rippled`サーバーソフトウェアは、非常に特殊なルールによってのみ更新可能なレジャーデータベースを管理することにより、これを実現しています。各`rippled`インスタンスはレジャーの完全なコピーを保持し、`rippled`サーバーからなるピアツーピアネットワークはトランザクション候補を各サーバーに配信します。コンセンサスプロセスによって、レジャーの新しいバージョンに適用されるトランザクションが決定します。関連項目: [コンセンサスプロセス](consensus.html)。
|
||||
XRP Ledgerは、誰にでも開かれた共有のグローバル台帳(レジャー)です。個々の参加者は、単一の機関に台帳の管理を任せることなく、台帳の正当性を信頼することができます。XRP Ledgerプロトコルは、非常に特殊なルールに従ってのみ更新可能な台帳データベースを管理することで、これを実現しています。ピアツーピアネットワークのサーバは台帳データベースの完全なコピーを保持し、ネットワークは候補となるトランザクションを配信し、[コンセンサスプロセス](consensus.html)に従ってブロック単位で適用されます。
|
||||
|
||||
|
||||
{{ include_svg("img/ledger-changes.svg", "図: 各レジャーは、その前のレジャーバージョンにトランザクションを適用して生成されます")}}
|
||||
|
||||
この共有グローバルレジャーは、実際には`rippled`の内部データベースに保持されている一連の個別レジャー（レジャーバージョン）です。各レジャーバージョンには、レジャーの生成順を示す[レジャーインデックス][]が付いています。各閉鎖済みレジャーバージョンにも、レジャーの内容を示す識別用ハッシュ値があります。`rippled`インスタンスには常に、1つの処理中の「現行」オープンレジャー、コンセンサスにより承認されていないいくつかの閉鎖済みレジャー、およびコンセンサスによる検証済みの任意の数の履歴レジャーがあります。検証済みレジャーだけが、その内容が正確で変更できません。
|
||||
共有グローバル台帳は、レジャーバージョンまたは単に _レジャー_ と呼ばれる一連のブロックから構成されます。すべてのレジャーバージョンには、台帳の正しい順序を識別する[レジャーインデックス][]があります。永続的にクローズされる各台帳には、固有の識別ハッシュ値も存在します。
|
||||
|
||||
1つのレジャーバージョンはさまざまな要素で構成されています:
|
||||
各XRP Ledgerサーバは常に、進行中の _オープン_ レジャー、保留中の _閉鎖済み_ レジャー、そして確定済みの _検証済み_ レジャーの履歴を持っており、これらは変更不可(immutable)です。
|
||||
|
||||
|
||||
1つのレジャーバージョンはいくつかの要素から構成されています。
|
||||
|
||||
{{ include_svg("img/anatomy-of-a-ledger-simplified.svg", "レジャーにはトランザクション、状態ツリー、閉鎖時刻、検証情報を含むヘッダーが含まれています。")}}
|
||||
|
||||
* **ヘッダー** - [レジャーインデックス][]、レジャーのその他のコンテンツのハッシュ、その他のメタデータ。
|
||||
* **トランザクションツリー** - このレジャーの作成時に、直前のレジャーに適用された[トランザクション](transaction-formats.html)。トランザクションは、レジャーの変更を可能にする _唯一の_ 手段です。
|
||||
* **状態ツリー** - このバージョンのレジャーの設定、残高、オブジェクトを含むすべての[レジャーオブジェクト](ledger-object-types.html)。
|
||||
* **状態ツリー** - このレジャーの設定、残高などを含むすべての[レジャーエントリ](ledger-object-types.html)。
|
||||
|
||||
|
||||
## ツリーの形式
|
||||
|
||||
レジャーの状態ツリーは、その名前のとおりツリー型データ構造です。状態ツリーの各オブジェクトは256ビットのオブジェクトIDで識別されます。JSONではレジャーオブジェクトのIDは`index`フィールドです。このフィールドには64文字の16進数文字列が含まれています（例: `"193C591BF62482468422313F9D3274B5927CA80B4DD3707E42015DD609E39C94"`）。状態ツリーの各オブジェクトには、オブジェクトの検索に使用できるIDが設定されています。各トランザクションには、トランザクションツリーでトランザクションを検索するときに使用できる識別用ハッシュが含まれています。レジャーオブジェクトの`index`（ID）と[レジャーの`ledger_index`（シーケンス番号）][レジャーインデックス]を混同しないでください。
|
||||
|
||||
**ヒント:** レジャーの状態ツリーのオブジェクトは「レジャーノード」と呼ばれることもあります。たとえばトランザクションメタデータは`AffectedNodes`のリストを返します。これをピアツーピアネットワークの「ノード」（サーバー）と混同しないでください。
|
||||
|
||||
トランザクションの場合、識別用ハッシュは署名済みトランザクションの指示に基づいていますが、検索時のトランザクションオブジェクトにはトランザクションの結果とメタデータが含まれています。これは、ハッシュの生成時には反映されません。
|
||||
|
||||
<!-- TODO: translate these new sections -->
|
||||
|
||||
## Open, Closed, and Validated Ledgers
|
||||
|
||||
The `rippled` server makes a distinction between ledger versions that are _open_, _closed_, and _validated_. A server has one open ledger, any number of closed but unvalidated ledgers, and an immutable history of validated ledgers. The following table summarizes the difference:
|
||||
|
||||
| Ledger Type: | Open | Closed | Validated |
|
||||
|:---------------------------------|:----------------------------|:-------------------------------------------|:--|
|
||||
| **Purpose:** | Temporary workspace | Proposed next state | Confirmed previous state |
|
||||
| **Number used:** | 1 | Any number, but usually 0 or 1 | One per ledger index, growing over time |
|
||||
| **Can contents change?** | Yes | No, but the whole ledger could be replaced | Never |
|
||||
| **Transactions are applied in:** | The order they are received | Canonical order | Canonical order |
|
||||
|
||||
Unintuitively, the XRP Ledger never "closes" an open ledger to convert it into a closed ledger. Instead, the server throws away the open ledger, creates a new closed ledger by applying transactions on top of a previous closed ledger, then creates a new open ledger using the latest closed ledger as a base. This is a consequence of [how consensus solves the double-spend problem](consensus-principles-and-rules.html#問題の単純化).
|
||||
|
||||
For an open ledger, servers apply transactions in the order those transactions appear, but different servers may see transactions in different orders. Since there is no central timekeeper to decide which transaction was actually first, servers may disagree on the exact order of transactions that were sent around the same time. Thus, the process for calculating a closed ledger version that is eligible for [validation](consensus-structure.html#検証) is different than the process of building an open ledger from proposed transactions in the order they arrive. To create a "closed" ledger, each XRP Ledger server starts with a set of transactions and a previous, or "parent", ledger version. The server puts the transactions in a canonical order, then applies them to the previous ledger in that order. The canonical order is designed to be deterministic and efficient, but hard to game, to increase the difficulty of front-running Offers in the [decentralized exchange](decentralized-exchange.html).
|
||||
|
||||
Thus, an open ledger is only ever used as a temporary workspace, which is a major reason why transactions' [tentative results may vary from their final results](finality-of-results.html).
|
||||
|
||||
## Ledger Close Times
|
||||
|
||||
The time that a ledger version closed is recorded at the `close_time` field of the [ledger header](ledger-header.html). To make it easier for the network to reach a consensus on an exact close time, this value is rounded to a number of seconds based on the close time resolution, currently 10 seconds. If rounding would cause a ledger's close time to be the same as (or earlier than) its parent ledger's, the child ledger has its close time set to the parent's close time plus 1. This guarantees that the close times of validated ledgers are strictly increasing. <!-- STYLE_OVERRIDE: a number of -->
|
||||
|
||||
Since new ledger versions usually close about every 3 to 5 seconds, these rules result in a loose pattern where ledgers' close times end in :00, :01, :02, :10, :11, :20, :21, and so on. Times ending in 2 are less common and times ending in 3 are very rare, but both occur randomly when more ledgers randomly happen to close within a 10-second window.
|
||||
|
||||
Generally speaking, the ledger cannot make any time-based measurements that are more precise than the close time resolution. For example, to check if an object has passed an expiration date, the rule is to compare it to the close time of the parent ledger. (The close time of a ledger is not yet known when executing transactions to go into that ledger.) This means that, for example, an [Escrow](escrow.html) could successfully finish at a real-world time that is up to about 10 seconds later than the time-based expiration specified in the Escrow object.
|
||||
|
||||
### Example
|
||||
|
||||
The following examples demonstrate the rounding behavior of ledger close times, from the perspective of an example validator, following a ledger with the close time **12:00:00**:
|
||||
|
||||
**Current consensus round**
|
||||
|
||||
1. A validator notes that it was **12:00:03** when the ledger closed and entered consensus. The validator includes this close time in its proposals.
|
||||
2. The validator observes that most other validators (on its UNL) proposed a close time of 12:00:02, and one other proposed a close time of 12:00:03. It changes its proposed close time to match the consensus of **12:00:02**.
|
||||
3. The validator rounds this value to the nearest close time interval, resulting in **12:00:00**.
|
||||
4. Since 12:00:00 is not greater than the previous ledger's close time, the validator adjusts the close time to be exactly 1 second after the previous ledger's close time. The result is an adjusted close time of **12:00:01**.
|
||||
5. The validator builds the ledger with these details, calculates the resulting hash, and confirms in the [validation step](consensus-structure.html#検証) that others did the same.
|
||||
|
||||
Non-validating servers do all the same steps, except they don't propose their recorded close times to the rest of the network.
|
||||
|
||||
**Next consensus round**
|
||||
|
||||
1. The next ledger enters consensus at **12:00:04** according to most validators.
|
||||
2. This rounds down again, to a close time of **12:00:00**.
|
||||
3. Since this is not greater than the previous ledger's close time of 12:00:01, the adjusted close time is **12:00:02**.
|
||||
|
||||
**Next consensus round after that**
|
||||
|
||||
1. The ledger after that enters consensus at **12:00:05** according to most validators.
|
||||
2. This rounds up, based on the close time resolution, to **12:00:10**.
|
||||
3. Since this value is larger than the previous ledger's close time, it does not need to be adjusted. **12:00:10** becomes the official close time.
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
レジャーヘッダー、レジャーオブジェクトID、レジャーオブジェクトタイプについての詳細は、[レジャーデータフォーマット](ledger-data-formats.html)を参照してください。
|
||||
- レジャーヘッダー、レジャーオブジェクトID、レジャーオブジェクトタイプの詳細については、[レジャーのデータ型](ledger-data-formats.html)をご覧ください。
|
||||
- レジャーの状態の変更履歴を追跡する方法については、[レジャーの履歴](ledger-history.html)をご覧ください。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
|
||||
23
content/concepts/ledgers/open-closed-validated-ledgers.ja.md
Normal file
23
content/concepts/ledgers/open-closed-validated-ledgers.ja.md
Normal file
@@ -0,0 +1,23 @@
|
||||
---
|
||||
html: open-closed-validated-ledgers.html
|
||||
parent: ledgers.html
|
||||
blurb: レジャーオブジェクトには、オープン、閉鎖済み、検証済みの3つの状態があります。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
---
|
||||
# オープン、閉鎖済み、および検証済みレジャー
|
||||
|
||||
`rippled`サーバはレジャーのバージョンを _オープン(open)_、_閉鎖済み(closed)_、_検証済み(validated)_ に区別します。サーバはオープンなレジャーを1つ、閉鎖済みだが未検証のレジャーをいくつでも、そして検証済みレジャーの変更不可能な履歴を持ちます。以下の表はその違いをまとめたものです。
|
||||
|
||||
| レジャーの種類: | オープン | 閉鎖済み | 検証済み |
|
||||
|:--------------------------|:--------------|:--------------------------------------------|:--|
|
||||
| **目的:** | 一時的な作業領域 | 次の状態の提案 | 直前の状態の確認 |
|
||||
| **使用する数:** | 1 | 任意の数、通常は0または1 | レジャーインデックスごとに1つ、時間の経過とともに増加 |
|
||||
| **内容は変更可能?** | はい | いいえ、ただし、別のレジャーが採用される可能性あり。 | いいえ |
|
||||
| **トランザクションの適用方法:** | 受信順 | 正規順序 | 正規順序 |
|
||||
|
||||
直感に反し、XRP Ledgerはオープンレジャーを「閉鎖」して閉鎖済みレジャーへと変換することはありません。その代わりに、サーバはオープンレジャーを捨て、以前の閉鎖済みレジャーの上にトランザクションを適用して閉鎖済みレジャーを作成し、最新の閉鎖済みレジャーをベースとして新しいオープンレジャーを作成します。これは、[コンセンサスが二重支出問題を解決する方法](consensus-principles-and-rules.html#simplifying-the-problem)の結果と言えます。
|
||||
|
||||
オープンレジャーでは、サーバはトランザクションを受信した順番にトランザクションを適用しますが、サーバによってトランザクションが異なる順番で表示されることがあります。実際にどのトランザクションが先だったかを決定するための中心的なタイムキーパーが存在しないため、同じ時刻に送信されたトランザクションの正確な順序について、サーバ間で見解が一致しない可能性があります。したがって、[検証](consensus-structure.html#validation)の対象となる閉鎖済みのレジャーバージョンを計算するプロセスは、提案されたトランザクションを受信順に並べてオープンレジャーを構築するプロセスとは異なります。「閉鎖済み」レジャーを作成するために、各XRP Ledgerサーバは、トランザクションのセットと、以前、つまり「親」レジャーを使用します。サーバはトランザクションを正規順序に並べ、その順序で前のレジャーに適用します。正規順序は、[分散型取引所](decentralized-exchange.html)におけるオファーのフロントランニングの難易度を高めるために、決定論的で効率的であるが、悪用されにくいように設計されています。
|
||||
|
||||
このように、オープンレジャーは一時的な作業領域としてしか使用されないため、トランザクションの[暫定的な結果と最終的な結果が異なる可能性がある](finality-of-results.html)という大きな特徴があります。
|
||||
@@ -15,10 +15,10 @@ labels:
|
||||
|
||||
ネットワークとの同期は、通常はおよそ5分から15分で完了します。その間に、サーバーは次のようなさまざまなことを行います。
|
||||
|
||||
- 推奨バリデータリストを読み込み（通常は`vl.ripple.com`から）、信頼できるバリデータを判断します。
|
||||
- 推奨バリデータリストを読み込み（例: `vl.ripple.com`）、信頼できるバリデータを判断します。
|
||||
- [ピアサーバーを検出](peer-protocol.html#ピアの検出)して接続します。
|
||||
- ピアから最新のレジャーの[ヘッダー](ledger-header.html)と完全な[状態情報](ledgers.html#ツリーの形式)をダウンロードし、それを使用してレジャーデータの内部データベースを構築します。
|
||||
- 信頼できるバリデータをリッスンして、最近検証されたレジャーハッシュを見つけます。
|
||||
- ピアから最新のレジャーを完全にダウンロードし、それを使ってレジャーデータの内部データベースを構築します。
|
||||
- 新たにブロードキャストされたトランザクションを収集し、それを進行中のレジャーに適用します。
|
||||
|
||||
サーバーがこれらのタスクを行うときにネットワークに同調して対応できなかった場合は、サーバーはネットワークと同期しない状態になります。
|
||||
|
||||
@@ -174,10 +174,10 @@ Connecting to 127.0.0.1:5005
|
||||
|:----------------------------|:-----------------|:----------------------------|
|
||||
| `hash` | 文字列 | （省略される場合があります）要求されるレジャーの[ハッシュ][]（サーバーがこのハッシュを認識している場合）。 |
|
||||
| `have_header` | ブール値 | 要求されたレジャーのヘッダーセクションがサーバーにあるかどうか。 |
|
||||
| `have_state` | ブール値 | （省略される場合があります）要求されたレジャーの[アカウント状態セクション](ledgers.html#ツリーの形式)がサーバーにあるかどうか。 |
|
||||
| `have_transactions` | ブール値 | （省略される場合があります）要求されたレジャーのトランザクションセクションがサーバーにあるかどうか。 |
|
||||
| `needed_state_hashes` | 文字列の配列 | （省略される場合があります）サーバーが取得する必要がある[状態ツリー](ledgers.html#ツリーの形式)内のオブジェクトのハッシュ（最大16個）。 |
|
||||
| `needed_transaction_hashes` | 文字列の配列 | （省略される場合があります）サーバーが取得する必要があるトランザクションツリー内のオブジェクトのハッシュ（最大16個）。 |
|
||||
| `have_state` | ブール値 | （省略される場合があります）要求されたレジャーの完全な状態データがサーバーにあるかどうか。 |
|
||||
| `have_transactions` | ブール値 | （省略される場合があります）要求されたレジャーの完全なトランザクションセットがサーバーにあるかどうか。 |
|
||||
| `needed_state_hashes` | 文字列の配列 | （省略される場合があります）サーバーが取得する必要がある完全な状態データ内のオブジェクトのハッシュ（最大16個）。 |
|
||||
| `needed_transaction_hashes` | 文字列の配列 | （省略される場合があります）サーバーが取得する必要があるトランザクションセットのオブジェクトのハッシュ（最大16個）。 |
|
||||
| `peers` | 数値 | このレジャーを見つけるためにサーバーが照会するピアの数。 |
|
||||
| `timeouts` | 数値 | これまでにこのレジャーの取得操作がタイムアウトした回数。 |
|
||||
|
||||
|
||||
@@ -206,7 +206,7 @@ rippled json ledger_entry '{ "directory": { "owner": "rf1BiGeXwwQoi8Z2ueFYTEXSwu
|
||||
|
||||
| フィールド | 型 | 説明 |
|
||||
|:------------------------|:---------------------------|:----------------------|
|
||||
| `offer` | オブジェクトまたは 文字列 | 取得する[オファーオブジェクト](offer.html)。文字列の場合、オファーに対する[一意のオブジェクトID](ledgers.html#ツリーの形式)を指定します。オブジェクトの場合、オファーを一意に識別するためのサブフィールド`account`と`seq`を指定します。 |
|
||||
| `offer` | オブジェクトまたは 文字列 | 取得する[オファーオブジェクト](offer.html)。文字列の場合、オファーに対する[一意のオブジェクトID](ledger-object-ids.html)を指定します。オブジェクトの場合、オファーを一意に識別するためのサブフィールド`account`と`seq`を指定します。 |
|
||||
| `offer.account` | 文字列 - [アドレス][] | _(`offer`がオブジェクト形式で指定されている場合、必須)_ オファーを作成したアカウント。 |
|
||||
| `offer.seq` | 符号なし整数 | _(`offer`がオブジェクト形式で指定されている場合、必須)_ オファーオブジェクトを作成したトランザクションの[シーケンス番号][]。 |
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ labels:
|
||||
# DirectoryNode
|
||||
[[ソース]](https://github.com/XRPLF/rippled/blob/5d2d88209f1732a0f8d592012094e345cbe3e675/src/ripple/protocol/impl/LedgerFormats.cpp#L44 "Source")
|
||||
|
||||
`DirectoryNode`オブジェクトタイプは、レジャーの状態ツリー内の他オブジェクトへのリンクのリストを提供します。概念上の1つの _ディレクトリー_ は、1つ以上の各DirectoryNodeオブジェクトが含まれる二重リンクリストの形式になっています。各DirectoryNodeオブジェクトには、他オブジェクトの[ID](ledgers.html#ツリーの形式)が最大32個まで含まれています。1番目のオブジェクトはディレクトリーのルートと呼ばれ、ルートオブジェクト以外のオブジェクトはすべて必要に応じて自由に追加または削除できます。
|
||||
`DirectoryNode`オブジェクトタイプは、レジャーの状態ツリー内の他オブジェクトへのリンクのリストを提供します。概念上の1つの _ディレクトリー_ は、1つ以上の各DirectoryNodeオブジェクトが含まれる二重リンクリストの形式になっています。各DirectoryNodeオブジェクトには、他オブジェクトの[ID](ledger-object-ids.html)が最大32個まで含まれています。1番目のオブジェクトはディレクトリーのルートと呼ばれ、ルートオブジェクト以外のオブジェクトはすべて必要に応じて自由に追加または削除できます。
|
||||
|
||||
2種類のディレクトリーがあります。
|
||||
|
||||
|
||||
@@ -99,7 +99,7 @@ AMMのLPトークンを使って落札すると、落札額はAMMに返金され
|
||||
|
||||
P = M
|
||||
|
||||
**注記:** 台帳を作成する際に、ネットワーク上のすべてのサーバーが同じ結果になるように、時間の計測は前回の台帳の[正規の終了時刻](ledgers.html#ledger-close-times) に基づいており、これはおおよその目安の時間です。
|
||||
**注記:** 台帳を作成する際に、ネットワーク上のすべてのサーバーが同じ結果になるように、時間の計測は前回のレジャーの[正規の閉鎖時刻](ledger-close-times.html) に基づいており、これはおおよその目安の時間です。
|
||||
|
||||
## 払い戻し
|
||||
|
||||
@@ -115,7 +115,7 @@ R = B × (1 - t)
|
||||
|
||||
特殊なケースとして、オークションスロットの最終（20番目）区間では、払い戻し額は0となる。
|
||||
|
||||
**注記:** XRP Ledgerの時刻と同様に、トランザクション処理では _前回の_ 台帳の[正規の終了時刻](ledgers.html#ledger-close-times)を使用するため、実時間と最大で約10秒の差が生じる場合があります。
|
||||
**注記:** XRP Ledgerの時刻と同様に、トランザクション処理では _前回の_ レジャーの[正規の閉鎖時刻](ledger-close-times.html)を使用するため、実時間と最大で約10秒の差が生じる場合があります。
|
||||
|
||||
|
||||
## エラーケース
|
||||
|
||||
@@ -920,28 +920,32 @@ pages:
|
||||
targets:
|
||||
- en
|
||||
|
||||
# TODO: update translation. Some parts split into "ledger structure"
|
||||
- md: concepts/ledgers/ledgers.ja.md
|
||||
outdated_translation: true
|
||||
targets:
|
||||
- ja
|
||||
|
||||
# TODO: translate. Some parts taken from "ledgers.md"
|
||||
- md: concepts/ledgers/ledger-structure.md
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/ledgers/ledger-structure.ja.md
|
||||
targets:
|
||||
- ja
|
||||
|
||||
# TODO: translate. Content mostly split off from "ledgers.md"
|
||||
- md: concepts/ledgers/open-closed-validated-ledgers.md
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/ledgers/open-closed-validated-ledgers.ja.md
|
||||
targets:
|
||||
- ja
|
||||
|
||||
# TODO: translate. Content mostly split off from "ledgers.md"
|
||||
- md: concepts/ledgers/ledger-close-times.md
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: concepts/ledgers/ledger-close-times.ja.md
|
||||
targets:
|
||||
- ja
|
||||
|
||||
# TODO: add a "ledger history" page that doesn't go too deep into
|
||||
|
||||
Reference in New Issue
Block a user