latest는 RPC 노드가 보는 현재 정식 체인의 최신 블록이라 가장 빠르지만, 나중에 재구성될 수 있습니다. safe는 합의 관점에서 정식 체인에서 빠질 가능성이 낮은 최신 블록을, finalized는 합의가 확정한 체크포인트에 포함된 상태를 가리킵니다. pending은 노드가 아직 블록에 들어가지 않은 거래까지 반영해 꾸린 로컬 상태라 제공자마다 다를 수 있습니다. 한 업무에서 잔액, 저장소, 로그를 여러 번 읽을 때 태그를 되풀이해 쓰면 호출 사이에 최신 블록이 움직일 수 있습니다. 그래서 첫 응답의 블록 해시를 받아 EIP-1898 방식으로 뒤따르는 조회를 고정하는 편이 일관됩니다.
태그는 같은 높이 선택지가 아니라 다른 신뢰 단계입니다
eth_getBalance, eth_getCode, eth_call처럼 기본 블록 인자를 받는 메서드는 블록 번호나 태그를 받습니다. latest는 노드가 지금 정식 체인(canonical chain)의 끝으로 보는 블록을 가리킵니다. 응답이 빠른 대신 짧은 재구성으로 해시가 바뀔 수 있습니다. 그래서 latest에서 읽은 값은 ‘현재 관측’일 뿐 영구히 확정된 사실이라는 뜻이 아닙니다.
safe와 finalized는 합의 클라이언트가 실행 클라이언트에 넘겨주는 합의 정보를 반영합니다. safe는 일반적인 조건에서 정식 체인에서 빠질 가능성이 매우 낮은 블록이고, finalized는 확정 체크포인트에 포함된 블록입니다. 세 태그의 차이는 단순한 블록 수 차이가 아닙니다. 그 의미는 노드 동기화 상태와 합의 판정이 정합니다.
RPC 태그는 속도 버튼이 아니라, 응답을 어떤 합의 시점의 사실로 사용할지 밝히는 데이터 계약입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 태그는 같은 높이 선택지가 아니라 다른 신뢰 단계입니다
eth_getBalance, eth_getCode, eth_call처럼 기본 블록 인자를 받는 메서드는 블록 번호나 태그를 받습니다.
- 업무 위험에 맞춰 읽기 기준을 선택합니다
토큰 가격 미리보기나 지갑 잔액 새로고침은 latest를 쓰고, 재구성이 일어나면 다시 갱신해도 됩니다.
- pending은 미래 블록을 보장하지 않습니다
pending 상태는 노드가 알고 있는 멤풀 거래를 차례로 적용해 만든 후보일 수 있습니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
업무 위험에 맞춰 읽기 기준을 선택합니다
토큰 가격 미리보기나 지갑 잔액 새로고침은 latest를 쓰고, 재구성이 일어나면 다시 갱신해도 됩니다. 주문 체결 알림은 latest로 먼저 띄우되 ‘잠정’ 표시를 붙였다가 safe에 이르면 확정으로 올릴 수 있습니다. 대규모 출금·정산·회계 마감은 finalized 기준에 별도 운영 정책을 더합니다.
태그 지원 여부와 지연은 RPC 제공자와 연결된 클라이언트 구성에 따라 확인해야 합니다. safe 요청을 지원하지 않는 엔드포인트가 오류를 내거나, 오래된 노드가 멈춘 값을 줄 수 있습니다. 이럴 때 대체 경로를 조용히 latest로 바꾸지 않습니다. 응답의 블록 번호·해시와 최신 블록 대비 지연을 기록하고, 요구하는 신뢰 수준에 못 미치면 업무를 보류합니다.
| 태그 | 관측 대상 | 주요 위험 | 적합한 예 |
|---|---|---|---|
| latest | 현재 정식 체인의 끝 | 짧은 재구성 | 빠른 잔액 화면 |
| safe | 합의상 안전한 최신 블록 | 지원 여부·동기화 지연 | 주문 상태 확정 |
| finalized | 확정 체크포인트 이하 | 최신성 지연 | 정산·고위험 승인 |
| pending | 노드의 후보 상태 | 노드별 차이 | 전송 전 시뮬레이션 |
| earliest | 가장 이른 상태 | 과거 데이터 보존 여부 | 초기 상태 확인 |
pending은 미래 블록을 보장하지 않습니다
pending 상태는 노드가 알고 있는 멤풀 거래를 차례로 적용해 만든 후보일 수 있습니다. 노드마다 대기 거래 목록, 수수료 정책, 피어에게서 거래를 받은 시점이 다르므로 두 RPC 엔드포인트의 pending 잔액이나 논스가 서로 다를 수 있습니다. pending 기준 eth_call이 성공했다고 다음 블록에 들어가거나 같은 실행 결과가 나온다는 보장은 없습니다.
거래 발송기는 pending 논스를 참고할 수 있지만, 로컬에서 예약한 논스와 이미 보낸 거래를 함께 관리해야 합니다. 읽기 결과에는 엔드포인트와 관측 시각을 남기고, 사용자에게 확정 잔액처럼 보여 주지 않습니다. pending을 네트워크 공통 상태로 해석하지 않습니다.
- 화면 미리보기·알림·정산 등 읽기 목적을 분류합니다.
- 목적마다 latest·safe·finalized 허용 기준을 문서로 정합니다.
- 응답의 블록 번호와 블록 해시를 함께 저장합니다.
- 뒤따르는 여러 호출은 같은 블록 해시로 고정합니다.
- 태그 미지원·동기화 지연은 명시적 오류로 처리합니다.
- 재구성 때 잠정 결과를 취소하는 절차를 시험합니다.
여러 호출은 첫 블록 해시에 고정합니다
대시보드가 latest로 잔액을 읽고 300밀리초 뒤 다시 latest로 저장소를 읽는 사이에 새 블록이 들어오면, 두 값은 서로 다른 상태 루트에서 나옵니다. 각각은 올바른 응답이어도 합친 결과는 한 번도 존재한 적 없는 스냅샷이 될 수 있습니다. 먼저 대상 블록을 가져와 해시를 확보하고 뒤따르는 기본 블록 메서드를 그 해시에 고정합니다.
EIP-1898은 블록 번호나 태그 대신 blockHash 객체를 받을 수 있게 하고 requireCanonical 선택값을 정의합니다. 블록 번호만 고정하면 재구성 뒤 같은 높이가 다른 해시를 가리킬 수 있지만, 해시는 특정 블록 하나를 식별합니다. requireCanonical=true는 그 해시가 정식 체인에 없을 때 오류를 내도록 요구하므로 정식 체인에 기대는 업무에 쓸모가 있습니다.
재구성과 데이터 보존 요구가 선택을 바꿉니다
과거 블록 해시를 지정해도 엔드포인트가 해당 상태를 보존하지 않았다면 조회가 실패할 수 있습니다. EIP-1898은 ‘블록을 찾을 수 없음’과 ‘정식 체인 요구 불충족’을 구분하라고 권고하지만, 제공자마다 다른 오류 코드와 메시지는 통합 시험으로 확인해야 합니다. 과거 상태 전체(archive) 조회가 필요하다면 서비스 계약과 실제 보존 범위를 확인합니다.
로그 인덱서는 latest에서 빠르게 모은 뒤 safe·finalized 경계가 앞으로 나아갈 때 상태를 확정 단계로 올립니다. 블록 해시가 정식 체인에서 벗어나면 그 블록에서 파생된 상태를 되돌립니다. 조회 API와 이벤트 처리기가 같은 확정 단계 용어를 써야 화면과 내부 장부가 서로 다른 의미의 ‘완료’를 보여 주지 않습니다.
노드 상태까지 포함해 검증합니다
두 엔드포인트에 같은 태그를 요청하고 블록 번호·해시·타임스탬프를 비교합니다. finalized가 오래 움직이지 않으면 네트워크 최종성 문제로 단정하기 전에 합의 클라이언트 연결, 실행 클라이언트 동기화, 제공자 상태를 점검합니다. latest와 finalized 사이 간격도 고정 임계값보다 평소 분포와 업무 허용치를 기준으로 경보를 겁니다.
통합 테스트에서는 호출 사이에 최신 블록을 진행시켜 태그 반복 조회의 불일치를 재현하고, 해시를 고정한 뒤 모든 값이 같은 상태 루트에 속하는지 확인합니다. safe 미지원 응답, 알 수 없는 블록 해시, 정식 체인 밖의 해시, 정리돼 사라진 상태 오류도 각각 사용자 안내와 재시도 정책에 연결합니다.
자주 묻는 질문
latest는 가장 최근에 최종 확정된 블록인가요?
아닙니다. latest는 노드가 보는 현재 정식 체인의 끝이며, 나중에 짧은 재구성으로 바뀔 수 있습니다.
safe와 finalized 중 무엇이 더 최신인가요?
보통 safe가 finalized보다 앞서지만, 정확한 간격은 합의 진행과 노드 상태에 따라 달라집니다.
블록 번호를 고정하면 일관된 조회가 되나요?
호출 중에 재구성이 일어나면 같은 번호가 다른 해시를 가리킬 수 있습니다. 특정 블록 해시로 고정하는 편이 더 분명합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
