탐색기는 노드 데이터를 색인해 보여 주는 별도 서비스라서, 화면이 멈췄다고 합의가 멈췄다는 뜻은 아닙니다. 탐색기 한 곳의 5xx 오류나 갱신 지연만 보고 블록 생성이 멈췄다고 보도하면 근거가 모자랍니다. 그러니 독립된 RPC에서 최신 높이와 확정 높이, 연결된 피어 수를 보고 여러 탐색기를 함께 대조해야 합니다.
탐색기는 노드 위에 얹힌 별도 색인 서비스입니다
블록 탐색기는 노드 하나 이상에서 블록과 거래 데이터를 읽어 데이터베이스에 색인하고, API와 웹 화면으로 보여 줍니다. 프런트엔드, API 관문, 인덱서, 연결된 노드 가운데 한 층만 고장 나도 사용자 눈에는 ‘블록이 멈춘’ 화면이 보일 수 있습니다.
합의 네트워크의 블록 생산은 탐색기와 따로 돌아갑니다. 탐색기의 마지막 높이가 그대로라는 사실 하나로 검증자나 채굴자가 새 블록을 못 만들었다고 결론짓지 마세요.
탐색기는 체인을 비춰 보여 주는 색인 서비스입니다. 탐색기 화면의 마지막 블록이 곧 체인의 마지막 블록이라는 등식은 성립하지 않습니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 탐색기는 노드 위에 얹힌 별도 색인 서비스입니다
블록 탐색기는 노드 하나 이상에서 블록과 거래 데이터를 읽어 데이터베이스에 색인하고, API와 웹 화면으로 보여 줍니다.
- 화면 오류인지 체인 정지인지 교차 확인으로 가려냅니다
먼저 탐색기 API도 같은 높이에서 멈춰 있는지 봅니다.
- 탐색기 900,000과 RPC 900,012로 보는 예시
이해를 돕기 위한 가정입니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
화면 오류인지 체인 정지인지 교차 확인으로 가려냅니다
먼저 탐색기 API도 같은 높이에서 멈춰 있는지 봅니다. 다음으로 운영자가 서로 다른 독립 RPC에서 최신 높이와 블록 해시를 조회합니다. RPC의 최신 높이가 계속 올라간다면 화면이나 인덱서 문제라는 쪽에 무게가 실립니다.
공용 RPC 한 곳이 응답 시간을 넘겼다고 체인이 멈춘 것은 아닙니다. 그 노드가 동기화 중이거나 요청 한도, 네트워크 장애에 걸렸을 수 있습니다. 적어도 두 운영자의 응답과 공식 클라이언트 팀이나 상태 공지를 함께 보세요.
탐색기 900,000과 RPC 900,012로 보는 예시
이해를 돕기 위한 가정입니다. 탐색기 화면은 높이 900,000에서 15분째 멈춰 있는데 독립 RPC A는 900,012, RPC B는 900,013을 돌려주고, 높이마다 부모 해시가 끊김 없이 이어진다면 탐색기 색인이 늦어졌을 가능성이 큽니다. 두 RPC 사이의 1블록 차이는 요청한 시각이 달라서일 수 있습니다.
반대로 여러 독립 노드의 최신 높이가 같은 자리에서 멈추고 피어·동기화나 합의 상태에도 이상이 보인다면 체인 차원의 사건으로 조사합니다. 공용 RPC 하나가 탐색기와 같은 회사의 백엔드일 수도 있으므로 도메인만 다른 두 주소를 독립 근거로 세지 않습니다.
| 계층 | 보이는 증상 | 체인 상태와의 관계 |
|---|---|---|
| 프런트엔드 | 페이지 5xx·스크립트 오류 | 노드와 인덱서는 정상일 수 있음 |
| 탐색기 API | 검색·주소 조회 오류 | 새 블록 수집은 계속될 수 있음 |
| 인덱서 | 마지막 블록·잔액 갱신 지연 | 체인은 나아가지만 표시가 뒤처짐 |
| 노드·합의 | 독립 RPC 최신 높이도 정지 | 체인 사건 가능성, 추가 교차 확인 필요 |
비트코인 RPC에서 확인할 네 가지 값
비트코인 getblockchaininfo 응답에서 blocks는 그 노드가 끝까지 검증한 작업량 최대 체인의 높이, headers는 검증한 헤더 수, bestblockhash는 현재 최선 블록의 해시입니다. blocks가 headers보다 뒤처지고 initialblockdownload가 true라면 그 노드 자체가 아직 동기화 중일 수 있어 네트워크 최신 높이의 근거로 쓰기 어렵습니다.
두 노드의 높이가 같아도 bestblockhash가 다르다면 일시적인 분기, 재조직, 엉뚱한 네트워크 연결을 의심해 봅니다. chain 값이 메인넷인지 테스트넷인지부터 맞추고, 가장 최근 블록 하나는 뒤이은 블록에 따라 바뀔 수 있으니 ‘확정’이라는 말은 아껴 쓰세요.
- 탐색기의 마지막 블록 높이·해시·표시 시각을 저장합니다
- 운영자가 다른 RPC를 적어도 두 곳 비교합니다
- 비트코인은 chain·blocks·headers·bestblockhash·초기 동기화 여부를 확인합니다
- 이더리움은 eth_blockNumber·eth_syncing과 최근 블록 해시를 확인합니다
- 거래소 입출금 상태는 체인 상태와 따로 공지로 확인합니다
이더리움에서는 최신 높이와 동기화를 함께 봅니다
ethereum.org의 JSON-RPC 문서는 eth_blockNumber가 현재 최신 블록을 따라가는 메서드이고, eth_getBlockByNumber로 그 블록을 조회할 수 있다고 설명합니다. eth_syncing이 객체를 돌려주는 노드는 아직 따라잡는 중이니, 그 currentBlock을 네트워크 전체의 최신 높이로 착각하지 마세요.
탐색기에 거래를 찾을 수 없음이 떴을 때 RPC에도 영수증이 없다면 아직 담기지 않았거나, 버려졌거나, 해시가 틀렸을 수 있습니다. 영수증은 있는데 탐색기만 못 찾는다면 색인 지연일 가능성이 높습니다. 대기 중인 거래와 확정된 블록의 색인 문제를 한 장애로 묶지 마세요.
장애 판정 타임라인을 남기는 법
세계표준시(UTC) 시각마다 탐색기 HTTP 상태, 탐색기 마지막 높이와 해시, RPC별 최신 높이·해시·동기화 상태를 한 줄에 적습니다. 30초 간격으로 세 번 쟀다면 주소마다 얼마나 늘었는지 비교합니다. 한 번의 응답 시간 초과는 전면 중단이 아니라 관측 실패로 남겨 둡니다.
상태 페이지가 탐색기 색인 지연만 언급했다면 합의 중단이나 자금 손실로 부풀리지 않습니다. 거꾸로 공식 체인 상태 페이지와 클라이언트 팀이 합의 문제를 알렸다면, 탐색기가 돌아왔다는 것만으로 사건이 끝났다고 판단하지 않습니다.
이 확인 작업은 상태를 읽기만 하는 관찰입니다. 개인 RPC 자격증명이나 지갑 서명을 요구하지 않고, 거래를 다시 보내지도 않습니다. 화면 복구, RPC 200 응답, 최신 높이 증가가 각각 어디까지를 증명하는지 나눠서 보세요.
자주 묻는 질문
탐색기에서 transaction not found면 송금이 사라진 건가요?
아닙니다. 해시가 틀렸거나, 아직 퍼지지 않았거나 블록에 담기지 않았거나, 재조직이나 색인 지연 때문일 수 있습니다. 독립 RPC에서 거래와 영수증을 확인하세요.
HTTP 200이면 탐색기가 정상인가요?
페이지가 응답했다는 뜻일 뿐입니다. 마지막 블록이 계속 올라가는지, API 데이터가 최신인지, 검색이 제대로 되는지는 따로 확인해야 합니다.
RPC 두 곳의 높이가 1 차이나면 체인 분기인가요?
요청 시각과 전파 지연 때문에 한 블록쯤은 차이가 날 수 있습니다. 같은 높이의 해시와 부모 연결, 이후 하나로 모이는지를 확인하세요.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
