이더리움 JSON-RPC latest·safe·finalized 태그 차이

latest는 RPC 노드가 보는 현재 정식 체인의 최신 블록이어서 가장 빠르지만 이후 재구성될 수 있습니다. safe는 합의 관점에서 정식 체인에서 빠질 가능성이 낮은 head, finalized는 합의가 확정한 checkpoint에 포함된 상태를 가리킵니다. pending은 노드가 아직 블록에 포함되지 않은 거래를 반영해 구성한 로컬 상태라 제공자마다 다를 수 있습니다. 한 업무에서 balance, storage, logs를 여러 번 읽을 때 태그를 반복 사용하면 호출 사이 head가 움직일 수 있으므로 첫 응답의 block hash를 얻어 EIP-1898 방식으로 후속 조회를 고정하는 편이 일관됩니다.

태그는 같은 높이 선택지가 아니라 다른 신뢰 단계입니다

eth_getBalance, eth_getCode, eth_call 같은 default block 메서드는 블록 번호 또는 태그를 받습니다. latest는 노드가 현재 canonical head로 보는 블록을 가리키며 응답이 빠른 대신 짧은 재구성으로 hash가 바뀔 수 있습니다. 따라서 latest에서 읽은 값은 ‘현재 관측’이지 영구 확정 사실이라는 뜻이 아닙니다.

safe와 finalized는 consensus client가 execution client에 전달하는 합의 정보를 반영합니다. safe는 일반적인 조건에서 canonical chain에서 제외될 가능성이 매우 낮은 블록이고 finalized는 확정 checkpoint에 포함된 블록입니다. **세 태그의 차이는 단순한 블록 수 차이가 아닙니다**. 노드 동기화 상태와 합의 판정이 의미를 결정합니다.

RPC 태그는 속도 버튼이 아니라, 응답을 어떤 합의 시점의 사실로 사용할지 밝히는 데이터 계약입니다.

JOBCOIN 해설

VISUAL GUIDE프로토콜 실행의 기본 구조

1. 01
   태그는 같은 높이 선택지가 아니라 다른 신뢰 단계입니다

   eth_getBalance, eth_getCode, eth_call 같은 default block 메서드는 블록 번호 또는 태그를 받습니다.

2. 02
   업무 위험에 맞춰 읽기 기준을 선택합니다

   토큰 가격 미리보기나 지갑 잔액 새로고침은 latest를 사용하고 재구성 시 갱신해도 됩니다.

3. 03
   pending은 미래 블록을 보장하지 않습니다

   pending 상태는 노드가 아는 mempool transaction을 순서대로 적용해 만든 후보일 수 있습니다.

AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.

업무 위험에 맞춰 읽기 기준을 선택합니다

토큰 가격 미리보기나 지갑 잔액 새로고침은 latest를 사용하고 재구성 시 갱신해도 됩니다. 주문 체결 알림은 latest로 먼저 표시하되 provisional 라벨을 붙인 뒤 safe에서 승격할 수 있습니다. 대규모 출금·정산·회계 마감은 finalized 기준과 별도의 운영 정책을 결합합니다.

태그 지원과 지연은 RPC 제공자 및 연결된 client 구성에 따라 확인해야 합니다. safe 요청을 지원하지 않는 endpoint가 오류를 내거나 오래된 노드가 멈춘 값을 줄 수 있으므로 fallback을 조용히 latest로 바꾸지 않습니다. 응답 block number·hash와 head 지연을 기록하고 요구 신뢰 수준을 만족하지 못하면 업무를 보류합니다.

pending은 미래 블록을 보장하지 않습니다

pending 상태는 노드가 아는 mempool transaction을 순서대로 적용해 만든 후보일 수 있습니다. 각 노드는 서로 다른 pending pool, fee 정책, peer 전달 시점을 가지므로 두 RPC endpoint의 pending balance나 nonce가 다를 수 있습니다. pending eth_call 성공이 다음 블록 포함이나 동일 실행 결과를 보장하지 않습니다.

거래 발송기는 pending nonce를 참고할 수 있지만 로컬 예약 nonce와 이미 보낸 거래를 함께 관리해야 합니다. 읽기 결과에는 endpoint와 관측 시간을 남기고, 사용자에게 확정 잔액처럼 표시하지 않습니다. **pending을 네트워크 공통 상태로 해석하지 않습니다**.

• 화면 미리보기·알림·정산 등 읽기 목적을 분류합니다.
• 목적마다 latest·safe·finalized 허용 기준을 문서화합니다.
• 응답의 block number와 block hash를 함께 저장합니다.
• 여러 후속 호출은 같은 block hash로 고정합니다.
• 태그 미지원·동기화 지연을 명시적 오류로 처리합니다.
• 재구성 때 잠정 결과를 취소하는 절차를 시험합니다.

여러 호출은 첫 block hash에 고정합니다

대시보드가 latest로 balance를 읽고 300밀리초 뒤 latest로 storage를 읽는 사이 새 블록이 들어오면 두 값은 서로 다른 state root에서 나옵니다. 각각 올바른 응답이어도 합친 결과는 존재한 적 없는 스냅샷이 될 수 있습니다. 먼저 대상 블록을 가져와 hash를 확보하고 후속 default block 메서드를 그 hash에 고정합니다.

EIP-1898은 block number·tag 대신 blockHash 객체를 허용하고 requireCanonical 선택값을 정의합니다. block number만 고정하면 재구성 뒤 같은 높이가 다른 hash를 가리킬 수 있지만 hash는 특정 블록을 식별합니다. requireCanonical=true는 그 hash가 canonical chain에 없을 때 오류를 요구하므로 정식 체인 의존 업무에 유용합니다.

재구성과 데이터 보존 요구가 선택을 바꿉니다

과거 block hash를 지정해도 endpoint가 해당 state를 보존하지 않았다면 조회가 실패할 수 있습니다. EIP-1898은 block not found와 canonical 요구 불충족을 구분하도록 권고하지만 provider별 오류 code·메시지 차이는 통합 시험해야 합니다. archive 조회가 필요하면 서비스 계약과 실제 보존 범위를 확인합니다.

로그 인덱서는 latest에서 빠르게 수집한 뒤 safe·finalized 경계가 전진할 때 상태를 승격합니다. block hash가 canonical에서 이탈하면 기존 파생 상태를 되돌립니다. 조회 API와 이벤트 처리기가 같은 확정 단계 용어를 써야 UI와 내부 장부가 서로 다른 의미의 ‘완료’를 표시하지 않습니다.

노드 상태까지 포함해 검증합니다

두 endpoint에 같은 태그를 요청하고 block number·hash·timestamp를 비교합니다. finalized가 장시간 움직이지 않으면 네트워크 finality 문제로 단정하기 전에 consensus client 연결, execution sync와 provider 상태를 점검합니다. latest와 finalized 사이 간격도 절대 임계값보다 평소 분포와 업무 허용치를 기준으로 경보화합니다.

통합 테스트에서는 호출 사이 head를 진행시켜 태그 반복 조회의 불일치를 재현하고, hash 고정 뒤 모든 값이 같은 state root에 속하는지 확인합니다. safe 미지원 응답, unknown block hash, non-canonical hash, pruned state 오류도 각각 사용자와 재시도 정책에 연결합니다.

자주 묻는 질문