RPC 제공자 장애는 앱이 블록체인 노드에 질의하거나 거래를 전파하는 창구가 막힌 상태다. 잔액이 0으로 보이거나 전송이 pending이어도 체인 자체가 멈췄다고 단정할 수 없다. 서로 독립된 endpoint와 탐색기에서 chain ID, latest·safe·finalized block number와 hash, block timestamp를 비교하고, 같은 signed transaction의 hash가 다른 노드에 보이는지 확인해야 한다.
RPC는 체인이 아니라 체인을 보는 창구다
지갑과 DApp은 JSON-RPC로 노드에 잔액·코드·거래·블록을 묻고 signed transaction을 전파한다. ethereum.org 문서는 앱이 체인 데이터를 읽거나 거래를 보내려면 Ethereum node에 연결하며, 실행 client가 공통 JSON-RPC 규격을 구현한다고 설명한다. 한 provider의 HTTP 5xx나 timeout은 그 창구의 실패일 수 있다.
체인 중단은 다수 validator가 새 canonical block을 만들거나 finalize하지 못하는 합의 계층 문제다. RPC 장애는 새 블록이 계속 생성돼도 특정 앱만 stale data를 보여 줄 수 있다. provider 상태 페이지의 component 이름과 region, HTTP·WebSocket·archive 범위를 읽고 ‘Ethereum outage’ 같은 넓은 제목만 반복하지 않는다.
지갑 화면이 멈춘 것은 관측 창구의 이상 신호이지, 원장 전체가 멈췄다는 단독 증거가 아니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- RPC는 체인이 아니라 체인을 보는 창구다
지갑과 DApp은 JSON-RPC로 노드에 잔액·코드·거래·블록을 묻고 signed transaction을 전파한다.
- 높이뿐 아니라 같은 높이의 hash를 비교한다
두 endpoint에서 eth_blockNumber를 호출해 latest height를 비교한다.
- 잔액 0과 거래 누락은 block 기준을 먼저 본다
eth_getBalance는 어떤 block state를 질의했는지에 따라 결과가 달라진다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
높이뿐 아니라 같은 높이의 hash를 비교한다
두 endpoint에서 eth_blockNumber를 호출해 latest height를 비교한다. 숫자가 비슷해도 서로 다른 fork를 보고 있을 수 있으므로 eth_getBlockByNumber로 같은 높이의 block hash와 parent hash를 확인한다. block timestamp가 현재와 얼마나 차이나는지도 기록한다.
Ethereum JSON-RPC의 block parameter에는 latest, safe, finalized, pending이 있다. latest만 전진하고 finalized가 멈췄다면 단순 provider 지연과 다른 합의 이상을 의심할 수 있다. endpoint가 finalized tag를 지원하지 않거나 L2가 다른 finality 의미를 쓰면 해당 network 문서를 따른다.
| 관측 | 가능한 원인 | 추가 확인 |
|---|---|---|
| 한 endpoint만 timeout | provider·region 장애 | 독립 노드 응답 |
| 모든 endpoint 높이 정지 | 체인·공통 upstream 문제 | peer·consensus 상태 |
| 높이는 같고 hash 다름 | fork·stale cache | parent·finalized hash |
| 조회는 되고 send 실패 | 전파·rate limit | raw tx hash·nonce |
| HTTP 정상, 구독 끊김 | WebSocket 장애 | polling 결과 |
잔액 0과 거래 누락은 block 기준을 먼저 본다
eth_getBalance는 어떤 block state를 질의했는지에 따라 결과가 달라진다. provider가 뒤처졌거나 잘못된 network에 연결되면 오래된 잔액 또는 0을 표시할 수 있다. chain ID, address, block tag를 고정해 독립 노드에서 다시 읽고 explorer의 최신 block과 비교한다.
transaction hash가 한 provider에서 없다고 전체 network에 전파되지 않은 것은 아니다. 다른 endpoint에서 eth_getTransactionByHash와 receipt를 조회하고 발신 주소의 pending·latest nonce를 비교한다. 이미 전파된 raw transaction을 무작정 다시 만들면 같은 nonce의 경쟁 거래나 중복 의도가 생길 수 있다.
sync 상태와 provider 자체 상태를 함께 본다
EIP-2159는 client 공통 지표로 current canonical height에 대응하는 blockchain height와 eth_syncing의 highestBlock에 대응하는 best known block을 구분한다. current가 best known보다 뒤처지고 격차가 커지면 해당 node가 sync 중일 수 있다. peer count와 응답 latency도 보조 지표다.
Infura 같은 provider 상태 페이지는 network·API component별 상태와 incident history를 제공한다. 운영 공지를 인용할 때는 영향 region, 시작·복구 시각, read·write method 범위를 기록한다. 상태 페이지가 녹색으로 바뀐 사실은 누락된 transaction이 자동 복구됐다는 증거가 아니다.
- chain ID와 endpoint 운영 주체를 기록한다
- latest·safe·finalized 높이와 hash를 비교한다
- block timestamp와 local clock 차이를 본다
- transaction hash·nonce를 독립 노드에서 조회한다
- provider incident의 component·region·시간을 보존한다
대체 endpoint는 독립성이 있어야 한다
같은 provider의 다른 URL이나 같은 cloud region의 reseller는 공통 장애를 공유할 수 있다. 최소 하나는 다른 운영 주체·region·client 경로로 구성한다. 자체 node를 쓰더라도 execution과 consensus client가 모두 건강한지, upstream checkpoint나 beacon endpoint를 공유하지 않는지 확인한다.
자동 failover는 chain ID, genesis hash, 허용된 head lag, finalized hash 일치 조건을 통과한 endpoint만 선택해야 한다. 단순히 가장 먼저 HTTP 200을 보낸 endpoint로 바꾸면 잘못된 network나 stale node를 정상으로 취급할 수 있다. write 요청은 중복 전파를 허용하더라도 nonce와 tx hash로 멱등성을 관리한다.
복구 공지는 관측과 전파를 분리해 써야 한다
좋은 공지는 read query, transaction submission, WebSocket subscription, archive·trace method 중 무엇이 실패했는지 밝힌다. p95 latency와 error rate, 뒤처진 block 수, 영향 region을 제시하면 이용자가 자신의 증상과 맞출 수 있다. 체인이 정상 운영됐다는 결론은 독립 block production·finality 증거와 함께 쓴다.
복구 뒤에는 누락 구간의 block·receipt를 재수집하고 subscription gap을 backfill한다. 지갑은 pending transaction을 다시 조회하고 DApp은 cache와 indexer가 최신 head를 따라잡았는지 확인한다. RPC가 복구됐다는 시점과 화면 데이터가 완전히 회복된 시점은 다를 수 있다.
자주 묻는 질문
지갑 잔액이 0이면 자산이 사라진 건가요?
주소·chain ID·조회 block과 독립 endpoint를 먼저 확인한다. RPC 지연이나 잘못된 network 선택으로 0이 표시될 수 있다.
전송 버튼 오류 뒤 바로 다시 보내도 되나요?
먼저 원래 transaction hash와 발신 nonce가 다른 노드에 보이는지 확인해 경쟁 거래를 피한다.
탐색기 하나가 정상이라면 체인은 정상인가요?
단독 증거로는 부족하다. 탐색기도 provider·indexer에 의존하므로 독립 endpoint의 height·hash·finality를 교차한다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
