상태 스냅샷 공지, 빠른 노드 동기화의 신뢰 경계 확인하기

상태 스냅샷은 특정 block height의 application state를 묶어 새 node가 genesis부터 모든 transaction을 재실행하지 않고 빠르게 시작하도록 돕는다. 다운로드 파일 checksum만 맞는다고 canonical state가 증명되는 것은 아니다. chain ID, snapshot height·format·chunk, 독립 출처의 trusted height와 block hash, header가 약속한 AppHash를 확인하고 node가 이후 block을 정상 검증하며 따라가는지 점검해야 한다.

스냅샷은 상태의 지름길이지 독립 원장이 아니다

full sync는 과거 block을 내려받고 application transition을 순서대로 실행해 current state를 만든다. state sync는 최근 height의 snapshot을 받아 state를 복원하고 그 지점 이후 block을 검증한다. 시작 시간이 줄지만 어디서 trusted header를 얻는지와 snapshot을 어떤 root에 맞춰 검증하는지가 보안 경계가 된다.

Ethereum node 문서도 sync mode마다 genesis부터 재실행하거나 trusted checkpoint에서 current state로 접근하는 등 검증·저장 trade-off가 다르다고 설명한다. network와 client별 방식이 다르므로 ‘공식 snapshot’이라는 이름만으로 full verification과 같다고 쓰지 않는다.

파일이 온전하다는 증거와 그 파일이 canonical state라는 증거는 서로 다르다.

JOBCOIN 해설

VISUAL GUIDE뉴스·공시를 확인하는 세 가지 기준

1. 01
   스냅샷은 상태의 지름길이지 독립 원장이 아니다

   full sync는 과거 block을 내려받고 application transition을 순서대로 실행해 current state를 만든다.

2. 02
   checksum과 AppHash는 답하는 질문이 다르다

   SHA-256 checksum은 내려받은 archive가 게시자가 제시한 바이트와 같은지 확인한다.

3. 03
   trusted height와 hash를 독립 출처에서 구한다

   CometBFT light client 문서는 semi-trusted height와 hash를 여러 full node에 질의해 비교하는 방법을 제시한다.

AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.

checksum과 AppHash는 답하는 질문이 다르다

SHA-256 checksum은 내려받은 archive가 게시자가 제시한 바이트와 같은지 확인한다. 게시 사이트와 checksum 파일이 함께 침해되면 둘 다 일치할 수 있다. signature가 있다면 signer key와 배포 절차도 검증한다. checksum은 state의 consensus 유효성을 혼자 증명하지 않는다.

CometBFT state sync 규격은 snapshot metadata에 height, format, chunks, hash가 있고, snapshot height의 light block으로 AppHash를 검증한다고 설명한다. node는 consensus params와 header를 사용해 state를 구성한다. snapshot hash와 block header의 AppHash를 같은 값으로 오해하지 않는다.

trusted height와 hash를 독립 출처에서 구한다

CometBFT light client 문서는 semi-trusted height와 hash를 여러 full node에 질의해 비교하는 방법을 제시한다. snapshot 제공자와 같은 운영 주체의 RPC 하나만 쓰면 공통 오염을 잡기 어렵다. 서로 다른 validator·provider의 commit hash가 같은지 확인하고 chain ID와 height를 함께 기록한다.

trusted height가 너무 오래되면 trusting period와 validator set 변화 때문에 light verification이 실패할 수 있다. 너무 최신 값을 검증 없이 복사하면 공격자가 제시한 fork를 root로 삼을 수 있다. chain 운영 문서가 제시하는 범위와 현재 validator 정보를 따르고, 공지의 숫자를 시간 경과 뒤 그대로 재사용하지 않는다.

snapshot 출처와 생성 환경을 평가한다

공지에는 생성 node의 client·application version, pruning 설정, chain ID, height·block time, archive 크기·format, checksum과 signature를 적어야 한다. snapshot이 upgrade 전후 어느 binary에서 생성됐는지 중요하다. application database schema가 맞지 않으면 복원은 성공한 듯 보여도 시작 시 panic이나 잘못된 migration을 일으킬 수 있다.

제3자 mirror는 원본 URL과 checksum을 함께 복제하되 자체 checksum만 새로 제시해서는 출처 계보가 흐려진다. HTTPS만으로 파일 내용의 합의를 증명하지 않는다. 임시 디렉터리에 내려받아 검증하고 기존 data directory를 덮기 전 별도 복구 가능 상태를 만든다.

• chain ID·client·app version을 확인한다
• height·format·chunk 수를 기록한다
• archive checksum과 signature를 검증한다
• trusted hash를 독립 full node에서 교차한다
• AppHash와 복원 뒤 query 표본을 비교한다

복원 성공과 합의 참여 가능을 나눈다

archive 압축이 풀리고 process가 시작됐다는 사실은 완료가 아니다. node log에서 snapshot offer·chunk 적용·AppHash 검증, consensus handshake와 이후 block sync를 확인한다. latest height와 block hash가 독립 node를 따라가고 peer 수가 안정적인지 본다.

validator라면 먼저 sentry나 non-signing node에서 검증한다. 잘못된 state·binary로 signer를 켜면 missed block뿐 아니라 이중 서명 위험 관리가 필요하다. validator key를 snapshot archive나 테스트 data directory에 복사하지 않고 remote signer 연결도 chain ID를 확인한 뒤 연다.

빠른 동기화가 과거 조회를 제공하는 것은 아니다

recent state를 복원한 node는 current balance와 새 block 검증은 가능해도 오래된 transaction·receipt·historical state query를 모두 보유하지 않을 수 있다. pruning과 history 보존 범위를 별도로 확인한다. archive RPC가 필요한 indexer를 state-sync node에 붙이면 과거 data missing 오류가 생길 수 있다.

Ethereum의 partial history expiry 설명도 current state 유지와 과거 특정 시점 조회 가능성을 구분한다. header로 chain을 검증하는 것과 모든 historical body를 local disk에 보관하는 것은 다른 요구다. 운영 공지는 node 용도를 validator, public RPC, indexer, archive로 나눠 적는다.

갱신 공지는 오래된 신뢰값을 폐기한다

snapshot은 새로 생성될 때마다 height·checksum·trusted reference가 바뀐다. 게시 페이지는 생성 시각과 만료 또는 교체 상태를 보여 주고 이전 파일을 명확히 archive 처리한다. 손상된 파일이 발견되면 URL만 교체하지 말고 checksum 변경 이유와 영향 이용자를 공지한다.

운영자는 사용한 snapshot URL, checksum, trusted height·hash, 복원 완료 height를 변경 기록에 남긴다. 문제가 생겼을 때 어느 state에서 시작했는지 재현할 수 있어야 한다. 빠른 복구 목표가 검증 근거 삭제의 이유가 되어서는 안 된다.

자주 묻는 질문