이더리움 JSON-RPC 블록 태그: latest·safe·finalized·pending 차이

두 이더리움 앱이 같은 잔액을 조회했는데 잠시 다른 답을 보여 줄 수 있어요. 둘 중 하나가 반드시 고장 난 것은 아닙니다. 빠진 조건은 대개 블록 기준점이에요. 이더리움 블록체인 기초는 순서가 있는 기록을 만들지만, JSON-RPC 조회는 그 기록의 어느 시점 을 읽을지도 정해야 합니다.

블록 태그(Block Tag)는 이 선택을 짧은 이름으로 표현해요. latest, safe, finalized, pending, earliest는 최신성과 확신 사이에서 서로 다른 기준을 제공합니다. 특정 블록 번호나 해시를 쓰면 기준을 더 명확히 고정할 수 있어요.

이더리움 블록 태그는 무엇을 고르나요?

체인 상태를 여러 번 저장된 문서라고 생각해 보세요. latest는 내 노드가 현재 받아들인 가장 새 버전을 엽니다. safe는 교체되기 더 어려운 이전 버전을, finalized는 이더리움 합의가 정상 상황에서 가장 강하게 확정한 체크포인트를 열어요. pending은 아직 제출되지 않은 로컬 초안에 더 가깝습니다.

공식 이더리움 실행 API 명세는 다섯 가지 태그를 정의합니다.

노드는 요청 시점에 이 이름을 실제 블록으로 바꿉니다. 영구적인 블록 식별자가 아니에요. 다음 블록이 생기면 latest가 가리키는 곳도 바뀌며, 두 제공자의 체인 관점이 수렴하기 전에는 서로 다른 블록을 고를 수 있습니다.

pending에서 finalized까지 어떻게 이동하나요?

트랜잭션은 보통 서로 다른 확신 단계를 지나갑니다.

1. Pending: 한 노드가 거래를 알고 있으며 로컬 대기 상태에 포함할 수 있어요.
2. Latest: 거래가 담긴 제안 블록을 노드가 현재 정식 체인의 머리로 받아들입니다.
3. Safe: 합의 정보가 쌓여 명세의 가정 아래 교체 가능성이 더 낮아집니다.
4. Finalized: 지분증명 체크포인트가 이더리움의 가장 강한 정상 최종성 보장을 제공합니다.

이 흐름은 각 거래에 붙은 단순 타이머가 아닙니다. 태그는 클라이언트가 선택한 블록 상태를 가리켜요. 이더리움 공식 Gasper 문서에 따르면 전체 스테이킹 이더의 3분의 2에 해당하는 투표가 체크포인트를 정당화(Justify)하고, 다음 체크포인트 관계를 통해 이전 체크포인트가 최종화됩니다. 그 합의 원리는 블록체인 최종성 가이드에서 더 자세히 볼 수 있어요.

safe나 finalized를 “실행 성공”과 혼동하면 안 됩니다. 최종화된 블록에도 실패해 되돌려진 컨트랙트 호출이 들어갈 수 있어요. 최종성은 블록이 역사에서 얼마나 안정적인지를 말하고, 트랜잭션 영수증은 최상위 실행의 성공 여부를 기록합니다.

어떤 RPC 메서드가 블록 기준점을 쓰나요?

여러 상태 조회 메서드는 블록 번호나 태그를 받습니다. 이더리움 공식 JSON-RPC 문서는 eth_getBalance, eth_getStorageAt, eth_getTransactionCount, eth_getCode, eth_call과 여러 블록 조회 메서드에 이 매개변수를 설명해요.

블록을 바꾸면 질문 자체가 달라집니다.

{ "jsonrpc": "2.0", "method": "eth_getBalance", "params": ["0xYourAddress", "latest"], "id": 1 }

이 요청은 노드가 본 현재 체인 머리의 잔액을 묻습니다. latest를 finalized로 바꾸면 최종화된 상태의 잔액을 묻게 돼요. 기준점을 말하지 않고 둘 중 하나만 “진짜 잔액”이라고 부르기는 어렵습니다.

시뮬레이션도 마찬가지예요. pending 상태에서 실행한 eth_call은 한 노드의 로컬 대기 상태를 반영할 수 있지만, finalized는 의도적으로 더 오래된 상태를 사용합니다. 시뮬레이션이 성공해도 잔액, 논스(Nonce), 스토리지, 수수료, 순서, 컨트랙트 상태가 바뀌면 실제 포함과 실행 결과는 달라질 수 있어요.

태그, 블록 번호, 블록 해시 중 무엇을 쓸까요?

“가장 최신”, “더 안전”, “최종 확정”처럼 상대적인 요구에는 태그가 맞습니다. 특정 높이가 필요하고 정식 체인 변경을 별도로 처리할 수 있다면 블록 번호를 쓸 수 있어요. “현재 그 높이에 있는 어느 블록”이 아니라 정확한 블록의 정체성이 중요하면 블록 해시가 더 명확합니다.

EIP-1898은 여러 상태 메서드에서 블록 해시 객체를 쓰는 방식을 표준화했습니다. 해시와 함께 requireCanonical: true를 지정할 수도 있어요.

{
  "blockHash": "0x<64-hex-character-block-hash>",
  "requireCanonical": true
}

여러 조회가 하나의 일관된 상태 스냅샷을 설명해야 할 때 유용합니다. 먼저 블록 번호와 해시를 저장한 뒤, 지원되는 조회를 같은 해시에 고정하세요. 체인 재구성(Reorganization)으로 해당 블록이 정식 체인에서 빠졌다면 requireCanonical을 통해 비정식 블록 상태를 조용히 받아들이는 대신 오류를 요청할 수 있습니다.

증명 기반 조회에서는 블록 헤더도 신뢰 경계에 포함됩니다. eth_getProof 가이드는 계정·스토리지 증명이 선택한 블록의 상태 루트와 어떻게 연결되는지 설명해요.

상황별 선택 방법

모든 제품에 맞는 하나의 태그는 없습니다. 잘못된 답을 사용했을 때의 결과부터 생각해 보세요.

화면 표시와 영향이 작은 조회

반응이 빨라야 하는 대시보드, 지갑 미리 보기, 구속력 없는 추정에는 latest가 적절할 수 있어요. 다만 데이터가 잠정적임을 표시하고 체인 머리가 바뀌면 갱신해야 합니다. 빠른 화면을 결제 확정 주장으로 바꾸면 안 돼요.

결제·출금·되돌리기 어려운 작업

네트워크와 제공자가 지원한다면 safe 또는 finalized를 바탕으로 문서화된 확인 정책을 두세요. 결과가 클수록 “체인 머리에서 관찰됨”과 “앱 정책상 정산됨”을 구분해야 합니다. 이것은 위험 관리이며, 이더리움 위의 모든 레이어가 안전하다는 보장은 아니에요.

인덱서와 여러 호출의 스냅샷

연관된 조회를 하나의 블록 번호나, 지원된다면 EIP-1898 블록 해시에 고정합니다. 번호와 해시를 함께 저장하세요. 같은 높이의 정식 해시가 달라지면 파생 기록을 되돌리고 알려진 지점부터 다시 처리해야 합니다. 여러 체인 머리의 상태를 한 결과에 섞으면 안 돼요.

롤업과 다른 EVM 네트워크

모든 네트워크가 같은 단어에 동일한 의미를 부여한다고 가정하지 마세요. 롤업은 정산 레이어와의 관계에 따라 safe와 finalized를 제공할 수 있고, 클라이언트와 RPC 제공자별 지원도 다를 수 있습니다. L2의 구체적인 경계는 이더리움 롤업 트랜잭션 상태에서 확인할 수 있어요.

리스크와 흔한 실수

• latest를 최종 확정으로 보기: 최신 정식 체인 머리는 재구성될 수 있어 새 결과가 사라질 수 있습니다.
• pending을 모두가 공유하는 상태로 보기: 대기 상태는 노드의 로컬 멤풀과 정책으로 만들어요. 다른 제공자는 다른 거래를 볼 수 있습니다.
• 블록 기준점을 섞기: 움직이는 태그로 연속 조회하면 서로 다른 블록을 읽을 수 있어요. 일관성이 중요하면 스냅샷을 고정하세요.
• 메서드별 지원을 확인하지 않기: 표준에 선택자가 있어도 네트워크, 클라이언트, 제공자, 메서드별 기능은 다를 수 있습니다. 실제 엔드포인트를 시험하고 명시적 오류나 null을 처리하세요.
• 최종성과 앱 정확성을 혼동하기: 악성 승인, 실패한 호출, 나쁜 가격도 블록과 함께 최종화될 수 있어요. 블록 확신은 컨트랙트 감사나 경제적 판단을 대신하지 않습니다.
• 과거 상태가 항상 남는다고 가정하기: 노드가 옛 블록 헤더를 알아도 과거 잔액·코드·스토리지·호출·증명에 필요한 상태를 제공하지 않을 수 있습니다.

구현 전 빠른 체크리스트

• 각 조회가 최신성, 일관성, 정산 확신 중 무엇을 요구하는지 적어 두세요.
• 라이브러리 기본값에 맡기지 말고 블록 매개변수를 명시하세요.
• 파생 데이터와 함께 블록 번호와 해시를 기록하세요.
• 여러 호출은 한 블록 기준점에 고정하세요.
• latest와 잠정 이벤트 데이터에는 재구성 처리를 구현하세요.
• 실제 RPC 엔드포인트에서 safe, finalized, pending, EIP-1898 지원을 시험하세요.
• 폴백 동작을 정하고, 정산 검사를 몰래 latest로 낮추지 마세요.
• 체인 ID와 네트워크별 최종성 의미를 같은 정책에서 관리하세요.

자주 묻는 질문 (FAQ)

latest는 최신 최종화 블록인가요?

아닙니다. 클라이언트가 본 최신 정식 체인 블록이며, 실행 API 명세도 정상 상황에서 재구성될 수 있다고 설명합니다. 앱이 최종화 수준의 확신을 요구한다면 finalized를 사용하세요.

safe는 절대로 재구성되지 않는다는 뜻인가요?

절대적인 보장으로 해석하면 안 됩니다. 명세는 정직한 다수와 네트워크 동기성 가정 아래 안전하다고 정의해요. 체인 머리보다 강하지만 최종화 상태와는 구분됩니다.

두 RPC 제공자의 pending 결과가 왜 다른가요?

각 노드는 로컬 트랜잭션 풀을 관리하고 서로 다른 후보 상태를 만들 수 있어요. 합의가 실제 블록을 고르기 전에는 전파, 필터링, 순서, 노드 정책이 다를 수 있습니다.

인덱서는 모든 필드를 finalized에서만 읽어야 하나요?

꼭 그렇지는 않습니다. 최신성을 크게 잃고, 되돌릴 수 있는 화면에는 불필요할 수 있어요. 많은 시스템은 최근 블록을 잠정 수집하고 해시를 저장하며 재구성을 처리한 뒤, 정한 확신 기준을 넘으면 기록 상태를 승격합니다.

일관된 스냅샷에는 블록 번호면 충분한가요?

움직이는 태그보다는 낫지만 재구성으로 같은 높이의 정식 블록이 바뀔 수 있어요. 해시도 함께 저장하세요. 지원되는 환경이라면 requireCanonical을 포함한 EIP-1898 해시 선택자가 의도한 블록의 정체성을 더 분명하게 표현합니다.

마무리

이더리움 조회는 블록 기준점 없이 완전하지 않습니다. 최신 잠정 상태는 latest, 더 강한 확신은 safe나 finalized, 로컬 미리 보기를 받아들일 때만 pending을 선택하세요. 재현성이 중요하면 번호나 해시에 고정하고, 해석된 블록의 번호와 해시를 기록하며 오류와 재구성을 처리해야 합니다.

이 글은 교육 목적이며 투자 조언이 아닙니다. 크립토 네트워크, 앱, 자산에는 기술적·시장 위험이 있어요. 최신 명세를 확인하고 실제 제공자를 테스트하며, 잃어도 되는 범위에서만 참여하고 스스로 조사하세요(DYOR).