전체 이력 서버와 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 배포, 또는 제3자 역사적 데이터 API)에 의존하게 됩니다. XRPL 위에 구축하는 데 사용할 수 있는 더 넓은 툴킷은 Developer Tools & SDKs(영어)를 참고하세요.