탐색기는 노드 데이터를 색인해 보여 주는 별도 서비스라 화면 중단이 합의 중단을 곧 뜻하지 않는다. 한 탐색기 5xx나 갱신 지연만으로 블록 생성이 멈췄다고 보도하면 근거가 부족하다. 따라서 독립 RPC의 head·finalized 높이, 동료 수와 여러 탐색기를 교차 확인한다.
탐색기는 노드 위에 놓인 별도 색인 서비스
블록 탐색기는 하나 이상의 노드에서 block·transaction 데이터를 읽어 데이터베이스에 색인하고 API와 웹 화면으로 제공한다. 프런트엔드, API gateway, 인덱서, 연결 노드 중 한 계층만 고장나도 사용자는 ‘블록이 멈춘’ 화면을 볼 수 있다.
합의 네트워크의 블록 생산은 탐색기와 독립적이다. 탐색기 last height가 고정됐다는 관측만으로 validator·miner가 새 블록을 만들지 못했다고 결론 내리지 않는다.
탐색기는 체인을 보여 주는 색인 서비스다. 탐색기 화면의 마지막 블록이 체인의 마지막 블록이라는 등식은 성립하지 않는다.
JOBCOIN 해설
화면 오류와 체인 정지를 가르는 교차검증
먼저 탐색기 API도 같은 높이에서 멈췄는지 확인한다. 이어 서로 다른 운영자의 독립 RPC에서 head height와 block hash를 조회한다. RPC head가 계속 증가하면 화면·인덱서 문제의 증거가 강해진다.
공용 RPC 한 곳이 timeout이라고 체인 중단은 아니다. 그 노드가 동기화 중이거나 rate limit·네트워크 장애일 수 있다. 최소 두 운영자의 응답과 공식 client 또는 status 공지를 함께 본다.
탐색기 900,000과 RPC 900,012의 예시
교육용 가정에서 탐색기 화면이 높이 900,000에서 15분째 멈췄지만 독립 RPC A가 900,012, RPC B가 900,013을 반환하고 각 높이의 parent hash가 이어진다면 탐색기 인덱싱 지연 가능성이 크다. RPC 두 곳의 1블록 차이는 요청시각 차이일 수 있다.
반대로 여러 독립 노드의 head가 같은 높이에서 멈추고 peer·sync 또는 합의 상태에도 이상이 보인다면 체인 수준 사건을 조사한다. 한 공용 RPC가 탐색기와 같은 사업자의 backend일 수 있으므로 도메인만 다른 두 URL을 독립 근거로 세지 않는다.
| 계층 | 보이는 증상 | 체인 상태와의 관계 |
|---|---|---|
| 프런트엔드 | 페이지 5xx·스크립트 오류 | 노드와 인덱서는 정상일 수 있음 |
| 탐색기 API | 검색·주소 endpoint 오류 | 새 블록 수집은 계속될 수 있음 |
| 인덱서 | 마지막 블록·잔액 갱신 지연 | 체인은 전진하지만 표시가 뒤처짐 |
| 노드·합의 | 독립 RPC head도 정지 | 체인 사건 가능성, 추가 교차검증 필요 |
Bitcoin RPC에서 확인할 네 필드
Bitcoin getblockchaininfo의 blocks는 해당 노드가 완전히 검증한 most-work chain 높이, headers는 검증한 헤더 수, bestblockhash는 현재 best block hash다. blocks가 headers보다 뒤처지고 initialblockdownload가 true라면 그 노드 자체가 동기화 중일 수 있어 네트워크 head 근거로 쓰기 어렵다.
두 노드의 높이가 같아도 bestblockhash가 다르면 일시적 fork, 재조직 또는 잘못된 네트워크 연결을 확인한다. chain 필드가 main인지 test인지 먼저 맞추며, 최신 한 블록은 후속 블록에 의해 바뀔 수 있어 ‘확정’이라는 표현을 자제한다.
- 탐색기의 마지막 block height·hash·표시시각을 저장한다
- 서로 다른 운영자의 RPC 최소 두 곳을 비교한다
- Bitcoin은 chain·blocks·headers·bestblockhash·IBD를 확인한다
- Ethereum은 eth_blockNumber·eth_syncing과 최근 block hash를 확인한다
- 거래소 입출금 상태는 체인 상태와 별도 공지로 확인한다
Ethereum에서는 head와 동기화를 함께 본다
ethereum.org JSON-RPC 문서는 eth_blockNumber가 현재 head를 추적하는 gossip 계열 method이고 eth_getBlockByNumber로 해당 block을 조회할 수 있음을 설명한다. eth_syncing이 객체를 반환하는 노드는 따라잡는 중이므로 그 currentBlock을 네트워크 전체 head로 오해하지 않는다.
탐색기에서 transaction not found가 떠도 RPC receipt가 아직 없으면 미포함·드롭·잘못된 hash일 수 있고, receipt가 있는데 탐색기만 못 찾으면 색인 지연 가능성이 높다. pending transaction과 confirmed block 색인을 같은 장애로 묶지 않는다.
장애 판정 타임라인을 남기는 법
UTC 시각마다 explorer HTTP 상태, explorer last height/hash, RPC별 head/hash/sync 상태를 한 행에 기록한다. 30초 간격으로 세 번 측정했다면 각 endpoint의 증가량을 비교한다. 한 번의 timeout은 전면 중단이 아니라 관측 실패로 둔다.
상태 페이지가 explorer indexing delay만 언급했다면 합의 중단이나 자금 손실로 확대하지 않는다. 반대로 공식 체인 status와 client 팀이 합의 문제를 공지했다면 탐색기 복구만으로 사건 종료를 판단하지 않는다.
이 검증은 읽기 전용 상태 관찰이다. 개인 RPC 자격증명이나 지갑 서명을 요구하지 않으며 거래를 재전송하지 않는다. 화면 복구, RPC 200, head 증가가 각각 증명하는 범위를 구분한다.
자주 묻는 질문
탐색기에서 transaction not found면 송금이 사라진 건가요?
아니다. 잘못된 hash, 미전파·미포함, 재조직 또는 인덱싱 지연 가능성이 있다. 독립 RPC에서 transaction과 receipt를 확인한다.
HTTP 200이면 탐색기가 정상인가요?
페이지 응답 성공만 뜻한다. last block이 전진하는지, API 데이터가 최신인지와 검색 기능이 작동하는지는 별도 확인이 필요하다.
RPC 두 곳의 높이가 1 차이나면 체인 분기인가요?
요청시각과 전파 지연으로 한 블록 차이가 날 수 있다. 같은 높이의 hash와 parent 연결, 후속 수렴 여부를 확인한다.
