RPC 제공자 장애는 앱이 블록체인 노드에 질의하거나 거래를 전파하는 창구가 막힌 상태입니다. 잔액이 0으로 보이거나 전송이 대기 중으로 멈춰 있어도 체인 자체가 멈췄다고 단정할 수는 없습니다. 서로 독립된 접속 지점(endpoint)과 탐색기에서 체인 ID, latest·safe·finalized 블록 번호와 해시, 블록 시각을 비교하고, 서명을 마친 같은 거래의 해시가 다른 노드에도 보이는지 확인해야 합니다.
RPC는 체인이 아니라 체인을 들여다보는 창구입니다
지갑과 탈중앙 앱(DApp)은 JSON-RPC로 노드에 잔액·코드·거래·블록을 묻고, 서명한 거래를 전파합니다. ethereum.org 문서는 앱이 체인 데이터를 읽거나 거래를 보내려면 이더리움 노드에 연결해야 하며, 실행 클라이언트들이 공통 JSON-RPC 규격을 구현한다고 설명합니다. 제공자 한 곳에서 난 HTTP 5xx 오류나 시간 초과는 그 창구만의 실패일 수 있습니다.
체인 중단은 다수 검증자가 새 정식 블록을 만들지 못하거나 확정하지 못하는 합의 계층의 문제입니다. RPC 장애는 새 블록이 계속 생기는 동안에도 특정 앱만 낡은 데이터를 보여 줄 수 있습니다. 제공자 상태 페이지에서는 구성 요소 이름과 지역, HTTP·웹소켓·아카이브 범위를 읽어야 하며, ‘Ethereum outage’ 같은 넓은 제목만 되풀이하지 않습니다.
지갑 화면이 멈춘 것은 관측 창구에 이상이 생겼다는 신호일 뿐, 원장 전체가 멈췄다는 단독 증거가 아닙니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- RPC는 체인이 아니라 체인을 들여다보는 창구입니다
지갑과 탈중앙 앱(DApp)은 JSON-RPC로 노드에 잔액·코드·거래·블록을 묻고, 서명한 거래를 전파합니다.
- 높이만이 아니라 같은 높이의 해시를 비교합니다
두 접속 지점에서 eth_blockNumber를 호출해 최신 높이를 비교합니다.
- 잔액 0과 거래 누락은 어느 블록 기준인지부터 봅니다
eth_getBalance는 어떤 블록 상태를 물었느냐에 따라 결과가 달라집니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
높이만이 아니라 같은 높이의 해시를 비교합니다
두 접속 지점에서 eth_blockNumber를 호출해 최신 높이를 비교합니다. 숫자가 비슷해도 서로 다른 갈래를 보고 있을 수 있으니 eth_getBlockByNumber로 같은 높이의 블록 해시와 부모 해시를 확인합니다. 블록 시각이 현재와 얼마나 벌어졌는지도 기록해 둡니다.
이더리움 JSON-RPC의 블록 매개변수에는 latest, safe, finalized, pending이 있습니다. latest만 앞으로 나가고 finalized가 멈춰 있다면 단순한 제공자 지연이 아니라 합의 쪽 이상을 의심해 볼 수 있습니다. 접속 지점이 finalized 태그를 지원하지 않거나 레이어 2 네트워크가 최종성을 다르게 정의한다면 그 네트워크의 문서를 따릅니다.
| 관측 | 가능한 원인 | 추가 확인 |
|---|---|---|
| 접속 지점 한 곳만 시간 초과 | 제공자·지역 장애 | 독립 노드 응답 |
| 모든 접속 지점의 높이 정지 | 체인 또는 공통 상위 서버 문제 | 피어·합의 상태 |
| 높이는 같은데 해시가 다름 | 갈래 분기·낡은 캐시 | 부모·확정 블록 해시 |
| 조회는 되는데 전송 실패 | 전파 문제·요청 한도 | 원본 거래 해시·논스 |
| HTTP는 정상, 구독만 끊김 | 웹소켓 장애 | 주기 조회 결과 |
잔액 0과 거래 누락은 어느 블록 기준인지부터 봅니다
eth_getBalance는 어떤 블록 상태를 물었느냐에 따라 결과가 달라집니다. 제공자가 뒤처졌거나 엉뚱한 네트워크에 연결돼 있으면 오래된 잔액이나 0을 보여 줄 수 있습니다. 체인 ID, 주소, 블록 태그를 고정해 독립 노드에서 다시 읽고 탐색기의 최신 블록과 비교합니다.
한 제공자에서 거래 해시가 보이지 않는다고 해서 네트워크 전체에 전파되지 않았다는 뜻은 아닙니다. 다른 접속 지점에서 eth_getTransactionByHash와 영수증을 조회하고, 보낸 주소의 pending·latest 논스를 비교합니다. 이미 전파된 원본 거래를 무작정 새로 만들면 같은 논스를 두고 경쟁하는 거래나 의도치 않은 중복이 생길 수 있습니다.
동기화 상태와 제공자 자체 상태를 함께 봅니다
EIP-2159는 클라이언트 공통 지표로, 현재 정식 높이에 해당하는 블록체인 높이와 eth_syncing의 highestBlock에 해당하는 알려진 최고 블록을 구분합니다. 현재 높이가 알려진 최고 블록보다 뒤처지고 그 격차가 벌어진다면 해당 노드는 동기화 중일 수 있습니다. 피어 수와 응답 지연도 보조 지표가 됩니다.
Infura 같은 제공자의 상태 페이지는 네트워크·API 구성 요소별 상태와 장애 이력을 보여 줍니다. 운영 공지를 인용할 때는 영향받은 지역, 시작·복구 시각, 읽기·쓰기 메서드 범위를 적어 둡니다. 상태 페이지가 초록색으로 바뀌었다고 누락된 거래까지 저절로 복구됐다는 증거가 되지는 않습니다.
- 체인 ID와 접속 지점 운영 주체를 기록합니다
- latest·safe·finalized 높이와 해시를 비교합니다
- 블록 시각과 로컬 시계의 차이를 확인합니다
- 거래 해시와 논스를 독립 노드에서 조회합니다
- 제공자 장애의 구성 요소·지역·시간을 보존합니다
대체 접속 지점은 독립적이어야 합니다
같은 제공자의 다른 주소나 같은 클라우드 지역을 쓰는 재판매 업체는 공통 장애를 함께 겪을 수 있습니다. 적어도 하나는 운영 주체와 지역, 클라이언트 경로가 다른 곳으로 꾸립니다. 자체 노드를 쓰더라도 실행 클라이언트와 합의 클라이언트가 모두 건강한지, 상위 체크포인트나 비콘 접속 지점을 남과 공유하지 않는지 확인합니다.
자동 전환(failover)은 체인 ID, 제네시스 해시, 허용 가능한 최신 블록 지연, 확정 블록 해시 일치 조건을 통과한 접속 지점만 골라야 합니다. 가장 먼저 HTTP 200을 돌려준 곳으로 무작정 바꾸면 엉뚱한 네트워크나 낡은 노드를 정상으로 착각할 수 있습니다. 쓰기 요청은 중복 전파를 허용하더라도 논스와 거래 해시로 멱등성을 관리합니다.
복구 공지는 관측과 전파를 나눠 써야 합니다
좋은 공지는 읽기 조회, 거래 제출, 웹소켓 구독, 아카이브·추적 메서드 가운데 무엇이 실패했는지 밝힙니다. p95 지연 시간과 오류율, 뒤처진 블록 수, 영향 지역을 보여 주면 이용자가 자기 증상과 맞춰 볼 수 있습니다. 체인이 정상 운영됐다는 결론은 독립적인 블록 생성·최종성 증거와 함께 적습니다.
복구 뒤에는 누락 구간의 블록과 영수증을 다시 모으고 구독 공백을 메웁니다. 지갑은 대기 중인 거래를 다시 조회하고, 탈중앙 앱은 캐시와 인덱서가 최신 블록을 따라잡았는지 확인합니다. RPC가 복구된 시점과 화면 데이터가 완전히 돌아온 시점은 다를 수 있습니다.
자주 묻는 질문
지갑 잔액이 0이면 자산이 사라진 건가요?
주소와 체인 ID, 조회한 블록, 독립 접속 지점부터 확인하세요. RPC 지연이나 네트워크를 잘못 고른 탓에 0이 표시될 수 있습니다.
전송 버튼 오류 뒤 바로 다시 보내도 되나요?
먼저 원래 거래 해시와 보낸 주소의 논스가 다른 노드에 보이는지 확인해 경쟁 거래가 생기지 않게 하세요.
탐색기 하나가 정상이라면 체인은 정상인가요?
그것만으로는 부족합니다. 탐색기도 제공자와 인덱서에 기대므로 독립 접속 지점의 높이·해시·최종성을 서로 맞춰 봐야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
