거래 영수증(transaction receipt)에는 거래 실행 뒤의 상태값, 누적 가스 사용량, 생성된 로그, 그리고 이 로그들로 만든 2048비트 블룸 필터(bloom)가 담깁니다. 로그 하나는 이벤트를 내보낸 컨트랙트 주소, 최대 네 개의 토픽(topic), 데이터로 이뤄지며 이벤트 시그니처는 보통 topic0에 들어갑니다. 블룸은 주소와 토픽마다 해시에서 고른 비트들을 켜 둡니다. 덕분에 후보에 없다는 사실은 빠르게 판정하지만, 필요한 비트가 모두 켜져 있어도 다른 값들이 우연히 겹쳤을 수 있는 거짓 양성이 생깁니다. 그래서 블록 헤더의 logsBloom으로 후보 블록을 거른 뒤, 영수증 안의 실제 주소와 토픽을 다시 맞춰 봐야 이벤트가 있었다고 확정할 수 있습니다.
거래 결과는 영수증에 따로 남습니다
이더리움 거래 본문에는 실행 뒤 생길 이벤트가 미리 들어 있지 않습니다. 실행 클라이언트는 거래마다 영수증을 만들어 성공 여부, cumulativeGasUsed, logsBloom, 로그 목록을 기록합니다. 컨트랙트 생성 거래라면 contractAddress 같은 RPC 파생 필드도 보이지만, 합의용 영수증 인코딩과 JSON-RPC 응답 필드는 구분해야 합니다.
상태값 1은 EVM 실행이 성공했다는 뜻일 뿐, 애플리케이션이 기대한 이벤트가 꼭 일어났다는 보장은 아닙니다. 상태값 0인 실패 거래는 상태 변경과 로그가 모두 되돌려집니다. 안쪽 호출(CALL)이 실패했어도 바깥 코드가 이를 처리하고 계속 진행했다면 영수증 전체는 성공으로 남을 수 있으므로, 실행 추적과 계약 로직을 함께 봅니다.
블룸은 이벤트를 찾아 주는 색인이 아닙니다. 찾는 주소나 토픽이 이 블록에는 없다고 빠르게 걸러 주는 확률적 표지입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 거래 결과는 영수증에 따로 남습니다
이더리움 거래 본문에는 실행 뒤 생길 이벤트가 미리 들어 있지 않습니다.
- 로그의 주소·토픽·데이터는 맡은 역할이 다릅니다
LOG0부터 LOG4까지의 옵코드는 지금 실행 중인 주소와 0~4개의 토픽, 길이 제한 없는 데이터를 묶어 로그 항목을 만듭니다.
- 블룸은 세 군데 비트 위치를 확인합니다
주소나 토픽을 Keccak-256으로 해시한 뒤, 정해진 세 개의 11-bit 값을 0~2047 위치로 써서 블룸 비트를 켭니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
로그의 주소·토픽·데이터는 맡은 역할이 다릅니다
LOG0부터 LOG4까지의 옵코드는 지금 실행 중인 주소와 0~4개의 토픽, 길이 제한 없는 데이터를 묶어 로그 항목을 만듭니다. 솔리디티 이벤트의 표준 시그니처 해시가 보통 첫 토픽이 되고, 인덱싱된 인수들이 뒤쪽 토픽에 들어갑니다. 인덱싱된 동적 값은 원문 대신 해시로 저장되므로 영수증만으로는 문자열 원문을 되살릴 수 없습니다.
인덱싱하지 않은 인수는 ABI 인코딩을 거쳐 데이터에 들어갑니다. 익명 이벤트는 시그니처 토픽을 빼 버릴 수 있고, 서로 다른 ABI가 같은 원본 로그를 전혀 다른 뜻으로 읽을 수도 있습니다. 디코더는 주소와 배포 당시의 코드·ABI 버전을 고정해 두고, topic0 하나만 보고 계약을 믿지 않습니다.
| 자료 | 포함 정보 | 판정 한계 |
|---|---|---|
| 블록 헤더 logsBloom | 블록 안 주소·토픽 비트의 합집합 | 거짓 양성 가능 |
| 영수증 logsBloom | 거래 하나의 로그 비트 합집합 | 실제 로그 위치는 모름 |
| 로그 주소 | 이벤트를 내보낸 실행 주소 | 코드의 의미는 ABI가 있어야 앎 |
| 토픽 | 검색할 수 있는 인덱싱 값 | 동적 값 원문은 해시로만 남음 |
| 데이터 | 인덱싱하지 않은 ABI 바이트 | 토픽 필터 검색 대상 아님 |
블룸은 세 군데 비트 위치를 확인합니다
주소나 토픽을 Keccak-256으로 해시한 뒤, 정해진 세 개의 11-bit 값을 0~2047 위치로 써서 블룸 비트를 켭니다. 여러 로그의 값은 OR 연산으로 합쳐집니다. 찾는 값의 세 비트 중 하나라도 0이면 그 범위에는 값이 확실히 없습니다. 반대로 모두 1이어도 다른 여러 값이 우연히 같은 비트를 켰을 수 있습니다.
이를테면 인기 있는 ERC-20 Transfer 시그니처와 수많은 컨트랙트 주소가 담긴 블록은 켜진 비트가 많습니다. 특정 토큰 주소와 계정 토픽 조합이 블룸을 통과했더라도, 실제 영수증 로그에서 한 항목이 모든 조건을 동시에 채우는지 확인해야 합니다. 조건마다 서로 다른 로그가 비트를 켜 줬을 수도 있기 때문입니다.
- 블록 해시·번호와 영수증을 함께 저장합니다.
- 주소와 토픽 필터로 블룸 후보를 좁힙니다.
- 후보 영수증의 실제 로그 항목을 다시 대조합니다.
- ABI 버전에 맞춰 인덱싱 값과 데이터를 디코딩합니다.
- 재편성이 일어나면 빠진 블록에서 파생된 상태를 되돌립니다.
거래 하나의 가스 사용량은 따로 계산합니다
영수증의 cumulativeGasUsed는 그 블록 안에서 해당 거래까지 쌓인 누적 사용량입니다. 거래 하나만의 가스 사용량은 현재 영수증의 누적값에서 직전 영수증의 누적값을 빼거나, RPC가 주는 gasUsed 필드를 씁니다. 가스 한도나 effectiveGasPrice와도 다른 값입니다.
타입이 붙은 거래가 도입된 뒤로는 영수증도 타입 봉투에 담길 수 있습니다. 클라이언트 API가 effectiveGasPrice나 블롭 관련 사용량 같은 확장 필드를 덧붙이더라도, 모든 포크와 체인에서 똑같다고 가정하지 않습니다. 원본 영수증과 RPC 스키마를 낸 클라이언트 버전을 기록해 둡니다.
재편성으로 블록이 빠지면 영수증도 사라집니다
최신 블록의 영수증은 정식 체인 후보에 들어갔다는 지금 시점의 관찰일 뿐입니다. 체인 재편성으로 블록이 빠지면 그 영수증과 로그도 정식 기록에서 사라집니다. 구독 API의 removed 표시를 처리하거나, 저장해 둔 블록 해시를 새 정식 해시와 맞춰 봐야 합니다.
입금이나 NFT 상태를 로그 하나로 갱신하면서 transactionHash만 고유 키로 쓰면, 같은 거래에서 나온 여러 로그가 서로를 덮어씁니다. 체인 ID, 블록 해시, 거래 해시, 로그 인덱스를 식별자로 삼고 safe·finalized 정책에 맞춰 임시 상태와 확정 상태를 나눕니다.
자주 묻는 질문
로그 블룸이 맞으면 이벤트가 반드시 있나요?
아닙니다. 해시 비트가 겹쳐 거짓 양성이 나올 수 있으니 실제 영수증의 주소와 토픽을 확인해야 합니다.
실패한 거래의 이벤트도 영수증에 남나요?
되돌려진 호출 프레임의 로그는 버려집니다. 바깥 호출이 실패를 처리해 전체가 성공했다면, 성공한 프레임의 로그는 남을 수 있습니다.
인덱싱된 문자열을 토픽에서 원문으로 되살릴 수 있나요?
토픽에는 동적 값의 해시가 들어갑니다. 원문 후보를 알고 있다면 맞는지 검증할 수는 있지만, 해시만으로 원문을 일반적으로 되살릴 수는 없습니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
