메인 콘텐츠로 건너뛰기

​
목적 및 범위

이 문서는 go-stablenet의 ancient store(일반적으로 “freezer”라고도 함) 하위 시스템을 설명하며, 과거 블록체인 데이터의 저장소 라이프사이클을 관리하는 방식을 다룹니다. Ancient store는 활성 데이터베이스(active database)의 성능과 디스크 사용을 최적화하기 위해 오래된 블록 데이터를 분리하여 보관하는 추가 전용(append-only) 아카이브 저장소 레이어입니다. 이 페이지는 다음을 다룹니다:
  • Ancient store 아키텍처 및 활성 데이터베이스와의 역할 분리
  • 활성 저장소에서 ancient 저장소로의 데이터 마이그레이션 흐름
  • Ancient store 작업(읽기, 쓰기, 잘라내기)
  • 고정(frozen) 데이터가 존재하는 상태에서의 체인 되감기 처리
  • Era1 형식을 사용한 과거 데이터 가져오기 및 내보내기
활성 데이터베이스 레이어 및 trie 저장소에 대한 정보는 데이터베이스 레이어 및 Merkle Patricia Trie을 참조하세요.
캐싱 및 스냅샷에 대한 정보는 캐싱 및 스냅샷을 참조하세요.

​
Ancient Store 아키텍처

Ancient store는 불변(immutable) 이 된 과거 블록체인 데이터를 저장하기 위한 전용 저장소입니다.
이 레이어는 성능 향상과 디스크 효율 개선을 위해 다음과 같은 특성을 가집니다:
  • 추가 전용(append-only) 쓰기 모델
  • 블록 번호 기준의 순차 접근
  • 활성 키-값 데이터베이스와 물리적/논리적 분리
  • 오래된 데이터에 대한 랜덤 접근 비용 최소화

​
저장소 레이어

블록체인 데이터는 두 개의 주요 레이어로 나뉩니다:
  • 활성 데이터베이스
    최근 블록, 상태(trie), 헤더, 트랜잭션 인덱스 등
    잦은 랜덤 접근 및 쓰기가 필요한 데이터
  • Ancient store
    충분히 오래되어 더 이상 변경되지 않는 블록, 영수증, 총 난이도 데이터

​
데이터베이스 인터페이스

ethdb.Database 인터페이스는 활성 및 ancient 저장소 모두에 대해 통합된 접근 지점을 제공합니다:
MethodDescriptionStorage Layer
Ancients()고정(frozen)된 블록 수 반환Ancient store
TruncateHead(n)블록 n 이후의 ancient 데이터 제거Ancient store
Get(key) / Put(key, val)키-값 읽기/쓰기Active database
NewBatch()배치 쓰기 생성Active database
Ancient store는 동일한 DB 핸들을 통해 접근되지만, 순차적·불변 데이터에 최적화된 별도의 내부 구현을 사용합니다.

​
데이터 라이프사이클 및 마이그레이션

​
블록 데이터 상태

블록체인 데이터는 블록의 연령과 상태 가용성에 따라 다음 단계를 거칩니다:
  1. 활성 상태
    최근 블록으로, 상태(trie) 접근 및 되감기가 가능해야 함
  2. 전이 상태
    상태는 더 이상 필요 없지만 아직 ancient로 이동하지 않은 구간
  3. 고정(frozen) 상태
    상태 접근이 필요 없고, 불변으로 간주되어 ancient store에 저장됨

​
Freezer 임계값

Freezer 임계값은 블록이 ancient store로 이동되는 기준 지점입니다.
이 지점 이전의 블록은 되감기 시 상태 복구 대상이 되지 않는 블록으로 간주됩니다. 주요 고려사항:
  • 상태 가용성
    상태(trie)가 필요한 블록은 활성 저장소에 유지되어야 함
  • TriesInMemory 상수
    일반적으로 최근 약 128개 블록은 활성 DB에 유지됨
  • Snap 동기화
    Snap 동기화 중에는 피벗 블록이 freezer 경계에 영향을 미칠 수 있음
  • 전체 동기화
    상태가 더 이상 필요 없다고 판단되면 오래된 블록이 순차적으로 이동됨

​
Ancient Store 작업

​
Ancient 데이터 읽기

BlockChain 로직은 오래된 블록에 접근할 때 호출자에게 투명하게 ancient store에서 데이터를 읽습니다. 즉, 상위 계층에서는 데이터가 활성 DB에 있는지 ancient store에 있는지를 명시적으로 구분할 필요가 없습니다.

​
쓰기 및 잘라내기

Ancient store의 수정 작업은 제한된 경우에만 발생합니다:
  1. 체인 되감기(SetHead)
    고정 임계값 이하로 체인을 되감아야 할 때
  2. 과거 데이터 가져오기
    Era1 아카이브를 통해 과거 데이터를 주입할 때
TruncateHead는 ancient store에서 블록 번호 기준으로 이후 데이터를 제거합니다.

​
Ancient 데이터로 체인 되감기

​
되감기 프로세스

체인을 되감을 때(SetHead, SetHeadWithTimestamp)
고정 데이터에 대한 특별한 처리가 필요합니다.
ScenarioActive DB ActionAncient Store Action
목표가 고정 임계값 위활성 블록/헤더 삭제없음
목표가 고정 임계값 아래모든 활성 블록 삭제ancient 잘라내기
제네시스까지 되감기활성 DB 초기화모든 ancient 제거
이 로직은 setHeadBeyondRoot 흐름에서 구현됩니다.

​
누락된 상태 처리

되감기 시 시스템은 상태가 존재하는 블록을 반드시 찾아야 합니다:
  1. HasState(root) 또는 stateRecoverable(root) 확인
  2. 상태가 없으면 부모 블록으로 계속 이동
  3. Snap 동기화 피벗 아래로는 되감기 금지
  4. 복구 가능한 경우 triedb.Recover(root) 시도

​
Ancient 잘라내기 안전성

Ancient 잘라내기는 다음 안전 규칙을 따릅니다:
  • 단일 TruncateHead 호출로 수행
  • 활성 DB 정리가 선행됨
  • 제거된 블록의 해시/번호 매핑 삭제
  • 체인 헤드 마커를 원자적으로 갱신

​
과거 데이터 가져오기 및 내보내기

​
Era1 아카이브 형식

go-stablenet은 Era1 형식을 사용하여 블록체인 과거 데이터를 묶음 단위로 관리합니다.
ComponentContentPurpose
Era Archive약 8192 블록순차 저장 단위
Block DataHeader, Body, Tx블록 재구성
Receipts트랜잭션 영수증실행 결과 검증
Total Difficulty누적 난이도체인 가중치 계산
Root HashEra 머클 루트무결성 검증

​
가져오기 프로세스

ImportHistory는 Era1 아카이브를 직접 ancient store에 기록합니다. 활성 DB를 거치지 않으므로 빠른 부트스트랩이 가능합니다.

​
내보내기 프로세스

ExportHistory는 기존 체인 데이터를 Era1 형식으로 패키징하여 외부 저장 또는 배포에 사용할 수 있습니다.

​
직접 Ancient Store 초기화

빈 노드에 외부 ancient store를 연결할 경우 시작 시 자동 초기화가 수행됩니다. 이는 다음 시나리오에 유용합니다:
  • 신뢰 가능한 아카이브에서 빠른 초기화
  • ancient 데이터와 활성 데이터의 물리적 분리
  • 장애 복구 환경 구성

​
BlockChain과의 통합

​
BlockChain 구조 필드

type BlockChain struct {
	db ethdb.Database
	triedb *triedb.Database
	stateCache state.Database
	currentBlock atomic.Pointer[types.Header]
	currentSnapBlock atomic.Pointer[types.Header]
	bodyCache *lru.Cache[common.Hash, *types.Body]
	receiptsCache *lru.Cache[common.Hash, []*types.Receipt]
	blockCache *lru.Cache[common.Hash, *types.Block]
}

​
Ancient Store 쿼리 패턴

OperationImplementationAncient Check
번호로 블록 조회Ancients() 기준 분기Yes
헤더 조회활성 → ancient 폴백Implicit
체인 연속성 검증ancient 경계 확인Yes
상태 가용성 확인ancient 블록은 상태 없음Yes

​
Snap 동기화와의 상호작용

  • Snap 피벗 블록이 ancient 경계에 위치할 수 있음
  • 영수증 체인은 InsertReceiptChain으로 ancient 채움
  • currentSnapBlock과 currentBlock 불일치 가능
  • 경계 아래로의 snap 삽입 방지

​
유지 관리 작업

​
디스크 공간 관리

Ancient store는 전체 디스크 사용량의 큰 비중을 차지하므로 블록 수와 디스크 사용량을 지속적으로 모니터링해야 합니다.

​
데이터베이스 손상 복구

손상 원인:
  • 잘라내기 중 비정상 종료
  • 파일시스템 오류
  • 수동 파일 변경
복구 절차:
  1. 시작 시 ancient 카운트와 헤드 검증
  2. 불일치 시 자동 잘라내기
  3. 필요 시 SetHead를 통한 수동 복구

​
모범 사례

​
운영 가이드라인

  1. Ancient store는 실행 중에도 백업 가능
  2. I/O 분산을 위해 별도 디스크 배치 고려
  3. ancient 블록 수와 디스크 사용량 분리 모니터링
  4. ancient 데이터는 불변이며 잘라내기로만 제거됨

​
성능 고려사항

AspectRecommendationRationale
Ancient 위치순차 읽기 성능 우수한 디스크Append-only 패턴
Active DB랜덤 I/O 성능 우수한 디스크빈번한 읽기/쓰기
메모리최소 캐싱접근 빈도 낮음
동기화Full sync는 자연스럽게 채움Snap은 별도 영수증 필요