レジャーの構造とクローズプロセス

XRPレジャーが、状態と履歴を連続する不変のレジャーバージョンとしてどのように編成しているかを解説します。

レジャーバージョン

XRPLの履歴は、番号が振られた一連のレジャーバージョンとして編成されています。それぞれが、ある時点でのアカウント残高とオブジェクトの状態の完全なスナップショットに加え、前のバージョンからそれを生成するために適用された取引のリストを表します。新しいレジャーバージョンは、コンセンサスプロセスを通じておよそ3〜5秒ごとに生成されます。

レジャーバージョンの中身

クローズされた各レジャーバージョンには、以下が含まれます。

• レジャーヘッダー — シーケンス番号、前のレジャーを参照するハッシュ、タイムスタンプを含みます。
• 状態ツリー — すべてのアカウント、その残高、そのアカウントが所有するオブジェクト(トラストライン、オファー、エスクローなど)を含み、任意の状態の断片を暗号学的に証明できるよう、マークル木に似た構造で符号化されています。
• 取引ツリー — そのレジャーバージョンで適用されたすべての取引を、同様にマークル木に似た構造でリスト化しています。

クローズプロセス

レジャーを「クローズ」するとは、ネットワークが次のバージョンについてコンセンサスに達し、それを確定させる行為です。クローズされると:

• そのレジャー内の取引順序は固定され、変更できません。
• その結果生じたアカウント残高と状態は最終確定します。
• 次のレジャーバージョンがその上に積み重なる形で構築され始めます。

ファイナリティは、その後の多数のブロックにわたって確率的に生じるのではなく、レジャーのクローズ時点で生じるため、Bitcoinのように「確認」を待つことに相当するものは存在しません。クローズされたレジャーに含まれた取引は、それで完了です。

シーケンス番号と「last ledger sequence」安全機能

すべてのアカウントには、それが送信する各取引ごとに増加するシーケンス番号があり、そのアカウント自身の取引のリプレイや順序の入れ替えを防いでいます。取引にはLastLedgerSequenceという値を指定することもでき、これを超えると自動的に期限切れとみなされ、決して適用されなくなります。これにより、ある取引が宙に浮いた状態のままになることなく、成功したか、確定的に失敗したかのいずれかであることを確実に知ることができます。

完全な履歴と現在の状態

完全な履歴を持つXRPLサーバーを運用するには、ジェネシスまで遡るすべてのレジャーバージョンを保存する必要があり、これはデータ集約的です。特に完全履歴ノードとして設定されていない限り、ほとんどのバリデーターやAPIを提供するノードは、直近の一定期間分のレジャー履歴(と現在の状態)のみを保持しており、過去のクエリ用には専用の完全履歴サーバーやサードパーティのアーカイブが利用可能です。