getBlock",
tooltip: "",
icon: "",
},
"2": {
title: "Full block and its transactions at a slot
",
tooltip: "",
icon: "",
},
"3": {
title: "Only maxSupportedTransactionVersion: 0 is accepted
",
tooltip: "",
icon: "",
},
id: 0,
},
{
"1": {
title: "getTransaction
",
tooltip: "",
icon: "",
},
"2": {
title: "A confirmed transaction by signature
",
tooltip: "",
icon: "",
},
"3": {
title:
"Rejects processed commitment; returns null if not found
",
tooltip: "",
icon: "",
},
id: 1,
},
{
"1": {
title: "getSignaturesForAddress
",
tooltip: "",
icon: "",
},
"2": {
title: "Signatures that reference an address, newest first
",
tooltip: "",
icon: "",
},
"3": {
title:
"Limit 1 to 1,000 per call; paginate with before and until
",
tooltip: "",
icon: "",
},
id: 2,
},
{
"1": {
title: "getBlocks
",
tooltip: "",
icon: "",
},
"2": {
title: "Confirmed slots in a range
",
tooltip: "",
icon: "",
},
"3": {
title: "Range capped at 500,000 slots
",
tooltip: "",
icon: "",
},
id: 3,
},
{
"1": {
title: "getBlockTime
",
tooltip: "",
icon: "",
},
"2": {
title: "Estimated production time of a block
",
tooltip: "",
icon: "",
},
"3": {
title: "Returns null if no timestamp was recorded
",
tooltip: "",
icon: "",
},
id: 4,
},
{
"1": {
title: "getFirstAvailableBlock
",
tooltip: "",
icon: "",
},
"2": {
title: "Lowest slot available from storage
",
tooltip: "",
icon: "",
},
"3": {
title: "The archive's floor, not the node's
",
tooltip: "",
icon: "",
},
id: 5,
},
],
}}
/>
대부분의 히스토리컬 파이프라인은 이 중 두 메서드로 구성된다. `getSignaturesForAddress`로 주소의 이력을 역순으로 페이지 넘기고, 각 트랜잭션의 상세 정보를 `getTransaction`으로 가져온다. signature 조회는 [호출당 최대 1,000개 결과](https://www.alchemy.com/docs/reference/solana-api-quickstart)만 반환하므로, 활발한 주소의 첫 트랜잭션까지 거슬러 올라가려면 페이지네이션된 호출이 길게 이어져야 하고, 그중 노드의 최소 원장 슬롯을 지난 거의 모든 호출은 아카이브에서 서빙된다.
이 지점에서 취약한 아카이브의 문제가 드러난다. 프로바이더의 장기 저장소에 빈틈이 있으면, 백필 도중 깊숙이 들어간 어느 호출이 "slot skipped" 또는 "missing in long-term storage" 에러를 반환하는데, 이를 확인하지 않으면 아무도 모르는 사이 인덱스에 구멍이 생긴다. 모든 프로바이더가 같은 메서드 이름을 노출한다. 다른 것은 그 뒤의 저장소에 빈틈이 있는지, 그리고 수천 번씩 연속 호출하며 페이지를 넘길 때 얼마나 빠르게 답하는지다.
## 전체 블록 및 트랜잭션 이력은 어떻게 쿼리하는가?
쿼리 자체는 평범한 JSON-RPC다. 별도의 아카이벌 API도, 이력을 열어주는 특별한 파라미터도 없다. 체인 최신 상태에서 쓰는 것과 같은 메서드를 호출하면, 슬롯이 노드의 로컬 하한선 아래로 내려갈 때 프로바이더의 아카이브가 알아서 응답한다.
깊은 이력에서 블록 하나를 가져오는 예는 다음과 같다.
응답에는 블록 전체, 그 안의 모든 트랜잭션, 그리고 각 트랜잭션의 status와 메타데이터가 담긴다. 모든 호출의 params에 `maxSupportedTransactionVersion: 0`를 반드시 넣어야 한다. 넣지 않으면 versioned 트랜잭션이 포함된 블록에서 호출이 에러를 내는데, mainnet에서는 대부분의 블록이 여기 해당한다.
주소의 전체 이력을 훑는 것은 위 표의 두 메서드 패턴을 루프로 돌리는 것이다. `getSignaturesForAddress`로 역순 페이지네이션을 하다가 결과가 빈 값이 나오면 멈추고, 각 트랜잭션의 상세를 가져온다.
entry.signature));
before = page[page.length - 1].signature;
}
// Resolve each signature to full transaction detail
const tx = await rpc
.getTransaction(signatures[0], {
maxSupportedTransactionVersion: 0,
encoding: "jsonParsed",
})
.send();`}
/>
지갑 하나라면 이 루프만으로 충분하고, 노트북에서도 문제없이 돌아간다. 하지만 대상 주소가 수백만 개의 signature를 가진 활발한 프로그램이거나, 체인상의 모든 주소에 대한 이력이 필요할 때는 이 방식으로 부족하다. 그것이 백필 문제이며, 아래 절에서 데이터가 어디서 오는지와 빈틈 없이 로드하는 방법을 다룬다.
## Solana의 전체 이력은 실제로 어떻게 저장되는가?
어떤 밸리데이터도 원장 전체를 보관하지 않으므로, 장기 이력은 완전히 노드 바깥에 존재한다. 실무에서는 두 시스템이 이를 담당한다.
오래된 방식은 웨어하우스 패턴이다. 전용 노드가 finalize된 블록을 [Google Bigtable](https://docs.anza.xyz/operations/setup-an-rpc-node)에 계속 업로드하고, RPC 노드가 더 이상 보관하지 않는 슬롯에 대한 쿼리를 받으면 그 저장소로 폴백한다. 최근 슬롯은 노드의 로컬 데이터베이스에서, 그보다 오래된 슬롯은 Bigtable에서 온다. 대부분의 프로덕션 Solana RPC는 오랫동안 이런 방식으로 깊은 이력을 서빙해왔다. 이 방식의 대가는 집중화로, 체인 전체의 과거가 하나의 독점적인 클라우드 데이터베이스 안에 놓이게 된다.
더 새로운 방식은 Triton과 Yellowstone 프로젝트가 주도하는 오픈소스 아카이브인 [Old Faithful](https://old-faithful.net/)이다. genesis 이후 모든 블록을 콘텐츠 주소화된 CAR 파일로 패키징하고, IPFS, Filecoin, S3 호환 스토리지에 분산 저장하며, 표준 Solana JSON-RPC와 gRPC로 서빙한다. 이 프로젝트는 Solana 전체 이력이 어느 한 회사의 데이터베이스에 의존하지 않도록 만들기 위해 존재하며, genesis부터 검증 가능한 커버리지가 필요한 팀들은 이를 레퍼런스 아카이브로 취급한다.
프로바이더 뒤에 어떤 백엔드가 있든, 핵심은 아카이브가 노드와는 별개의 시스템이라는 점이다. 깊이와 완전성은 그 시스템의 속성이며, 가정하기보다는 직접 물어볼 가치가 있다.
## 대규모로 계정 및 토큰 이력을 얻으려면 어떻게 해야 하는가?
"대규모 Solana 이력"을 원하는 팀들이 실제로 원하는 것은 원시 블록이 아닌 경우가 많다. 시간에 따른 지갑 잔액, 어떤 주소가 이제껏 수행한 모든 전송, 토큰의 전체 보유자 이력을 대시보드나 세금 신고서를 구동할 만큼 빠르게 서빙하고 싶어 한다. 이런 것들은 원장 안에 쿼리 가능한 형태로 존재하지 않는다. 파생시켜야 한다.
프로젝트마다 방법은 거의 동일하다. 아카이벌 RPC에서 주소의 전체 트랜잭션 이력을 가져오고, 그 트랜잭션들을 순서대로 리플레이하며, 그 과정에서 필요한 상태를 계산한다. 각 트랜잭션 이후의 잔액, 소유권 변경, 전송 흐름 등이다. 그 결과를 자체 데이터베이스에 기록해서, 비용이 많이 드는 리플레이가 요청마다가 아니라 한 번만 일어나도록 한다. 어떤 체인에서든 이것은 블록체인 인덱서의 역할이다. Solana에서는 이것이 히스토리컬 상태에 도달하는 유일한 경로인데, 노드가 아무것도 보관하지 않기 때문이다.
가장 첨예한 질문, 즉 지갑이 특정 슬롯에서 무엇을 보유했는가에 대해서는 이제 직접적인 답을 제공한다. [`getTokenAccountsByOwnerAtSlot`](https://www.alchemy.com/docs/chains/solana/solana-api-endpoints/get-token-accounts-by-owner-at-slot)은 표준 `getTokenAccountsByOwner`의 문법을 그대로 유지하면서 `slot` 파라미터를 추가해, 한 번의 호출로 그 시점의 지갑의 정확한 토큰 잔액을 반환한다. 리플레이가 아니라 지속적으로 유지되는 히스토리컬 인덱스로 뒷받침되므로, 특정 시점의 보유량을 알고 싶을 때는 위에서 설명한 전체 재구성 파이프라인이 필요 없어진다. [historical Solana token balances 출시 포스트](https://www.alchemy.com/blog/historical-solana-token-balances)에서 그 동작 원리를 다룬다.
시간에 따른 잔액, 전송, 토큰 메타데이터 등 그 외 흔히 필요한 파생 데이터 형태에 대해서는 [Data APIs](https://www.alchemy.com/docs/data)가 이미 계산된 형태로 제공하므로 인덱싱 프로젝트 자체를 건너뛸 수 있다. 커스텀 파생 데이터나 파이프라인의 완전한 통제가 필요할 때는 직접 인덱서를 구축하라. 표준 형태로 충분하다면 관리형 메서드를 쓰라. 작동할 수 없는 것은 일반 노드에게 과거 계정 상태를 요청하는 것뿐이다. 노드가 애초에 그것을 보관한 적이 없기 때문이다. 작동하는 모든 답은 이력 위에 구축된 인덱스에서 나온다.
## genesis부터 무너지지 않고 인덱스를 백필하려면 어떻게 해야 하는가?
히스토리컬 파이프라인에서 어려운 부분은 콜드 스타트다. 인덱스는 비어 있고, 수억 개의 슬롯을 로드해야 하며, 로드하는 내내 체인은 계속 새 블록을 생성한다. 백필과 라이브 피드가 깔끔하게 맞물리지 않으면 한쪽이 끝난 지점과 다른 쪽이 시작한 지점 사이에 틈이 생긴다.
많은 팀이 전체 백필을 아카이벌 RPC 폴링으로 시작하는데, genesis 규모에서는 이것이 상당히 고통스러워진다. 레이트 리밋, 수억 개의 슬롯에 걸친 요청당 비용, 그리고 아무것도 놓치지 않았음을 증명할 깔끔한 방법의 부재가 그것이다. 프로덕션 환경을 견뎌내는 패턴은 각 단계에 서로 다른 소스를 쓴다. 대량 이력은 아카이브에서 바로 가져오는데, [Jetstreamer](https://github.com/anza-xyz/jetstreamer) 같은 툴은 Old Faithful에서 직접 스트리밍한다. 체인 최신 상태는 폴링이 아니라 라이브 스트림에서 가져온다.
라이브 쪽은 Yellowstone 호환 [Solana gRPC 스트림](https://www.alchemy.com/solana-grpc)이 새 트랜잭션과 계정 업데이트를 계정, 프로그램, 또는 signature 기준으로 필터링해 인덱서에 실시간으로 밀어준다. 백필과 스트림 사이의 이음매는 보통 파이프라인이 새는 지점이며, 이를 봉합하는 것이 replay다. [저희 gRPC](https://www.alchemy.com/blog/introducing-alchemy-solana-grpc)는 클라이언트가 `from_slot` 파라미터로 재연결하면서 다운되어 있던 동안 놓친 슬롯을 다시 받을 수 있게 해서, 연결이 끊겨도 데이터에 구멍이 남지 않도록 한다. 저희는 또한 [failover를 견디면서도 메시지를 놓치지 않는 스트리밍 레이어](https://www.alchemy.com/blog/zero-downtime-zero-gaps-solana-grpc-streaming)를 구축했는데, 이는 그렇지 않으면 인덱서 옆에 별도로 돌려야 하는 gap-detection 서비스에 해당하는 작업이다. 아카이브가 과거를 커버하고 스트림이 최신 상태를 커버하면, replay가 그 둘을 꿰매어 이어준다.
## Solana 아카이벌 프로바이더에서 무엇을 확인해야 하는가?
가장 먼저 확정해야 할 것은 깊이이며, 어떤 프로바이더에게든 정확히 이렇게 물어볼 가치가 있다. genesis부터 인덱싱하는가, 아니면 더 최근의 높이부터인가? 하한선을 밝히지 않은 채 "전체 히스토리컬 데이터"라고 말하는 경우가 흔하며, 보통 그 하한선은 백필이 거기서 죽고 나서야 발견된다.
나머지 체크리스트는 백필이 실제로 어떻게 돌아가는지에서 나온다. 완전성이 중요한 이유는 구멍 하나가 그 위에 쌓은 인덱스 전체를 망가뜨리기 때문이다. 속도가 중요한 이유는 전체 signature 이력을 훑는 작업이 수천 번의 순차적인 아카이브 읽기이므로, 호출당 지연시간이 곱해져 몇 시간 또는 며칠의 실제 시간으로 늘어나기 때문이다. 표준 JSON-RPC가 중요한 이유는 독점적인 히스토리컬 엔드포인트가 파이프라인을 특정 벤더에 묶어버리는 반면, 일반 RPC는 재작성이 전혀 필요 없기 때문이다. 그리고 가격이 중요한 이유는 깊은 이력이 본질적으로 읽기 중심이기 때문이다.
저희는 이 체크리스트를 기준으로 아카이벌 액세스를 구축했다. [genesis부터의 완전한 블록 및 트랜잭션 이력](https://www.alchemy.com/docs/reference/solana-api-quickstart)을 표준 JSON-RPC로 제공하며, [저희 벤치마크](https://www.alchemy.com/blog/solana-infrastructure)에서는 히스토리컬 `getTransaction`이 다른 프로바이더보다 최대 20배 빠르게 동작했고, `getBlock`은 최대 3배, `getProgramAccounts` 같은 무거운 호출은 최대 10배 빠르게 동작했다. 코드 변경이나 독점 메서드는 전혀 필요하지 않다. [Solana에서 가장 빠른 아카이벌 메서드를 어떻게 구축했는지에 대한 엔지니어링 스토리](https://www.alchemy.com/blog/how-alchemy-built-the-fastest-archival-methods-on-solana)에서 이 수치들 뒤의 아키텍처를 다룬다. 깊이, 업타임, 가격, 툴링을 전체적으로 비교하려면 [최고의 Solana RPC 프로바이더 9선 결정 가이드](https://www.alchemy.com/overviews/solana-rpc)에서 시장 전체를 다룬다. 어떤 프로바이더를 선택하든, 백필을 시작하기 전에 genesis 깊이와 완전성에 대한 답을 문서로 받아두라.
## Alchemy에서 Solana 히스토리컬 파이프라인을 구축하세요
작동하는 히스토리컬 파이프라인에는 두 가지가 필요하다. genesis부터 백필할 만큼 깊은 아카이브와, 최신 상태를 따라잡을 만큼 빠른 스트림이다. 저희는 이 둘을 [Alchemy의 Solana 플랫폼](https://www.alchemy.com/solana)의 일부로 운영한다. 아카이벌 읽기는 전체 블록 및 트랜잭션 이력을 표준 JSON-RPC로 제공하므로, 기존 Solana 클라이언트를 Alchemy 엔드포인트로 향하게 하는 것이 마이그레이션의 전부다. [Solana gRPC 스트리밍](https://www.alchemy.com/solana-grpc)은 Yellowstone과 호환되며 재연결 시 replay를 지원하고, 월 최소 사용량이나 플랜 가입 없이 TB당 $75의 종량제로 가격이 책정된다.
계약도 영업 통화도 없이 무료 티어에서 시작하라. Solana 인프라를 구축하는 팀은 [$20M Solana Fund](https://www.alchemy.com/solana-20m-fund)를 통해 최대 $25,000의 크레딧도 신청할 수 있다. 파이프라인이 가동되면, 노드가 버리는 이력은 더 이상 여러분의 문제가 아니게 된다.