비트코인에는 없고 이더리움에만 있는 것들: Receipts와 Blob의 진짜 의미

※ 이 글은 현재 버전으로 우선 게시되며, 2일 후 Daily Crypto Times(DCT) 포맷에 맞춘 최종 버전으로 업데이트될 예정입니다.

Ethereum 블록 파이프라인과 Receipts — 비트코인과 무엇이 다르고 Blob과는 어떻게 다른가

비탈릭 부테린은 사토시 나카모토가 만든 비트코인 네트워크 위에 스마트 계약을 실행할 수 있는 범용 컴퓨팅 레이어를 더하고자 하였습니다. 이를 위해 비트코인의 UTXO 모델을 넘어 계정 기반(Account Model)으로 전환한 소위 “2세대 블록체인”을 설계하였습니다. 그 결과 이더리움은 비트코인보다 훨씬 복잡한 구조를 가지게 되었고, 블록체인 내부 데이터 처리 방식도 크게 달라졌습니다.

본 글은 다음 두 편의 글을 먼저 읽어보시면 이해에 큰 도움이 됩니다.
1) 비트코인 채굴처럼 경쟁하는 이더리움 Builder: ePBS 구조 완전 해설
2) L2 확장 논란의 진실: 왜 지금은 Rollup-first가 최선인가

이 두 글은 이더리움의 블록 생성 구조와 L2 확장 전략을 이해하는 데 중요한 배경을 제공합니다. 본 글에서는 그 연장선에서, 이더리움 구조의 핵심 차이를 보여주는 두 가지 요소, 즉 스마트 계약 실행을 검증하는 영수증(Receipts) 메커니즘L2 확장성을 제공하는 Blob 데이터 처리 방식을 중심으로 설명드리고자 합니다. 이 두 가지는 이더리움이 왜 비트코인과 다른 구조를 선택했는지, 그리고 2세대 블록체인의 방향이 과연 성공적인지 다시 생각해볼 수 있는 중요한 단서가 됩니다. 일반 독자분들께는 다소 어려울 수 있으나, 최대한 쉽게 설명해보겠습니다.


대부분의 사람들은 블록체인을 “블록헤더 + 블록바디가 연결된 체인”으로 이해합니다. 비트코인처럼 새로운 블록이 생성되면 그 블록만 네트워크에 전파되면 된다고 생각합니다.

그러나 이더리움은 훨씬 복잡한 구조를 가지고 있습니다. 이더리움의 블록 검증 과정에는 블록 헤더와 블록 바디뿐 아니라 블록 영수증(Receipts)이라는 별도의 데이터가 반드시 함께 전파되고 검증되어야 합니다.

Receipts는 블록 생성 시 트랜잭션 목록과 함께 만들어지며, 블록 헤더에는 receiptsRoot라는 형태로 요약되어 기록됩니다. 따라서 블록이 유효하게 검증되려면 검증 노드들은 블록헤더와 바디뿐 아니라 Receipts까지 포함한 전체 실행 결과를 확인해야 합니다.

또한 이더리움 L2가 L1에 올리는 Blob 데이터(EIP-4844) 역시 L1 블록체인과는 별도로 L2·시퀀서·DA 레이어 등에서 장기적으로 보관되어야 합니다. 이 구조를 이해해야 이더리움의 검증 방식과 Rollup 기반 L2 확장 구조를 제대로 이해할 수 있습니다.


1) 블록 파이프라인 전체에서 Receipts는 어디서 등장하는가

이더리움의 블록 생성 파이프라인은 다음과 같이 진행됩니다.

  • 사용자(User): 트랜잭션을 네트워크에 전송합니다.
  • 빌더(Builder): 트랜잭션을 실행(EVM)하고 블록 바디(트랜잭션 목록)와 Receipts를 생성합니다.
  • 프로포저(Proposer): 빌더가 만든 블록을 선택해 네트워크에 전파합니다.
  • 검증 노드(Validators): 블록을 수신한 뒤 트랜잭션을 재실행하고 자신이 계산한 receiptsRoot와 블록 헤더의 receiptsRoot를 비교합니다.

이 과정에서 중요한 점은 블록 바디와 Receipts가 분리된 데이터 구조라는 것입니다.

  • 블록 바디(Block Body): 트랜잭션 목록만 포함합니다.
  • Receipts: 각 트랜잭션의 실행 결과를 담습니다. (성공/실패, 가스 사용량, 이벤트 로그, 내부 호출 결과 등)

블록 헤더에는 Receipts 전체가 아니라 receiptsRoot만 저장됩니다. 검증 노드는 이를 기준으로 실행 결과가 변조되지 않았음을 확인합니다.


2) 이더리움은 왜 Receipts가 반드시 필요한가

비트코인은 UTXO 모델 덕분에 “결과만 맞으면” 검증이 가능합니다. 그러나 이더리움은 스마트컨트랙트 플랫폼이기 때문에 실행 과정이 훨씬 복잡합니다.

트랜잭션 하나가 다음을 포함할 수 있습니다.

  • 여러 컨트랙트 호출
  • 내부 트랜잭션
  • 이벤트 로그 발생
  • 가스 소모
  • 성공 또는 실패

이런 실행 과정의 정보는 state에 저장되지 않습니다. 따라서 Receipts는 다음을 기록하는 유일한 구조입니다.

  • 이벤트 로그(Event Logs)
  • 가스 사용량
  • 성공/실패 여부
  • 내부 호출 정보

Receipts가 있기 때문에 블록 탐색기(Etherscan), 인덱싱 서비스(The Graph), 지갑 서비스 등이 정확한 정보를 제공할 수 있습니다. 무엇보다 블록 헤더의 receiptsRoot는 블록 전체 실행 결과를 요약한 해시이므로 블록 검증에 필수적입니다.


3) Blob 데이터와 Receipts는 왜 완전히 다른가

Blob 데이터(EIP-4844)와 Receipts는 모두 “본문은 L1에 저장하지 않고 요약값만 저장한다”는 점에서 비슷해 보이지만, 목적과 보존 방식은 완전히 다릅니다.

Blob 데이터 — L2 데이터 가용성(DA)용

  • L2가 L1에 올리는 대용량 데이터입니다.
  • L1은 Blob의 commitment만 영구 저장합니다.
  • Blob 본문은 일정 기간 후 삭제됩니다.
  • L2·시퀀서·DA 레이어가 장기 보관합니다.

Receipts — L1 실행 결과 증명용

  • 트랜잭션 실행 결과와 이벤트 로그를 저장합니다.
  • L1은 receiptsRoot를 영구 저장합니다.
  • Receipts 본문은 노드·인덱서가 장기 보관합니다.

요약 비교

항목 Blob 데이터 Receipts
목적 L2 데이터 가용성 L1 실행 결과 증명
본문 보존 임시, 삭제 가능 외부 노드가 영구 보관
L1 저장 Blob commitment receiptsRoot
데이터 성격 대용량 L2 데이터 구조화된 실행 결과

맺음말

이더리움을 단순히 “블록헤더 + 블록바디의 체인”으로 이해하면 Receipts와 Blob 데이터의 존재 이유를 설명할 수 없습니다.

이더리움의 현실은 더 복잡합니다. Receipts는 L1의 실행 결과를 영구적으로 증명하는 데이터이며, Blob은 L2 확장을 위한 데이터 가용성 레이어입니다.

이 두 구조를 이해해야 이더리움이 어떻게 안전한 L1확장 가능한 L2를 동시에 지향하는지 선명하게 보입니다.

정윤찬 (Younchan Jung)
AI, 블록체인, 온체인 경제의 구조적 변화를 탐구하는 리서처.

This article is also available in English.

댓글

이 블로그의 인기 게시물

Ethereum’s Quiet Takeover: How Stablecoins and Tokenized Assets Are Rewriting Global Finance

The Real Reason the CLARITY Act Stalled: A USDC Yield War Between Coinbase and the Banks

비트코인은 자산, 이더리움은 인프라: 기관이 다시 짜는 글로벌 금융의 판도