이더리움 블록 헤더 설명: 필드·루트·RPC 검증법

블록 탐색기는 수백 개 트랜잭션을 보여주지만, 이더리움은 그 블록을 하나의 해시로 식별해요. 긴 페이로드와 작은 식별자를 연결하는 구조가 **블록 헤더(Block Header)**입니다. 부모 해시, 상태 커밋, 가스 계산, 시간을 한곳에 묶어 검증 가능한 블록체인 기초를 만들죠.

헤더는 훼손 여부를 확인할 수 있는 화물 라벨과 비슷해요. 라벨 안에 모든 물건이 들어 있지는 않습니다. 대신 운송 경로, 총량, 봉인된 지문을 기록해 수령자가 화물과 명세가 맞는지 확인하게 해요. 이 글에서는 JSON-RPC로 보이는 실행 레이어(Execution Layer) 필드, 지분증명 비콘 블록(Beacon Block)과의 관계, 헤더가 증명하지 못하는 범위까지 살펴봅니다.

이더리움 블록 헤더가 하는 일

실행 블록 헤더의 역할은 네 가지로 정리할 수 있어요.

1. 기록을 연결합니다. parentHash가 앞선 실행 블록을 가리켜요. 과거 헤더가 바뀌면 이를 참조하는 뒤쪽 블록도 영향을 받습니다.
2. 데이터와 결과에 커밋합니다. 루트 필드가 트랜잭션, 영수증, 실행 후 상태를 요약해요.
3. 실행 제약을 기록합니다. 가스, 수수료, 시간, 블록 번호는 클라이언트가 블록을 검증할 때 필요한 입력입니다.
4. 블록 해시를 만듭니다. 프로토콜이 정한 순서와 방식으로 헤더를 인코딩한 뒤 해시해요. RPC 제공자가 보낸 임의의 JSON 문자열을 그대로 해시하는 방식이 아닙니다.

공식 이더리움 블록 문서는 지분증명 비콘 블록과 그 안의 실행 페이로드(Execution Payload)를 구분합니다. 머지(The Merge) 이후 합의 레이어는 비콘 블록을 선택·최종화하고, 실행 레이어는 트랜잭션을 처리해 페이로드가 올바른지 검사해요.

핵심 실행 헤더 필드 읽기

네트워크 업그레이드가 기능을 추가하면 필드 집합도 늘어납니다. 따라서 실제 구현은 대상 포크(Fork)의 명세를 따라야 해요. 아래 표는 eth_getBlockByNumber에서 흔히 만나는 핵심 필드입니다.

표준 Ethereum Execution API는 개발자가 쓰기 편한 블록 객체를 반환해요. 이름은 합의 명세와 다를 수 있습니다. RPC에서는 흔히 miner라고 표시하지만, 머지 이후 실행 페이로드 명세는 그 역할을 fee_recipient라고 불러요. difficulty, mixHash, nonce처럼 과거 형태를 따르는 필드도 호환성을 위해 남을 수 있지만, 지분증명 검증에서는 작업증명 때와 같은 뜻으로 쓰이지 않습니다.

세 가지 루트는 무엇이 다른가요?

가장 중요한 세 커밋은 서로 다른 질문에 답해요.

상태 루트: 실행이 무엇을 만들었나?

stateRoot는 블록의 모든 트랜잭션을 실행한 뒤 이더리움 전역 상태에 커밋합니다. 계정 논스(Nonce)와 잔액, 컨트랙트 코드와 스토리지 커밋이 대상이에요. 실행 클라이언트는 부모 상태에서 시작해 트랜잭션을 순서대로 처리하고, 자신이 계산한 결과 루트가 헤더와 같은지 확인합니다.

이더리움 머클 패트리샤 트라이 가이드를 보면 32바이트 루트가 모든 계정의 압축 사본이 아니라, 훨씬 큰 키-값 구조의 지문인 이유를 이해할 수 있어요.

트랜잭션 루트: 어떤 입력이 어떤 순서로 들어갔나?

transactionsRoot는 정확한 순서의 트랜잭션 인코딩에 커밋해요. 두 거래가 같은 상태를 건드리면 순서를 바꾸는 것만으로 결과가 달라질 수 있습니다. 탐색기가 보여주는 트랜잭션 해시 목록은 편리하지만, 포함 증명을 만들려면 합의 인코딩과 트라이 위치가 필요해요.

영수증 루트: 어떤 실행 기록이 남았나?

receiptsRoot는 순서가 있는 영수증 인코딩에 커밋합니다. 영수증에는 적용되는 규칙에 따라 상태 코드 또는 과거 상태 루트 형식, 누적 가스, 블룸 데이터, 로그가 들어가요. 전체 옵코드 실행 트레이스가 들어가는 것은 아닙니다.

트랜잭션이나 영수증이 하나라도 바뀌면 해당 트라이 루트가 달라집니다. 실행 결과가 다르면 stateRoot도 바뀌어요. 이 루트들이 헤더 안에 있으므로 최종 블록 해시까지 달라집니다.

가스·수수료·포크 추가 필드

gasLimit은 블록의 실행 예산이고, gasUsed는 포함된 트랜잭션이 실제로 사용한 양입니다. EIP-1559가 도입한 baseFeePerGas는 실행 가스의 프로토콜 기본 가격이에요. 사용자의 실효 단가에는 우선 수수료(Priority Fee)가 더해질 수 있으므로, 헤더의 기본 수수료가 모든 거래의 최종 비용은 아닙니다.

프로토콜 업그레이드는 새 데이터에 블록이 커밋해야 할 때 필드를 더합니다.

• EIP-4895는 합의 레이어 출금을 실행 레이어에서 처리하기 위한 출금 커밋을 추가했어요.
• EIP-4844는 별도 블롭 데이터 수수료 시장을 위해 blobGasUsed와 excessBlobGas를 추가했습니다.
• 이후 포크도 다른 커밋을 추가할 수 있어요. 소프트웨어는 하나의 고정된 헤더 형태를 가정하지 말고 선택한 블록의 명세와 실제 필드를 확인해야 합니다.

따라서 gasUsed 하나만으로 모든 비용을 설명할 수 없는 경우가 있어요. 블롭 가스는 별도로 계산됩니다. 일반 사용자 거래의 실제 실행 비용은 영수증의 트랜잭션별 gasUsed와 실효 가격을 함께 봐야 해요.

실행 헤더와 비콘 블록 헤더의 차이

현재 이더리움에는 이름이 비슷해 혼동하기 쉬운 두 구조가 있습니다.

**비콘 블록 헤더(Beacon Block Header)**는 합의 레이어 구조예요. 슬롯, 제안자 인덱스, 부모 루트, 상태 루트, 바디 루트를 담습니다. 비콘 블록 본문에는 어테스테이션(Attestation), 실행 페이로드 등 합의 객체가 들어가요.

**실행 페이로드 헤더(Execution Payload Header)**는 실행 페이로드를 요약합니다. 부모 실행 해시, 수수료 수령자, 실행 상태·영수증 루트, 가스 필드, 타임스탬프, 트랜잭션 루트와 포크별 추가 필드가 대상이에요. Bellatrix 합의 명세는 합의 처리가 실행 페이로드의 부모 해시, 무작위성 입력, 시간, 실행 유효성을 확인한 뒤 헤더를 저장하는 과정을 보여줍니다.

선택된 제안자가 기회를 놓치면 비어 있는 비콘 슬롯이 생길 수 있어요. 그래서 슬롯 번호와 실행 블록 번호는 같은 카운터가 아닙니다. 비콘의 state_root는 합의 상태에 커밋하고, 실행의 stateRoot는 EVM 계정과 컨트랙트 상태에 커밋해요. 표현은 비슷하지만 서로 다른 상태 머신입니다.

JSON-RPC로 안전하게 블록 확인하기

표준 메서드는 블록 선택자와 트랜잭션을 해시만 받을지 전체 객체로 받을지 정하는 불리언(Boolean)을 인자로 받아요.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_getBlockByNumber",
  "params": ["finalized", false]
}

실전에서는 다음 순서로 확인해 보세요.

1. 신뢰 기준을 선택하세요. 재현성이 필요하면 특정 블록 번호나 해시를 사용합니다. 결과의 영향이 크면 safe 또는 finalized를 선택해 재구성(Reorg) 위험을 낮춰요.
2. 번호와 해시를 함께 기록하세요. 체인 머리 근처에서는 재구성 뒤 같은 번호가 다른 블록을 가리킬 수 있습니다.
3. 부모 연결을 확인하세요. 자식의 parentHash가 선택한 부모 블록 해시와 같아야 해요.
4. 루트의 역할을 분리하세요. 상태·트랜잭션·영수증은 서로 다른 커밋이며 대신할 수 없습니다.
5. 16진수 수량을 변환하세요. JSON-RPC 수량은 10진 텍스트가 아니라 16진 문자열이에요.
6. JSON을 그대로 다시 해시하지 마세요. 블록 해시를 재현하려면 포크에 맞는 합의 헤더와 인코딩이 필요합니다. JSON 키를 알파벳순으로 정렬하는 것으로는 안 돼요.

이더리움 JSON-RPC 블록 태그 가이드는 latest, safe, finalized, pending, 명시적 식별자의 차이를 자세히 설명합니다.

리스크와 한계

• 유효한 헤더가 곧 최종화된 헤더는 아닙니다. 최근의 유효한 블록도 정식 체인에서 빠질 수 있어요. 결과의 영향에 맞는 최종성 정책이 필요합니다.
• 증명에는 신뢰할 루트가 필요합니다. 같은 불신 대상이 준 헤더에 대해 머클 증명이 맞는다고 해서 그 헤더까지 독립적으로 인증되는 것은 아니에요.
• RPC 객체는 인터페이스이지 합의 바이트가 아닙니다. 제공자가 선택·포크별 필드를 생략할 수 있고, pending 응답에는 null 값이 들어갈 수 있어요.
• 블룸 필터에는 거짓 양성(False Positive)이 있습니다. logsBloom은 데이터가 없음을 빠르게 걸러내지만, 일치 후보는 실제 로그에서 다시 확인해야 합니다.
• 타임스탬프는 정밀 시계가 아닙니다. 프로토콜 제약을 받는 입력이지 현실 사건의 정확한 발생 시간을 보증하는 오라클이 아니에요.
• 헤더 유효성이 앱 안전성을 보증하지 않습니다. 올바른 루트도 사기 거래, 취약한 컨트랙트, 경제적으로 불리한 교환에 커밋할 수 있습니다.

검증 체크리스트

• 의도한 체인과 블록 선택자인지 확인하기
• 블록 번호와 해시를 함께 저장하기
• parentHash와 부모 블록 해시 대조하기
• 비콘 루트와 실행 루트 구분하기
• gasLimit, gasUsed, 기본 수수료, 블롭 가스 구분하기
• 개별 거래 결과와 비용은 영수증 필드로 확인하기
• 블룸 일치는 후보로만 보고 실제 로그 검사하기
• 블록 해시 재계산 전 포크에 맞는 합의 인코딩 사용하기
• 중요한 동작에는 명시적인 safe/finalized 정책 적용하기
• 독립적으로 신뢰한 합의 경로를 통해 증명의 루트 확인하기

자주 묻는 질문

블록 해시와 상태 루트는 같은 값인가요?

아닙니다. 상태 루트는 실행 후 상태에 커밋해요. 블록 해시는 상태 루트뿐 아니라 부모 연결, 트랜잭션·영수증 커밋, 가스, 시간과 포크가 정한 다른 필드까지 포함한 실행 헤더를 식별합니다.

헤더 안에 모든 트랜잭션이 들어 있나요?

아니요. transactionsRoot를 통해 순서가 있는 인코딩에 커밋합니다. 트랜잭션 목록은 실행 페이로드나 RPC 블록 객체가 별도로 전달할 수 있어요.

JSON-RPC에 miner나 difficulty가 왜 남아 있나요?

API가 이더리움 역사 전반에서 사용한 블록 객체 형태를 유지하기 때문입니다. 머지 이후 수수료 수령자와 무작위성 필드는 지분증명 의미를 가지며, 일부 레거시 필드는 호환 값으로 남아요. 필드 이름만 보고 작업증명 채굴이 활성 상태라고 판단하면 안 됩니다.

트랜잭션 해시와 블록 헤더만으로 포함을 검증할 수 있나요?

그 두 값만으로는 부족해요. 정확히 인코딩한 트랜잭션, 인덱스 또는 트라이 키, 헤더의 트랜잭션 루트에 대한 유효한 포함 증명이 필요합니다. 그 헤더가 내 용도에 충분히 정식 체인이라는 신뢰 근거도 있어야 해요.

실행 블록 번호와 비콘 슬롯은 같은가요?

아닙니다. 합의 시계의 슬롯은 블록이 제안되지 않아도 앞으로 나아가요. 실행 블록 번호는 실행 블록이 만들어질 때 증가합니다.

주요 출처

• Ethereum.org: Blocks
• Ethereum Execution APIs: eth_getBlockByNumber
• Ethereum.org: JSON-RPC API
• Ethereum consensus specs: Bellatrix Beacon Chain
• EIP-1559: Fee market change
• EIP-4895: Beacon chain push withdrawals
• EIP-4844: Shard blob transactions

핵심 정리

이더리움 블록 헤더는 블록의 작은 복사본이 아니라 검증을 위한 압축된 표면입니다. 부모 연결은 기록의 순서를 만들고, 여러 루트는 입력과 결과에 커밋하며, 가스와 시간 필드는 실행을 제한해요. 포크가 추가한 필드는 블록이 책임질 범위를 넓힙니다. 각 필드를 해당 레이어와 포크에 맞춰 읽고, 증명의 기반이 되는 헤더부터 인증하며, 결과의 영향에 맞는 최종성 기준을 적용하세요.

이 글은 교육 목적이며 투자 조언이 아닙니다. 프로토콜에 맞는 블록에도 위험한 자산, 악성 컨트랙트, 되돌릴 수 없는 실수가 포함될 수 있어요. 도구를 충분히 시험하고 1차 명세를 직접 확인하세요. 잃어도 생활에 지장 없는 금액만 사용하고 스스로 조사하세요(DYOR).