이벤트 로그는 계약이 실행 중에 LOG 옵코드로 남기는 영수증(receipt) 데이터이고, 토큰 잔액은 계약 저장소를 balanceOf 같은 함수로 읽은 상태입니다. 표준적인 ERC-20 구현은 실제 잔액 변경과 Transfer 이벤트를 함께 처리합니다. 하지만 EVM이 아무 계약에나 둘의 일치를 자동으로 강제하지는 않습니다. 성공한 영수증, 공식 계약 코드, 해당 블록의 balanceOf·저장소 변화, 로그를 남긴 주소를 함께 확인해야 로그만 꾸며 낸 가짜 토큰이나 인덱서의 오해를 피할 수 있습니다.
로그와 상태는 저장 위치가 다릅니다
Ethereum 블록에는 state_root와 receipts_root가 따로 들어 있고, 영수증에는 실행 결과 상태, 가스, 로그가 담깁니다. 계약은 이벤트를 내보내 앱과 인덱서가 찾기 쉬운 기록을 남길 수 있습니다. 저장소는 다음 거래가 실행될 때 읽고 쓰는 지속 상태이고, 로그는 계약이 다시 읽어 들이는 저장 공간이 아닙니다.
ethereum.org의 스마트 계약 구조 설명에 따르면 거래가 검증된 뒤 계약이 이벤트를 내보내고, 프런트엔드가 이를 받아 처리할 수 있습니다. 화면이 로그를 빠르게 반영해 활동 내역을 만들더라도 현재 상태를 조회한 값과는 차이가 날 수 있습니다.
이벤트는 계약이 남긴 알림이고, 상태는 다음 실행이 실제로 참조하는 원장 값입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 로그와 상태는 저장 위치가 다릅니다
Ethereum 블록에는 state_root와 receipts_root가 따로 들어 있고, 영수증에는 실행 결과 상태, 가스, 로그가 담깁니다.
- Transfer 글자만 보고 자산 이동을 확정하지 않습니다
ERC-20 Transfer 이벤트의 서명과 색인된 보낸 주소·받는 주소, 금액 형식은 누구든 흉내 낸 계약에서 그대로 내보낼 수 있습니다.
- 실패 거래의 로그는 최종 결과로 남지 않습니다
EIP-140에 따르면 실행이 되돌려지면(revert) 상태 변경뿐 아니라 그동안 쌓인 로그도 함께 사라집니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
Transfer 글자만 보고 자산 이동을 확정하지 않습니다
ERC-20 Transfer 이벤트의 서명과 색인된 보낸 주소·받는 주소, 금액 형식은 누구든 흉내 낸 계약에서 그대로 내보낼 수 있습니다. 유명 토큰과 똑같은 이벤트가 보여도 로그를 남긴 주소가 공식 토큰 계약이 아니라면 그 자산이 움직인 것이 아닙니다. 탐색기 라벨이나 심볼보다 log.address를 확인합니다.
비표준 계약이나 악성 계약은 이벤트만 내보내고 잔액 기록은 바꾸지 않을 수 있습니다. 반대로 공급량이 자동 조정되는 리베이스 토큰이나 내부 회계를 쓰는 토큰은 Transfer를 단순히 더하는 것만으로 현재 잔액을 재현하기 어려울 수 있습니다. 표준을 전제로 한 가정을 프로젝트마다 다른 구현에 무조건 적용하지 않습니다.
| 자료 | 보여 주는 것 | 한계 |
|---|---|---|
| 영수증 상태 | 최상위 실행의 성공 여부 | 세부 상태는 따로 확인 |
| 이벤트 로그 | 계약이 내보낸 알림 | 내용이 참이라는 보장 없음 |
| balanceOf | 현재 토큰 잔액 | 조회 블록 지정 필요 |
| 상태 변화 내역 | 바뀐 저장소·잔액 | 노드·도구 지원 필요 |
| 실행 추적 | 내부 호출 경로 | 원래 거래와 별개인 거래가 아님 |
실패 거래의 로그는 최종 결과로 남지 않습니다
EIP-140에 따르면 실행이 되돌려지면(revert) 상태 변경뿐 아니라 그동안 쌓인 로그도 함께 사라집니다. 내부 호출이 로그를 남긴 뒤 상위 호출이 되돌려졌다면 그 로그를 최종 성공 이벤트로 쓸 수 없습니다. 영수증 상태와 호출 성공 여부를 먼저 확인합니다.
일부 추적 도구는 실패한 내부 실행에서 생겼다가 버려진 정보도 디버깅용으로 보여 줍니다. 이것을 최종 영수증의 로그와 구분해야 합니다. 탐색기 탭 이름이 ‘이벤트’라고 해서 모두 정식 성공 로그는 아니므로 데이터가 어디서 왔는지 확인합니다.
- 올바른 체인과 거래 ID를 확인합니다.
- 영수증 상태를 먼저 봅니다.
- 로그를 남긴 주소를 공식 계약과 대조합니다.
- 토픽과 데이터를 정확한 ABI로 해독합니다.
- 해당 블록의 balanceOf와 상태 변화 내역을 확인합니다.
인덱서는 로그를 해석해 별도 화면을 만듭니다
지갑과 분석 서비스는 로그를 모아 전송, 매매, 승인으로 분류합니다. 새 블록 처리, 체인 재편성(reorg), ABI 변경, 누락 구간 때문에 화면이 늦거나 다시 계산될 수 있습니다. 인덱서 결과는 편리하지만 노드가 확정한 상태와 같은 시점이 아닐 수 있습니다.
ethereum.org 데이터 문서는 온체인 원본 데이터를 블록, 거래, 로그, 실행 추적 표로 나누고, 인덱서가 이벤트를 조회 가능한 데이터로 바꾼다고 설명합니다. 두 서비스의 토큰 내역이 다르다면 각자 마지막으로 색인한 블록과 계약 필터를 비교합니다.
감사와 운영에서 둘을 함께 기록합니다
입금 시스템은 Transfer 이벤트를 감지한 뒤 영수증 확정 여부, 공식 계약, 받는 주소, 금액을 확인하고 나서 내부 장부에 반영해야 합니다. 이벤트 하나만 보고 입금 처리하면 가짜 발신 계약이나 재편성에 취약합니다. 잔액 변화만 주기적으로 조회하면 개별 원인을 놓칠 수 있으니 두 자료를 함께 씁니다.
사용자 문의 조사 기록에는 거래 ID, 블록, 영수증 상태, 로그 발신 주소, 해독한 이벤트, 전후 balanceOf를 넣습니다. 프록시 토큰이라면 프록시 주소에서 이벤트가 나왔는지, 그 블록 시점의 구현 계약이 무엇이었는지 확인합니다. 이런 증거가 있어야 ‘로그는 보이는데 잔액이 없다’는 상황을 정확히 설명할 수 있습니다.
자주 묻는 질문
Transfer 이벤트가 있으면 토큰을 받은 것 아닌가요?
공식 토큰 계약이 내보낸 이벤트인지, 영수증이 성공이고 balanceOf와도 맞는지 확인해야 합니다.
revert 전에 emit된 이벤트도 탐색기에 남나요?
최종 영수증의 로그에는 남지 않습니다. 실행 추적 디버깅 화면에는 실행 흔적이 보일 수 있으니 구분해야 합니다.
지갑 활동 내역과 balance가 다른 이유는 무엇인가요?
인덱서 지연, 잘못된 계약 분류, 체인 재편성, 비표준 토큰 구현이 원인일 수 있습니다.
