完全履歴サーバーとClio

XRPレジャーの完全な履歴記録がどのように保存・提供されているか、そしてなぜほとんどのノードがそのすべてを保持していないのかを解説します。

なぜすべてのノードがすべてを保存しているわけではないのか

Ledger Structure and the Close Processで述べたとおり、XRPレジャーは2012年以来、およそ3〜5秒ごとに新しいレジャーバージョンを生成しており、10年以上にわたって非常に大量の履歴データが蓄積されています。ジェネシスまで遡る完全な履歴を保存することはリソース集約的であるため、ほとんどのrippledサーバーは、完全な履歴アーカイブではなく、通常の運用(現在の取引の検証、直近のアカウント・取引の照会への対応)に十分な、直近の一定期間分のレジャー履歴のみを保持するよう設定されています。

完全履歴サーバー

完全履歴サーバーは、直近の一定期間分だけでなく、ジェネシス以降の完全なレジャー履歴を保持するよう特別に設定されたrippledノードです。これらは、比較的少数の運営者によって運用されており、多くの場合、ブロックエクスプローラー、リサーチ、コンプライアンス・監査ツール、その他、任意の古い取引やアカウント状態を実際に照会する必要があるアプリケーションを特にサポートするために運用されています。

Clio

Clioは、コアのrippledバリデーターソフトウェアとは別の、大規模なXRPLの履歴データを効率的に提供することを目的として特別に構築された専用のサーバー実装です。たまたま履歴も保存しているバリデーターとは異なり、Clioは読み取りが多いAPIサーバーとして特別に最適化されています。検証済みのレジャーデータを(多くの場合、完全履歴を持つrippledノードから)取り込み、なじみのある同じAPIインターフェースを通じてアプリケーションに提供しますが、そのインフラは、コンセンサスへの参加ではなく、大量の履歴クエリのために特別にチューニングされています。

なぜこれらの役割を分離することが理にかなうのか

「新しいレジャーを生成・検証する」こと(バリデーターの中核的な仕事)と、「大量の履歴データをアプリケーションに効率的に提供する」こと(Clioの専門分野)を分離することで、単一のソフトウェアに、レイテンシに敏感なコンセンサスの役割と、ストレージ・クエリの負荷が高いアーカイブの役割の両方を同時にこなさせるのではなく、それぞれのインフラを実際の仕事に合わせて最適化できます。

なぜこれが開発者やリサーチャーにとって重要なのか

古い取引履歴を照会する必要があるアプリケーション(税務報告ツール、コンプライアンス・監査システム、履歴分析ダッシュボード、あるいはレジャーの活動を時系列で研究するリサーチプロジェクトなど)を構築する人は、一般に、標準的な直近履歴のみのパブリックノードではなく、完全履歴のソース(自己ホストの完全履歴ノード、Clioのデプロイ、またはサードパーティの履歴データAPIのいずれか)に頼ることになります。XRPL上に構築するために利用できるより広範なツールキットについては、Developer Tools & SDKs(英語)を参照してください。