상태 스냅샷은 특정 블록 높이의 애플리케이션 상태를 묶어 둔 파일입니다. 새 노드가 제네시스부터 모든 거래를 다시 실행하지 않고 빠르게 시작하도록 돕습니다. 하지만 내려받은 파일의 체크섬이 맞는다고 정본 상태(canonical state)가 증명되지는 않습니다. 체인 ID, 스냅샷의 높이·형식·조각, 독립된 출처에서 얻은 신뢰 높이와 블록 해시, 헤더가 약속한 AppHash를 확인하고, 노드가 이후 블록을 정상적으로 검증하며 따라가는지 점검해야 합니다.
스냅샷은 상태의 지름길이지 독립 원장이 아니다
전체 동기화(full sync)는 과거 블록을 내려받아 상태 전환을 차례로 실행하며 현재 상태를 만듭니다. 상태 동기화(state sync)는 최근 높이의 스냅샷을 받아 상태를 복원하고, 그 지점 이후의 블록을 검증합니다. 시작 시간은 줄지만 신뢰할 헤더를 어디서 얻는지, 스냅샷을 어떤 루트 값에 맞춰 검증하는지가 보안의 경계가 됩니다.
Ethereum 노드 문서도 동기화 방식마다 검증과 저장의 득실이 다르다고 설명합니다. 제네시스부터 다시 실행하는 방식이 있고, 신뢰할 체크포인트에서 현재 상태로 바로 접근하는 방식도 있습니다. 네트워크와 클라이언트마다 방식이 다르므로 ‘공식 스냅샷’이라는 이름만 보고 전체 검증과 같다고 쓰지 않습니다.
파일이 온전하다는 증거와 그 파일이 정본 상태라는 증거는 서로 다릅니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 스냅샷은 상태의 지름길이지 독립 원장이 아니다
전체 동기화(full sync)는 과거 블록을 내려받아 상태 전환을 차례로 실행하며 현재 상태를 만듭니다.
- checksum과 AppHash는 답하는 질문이 다르다
SHA-256 체크섬은 내려받은 압축 파일이 게시자가 내놓은 바이트와 같은지 확인합니다.
- trusted height와 hash를 독립 출처에서 구한다
CometBFT 라이트 클라이언트 문서는 반쯤 신뢰하는 높이와 해시를 여러 전체 노드에 물어 비교하는 방법을 제시합니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
checksum과 AppHash는 답하는 질문이 다르다
SHA-256 체크섬은 내려받은 압축 파일이 게시자가 내놓은 바이트와 같은지 확인합니다. 게시 사이트와 체크섬 파일이 함께 뚫리면 둘 다 일치할 수 있습니다. 서명이 있다면 서명 키와 배포 절차도 검증합니다. 체크섬 혼자서는 상태가 합의상 유효하다는 것을 증명하지 못합니다.
CometBFT 상태 동기화 규격에 따르면 스냅샷 메타데이터에는 높이, 형식, 조각, 해시가 들어 있고, 스냅샷 높이의 라이트 블록으로 AppHash를 검증합니다. 노드는 합의 매개변수와 헤더를 써서 상태를 구성합니다. 스냅샷 해시와 블록 헤더의 AppHash를 같은 값으로 오해하지 않습니다.
| 값 | 확인 대상 | 한계 |
|---|---|---|
| 압축 파일 체크섬 | 다운로드 바이트 | 정본 상태는 증명 못 함 |
| 서명 | 게시자 키 | 게시자 신뢰 필요 |
| 신뢰 블록 해시 | 합의 헤더 | 출처 독립성 필요 |
| AppHash | 애플리케이션 상태 루트 | 높이 정확성 필요 |
| 조각 해시 | 전송 조각 | 전체 실행 이력은 재현 못 함 |
trusted height와 hash를 독립 출처에서 구한다
CometBFT 라이트 클라이언트 문서는 반쯤 신뢰하는 높이와 해시를 여러 전체 노드에 물어 비교하는 방법을 제시합니다. 스냅샷 제공자와 같은 운영 주체의 RPC 하나만 쓰면 함께 오염된 경우를 잡기 어렵습니다. 서로 다른 검증자·제공자의 커밋 해시가 같은지 확인하고 체인 ID와 높이를 함께 기록합니다.
신뢰 높이가 너무 오래되면 신뢰 기간과 검증자 집합 변화 때문에 라이트 검증이 실패할 수 있습니다. 반대로 너무 최신 값을 검증 없이 베껴 오면 공격자가 내민 포크를 기준으로 삼을 수 있습니다. 체인 운영 문서가 제시하는 범위와 현재 검증자 정보를 따르고, 공지에 적힌 숫자를 시간이 지난 뒤 그대로 다시 쓰지 않습니다.
snapshot 출처와 생성 환경을 평가한다
공지에는 스냅샷을 만든 노드의 클라이언트·애플리케이션 버전, 가지치기(pruning) 설정, 체인 ID, 높이와 블록 시각, 압축 파일 크기·형식, 체크섬과 서명이 적혀 있어야 합니다. 스냅샷이 업그레이드 전후 어느 실행 파일에서 만들어졌는지도 중요합니다. 애플리케이션 데이터베이스 구조가 맞지 않으면 복원은 성공한 듯 보여도 시작할 때 비정상 종료나 잘못된 이전 작업이 일어날 수 있습니다.
제3자 미러는 원본 주소와 체크섬을 함께 옮겨 실어야 합니다. 자체 체크섬만 새로 내놓으면 출처의 계보가 흐려집니다. HTTPS만으로는 파일 내용이 합의된 것임을 증명하지 못합니다. 임시 디렉터리에 내려받아 검증하고, 기존 데이터 디렉터리를 덮어쓰기 전에 따로 되돌릴 수 있는 상태를 만들어 둡니다.
- 체인 ID·클라이언트·앱 버전을 확인합니다
- 높이·형식·조각 수를 기록합니다
- 압축 파일 체크섬과 서명을 검증합니다
- 신뢰 해시를 독립된 전체 노드에서 교차 확인합니다
- AppHash와 복원 뒤 조회 표본을 비교합니다
복원 성공과 합의 참여 가능을 나눈다
압축이 풀리고 프로세스가 시작됐다고 해서 끝난 것은 아닙니다. 노드 로그에서 스냅샷 제안·조각 적용·AppHash 검증, 합의 연결 절차와 이후 블록 동기화를 확인합니다. 최신 높이와 블록 해시가 독립된 노드를 따라가는지, 피어 수가 안정적인지도 봅니다.
검증자라면 먼저 센트리 노드나 서명하지 않는 노드에서 검증합니다. 잘못된 상태나 실행 파일로 서명기를 켜면 블록 누락뿐 아니라 이중 서명 위험까지 관리해야 합니다. 검증자 키는 스냅샷 압축 파일이나 테스트용 데이터 디렉터리에 복사하지 않고, 원격 서명기 연결도 체인 ID를 확인한 뒤에 엽니다.
빠른 동기화가 과거 조회를 제공하는 것은 아니다
최근 상태를 복원한 노드는 현재 잔액 조회와 새 블록 검증은 할 수 있어도, 오래된 거래·영수증·과거 시점 상태 조회를 모두 갖고 있지 않을 수 있습니다. 가지치기 설정과 기록 보존 범위를 따로 확인합니다. 아카이브 RPC가 필요한 인덱서를 상태 동기화 노드에 붙이면 과거 데이터가 없다는 오류가 날 수 있습니다.
Ethereum의 부분 기록 만료(partial history expiry) 설명도 현재 상태 유지와 과거 특정 시점 조회를 구분합니다. 헤더로 체인을 검증하는 일과 모든 과거 블록 본문을 로컬 디스크에 보관하는 일은 서로 다른 요구입니다. 운영 공지는 노드 용도를 검증자, 공개 RPC, 인덱서, 아카이브로 나눠 적습니다.
갱신 공지는 오래된 신뢰값을 폐기한다
스냅샷은 새로 만들 때마다 높이·체크섬·신뢰 기준값이 바뀝니다. 게시 페이지는 생성 시각과 만료 또는 교체 상태를 보여 주고, 이전 파일은 보관 처리했다고 분명히 밝힙니다. 손상된 파일이 발견되면 주소만 바꾸지 말고 체크섬이 바뀐 이유와 영향을 받는 이용자를 공지합니다.
운영자는 사용한 스냅샷 주소, 체크섬, 신뢰 높이와 해시, 복원을 마친 높이를 변경 기록에 남깁니다. 문제가 생겼을 때 어느 상태에서 시작했는지 재현할 수 있어야 합니다. 빨리 복구하겠다는 목표가 검증 근거를 지우는 이유가 되어서는 안 됩니다.
자주 묻는 질문
checksum이 일치하면 snapshot은 안전한가요?
파일 무결성은 확인됩니다. 하지만 정본 상태인지는 신뢰할 헤더와 AppHash로 따로 검증해야 합니다.
state sync node도 모든 과거 거래를 조회할 수 있나요?
보장되지 않습니다. 가지치기 설정과 기록 보존 범위에 따라 아카이브 조회를 제공하지 못할 수 있습니다.
validator key를 복원 node에 바로 넣어도 되나요?
먼저 서명하지 않는 상태에서 체인 ID·상태·실행 파일과 동기화를 검증한 뒤 서명기 연결 절차를 따릅니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
