이벤트 log는 계약이 실행 중 LOG opcode로 남기는 receipt 데이터이고, token balance는 contract storage를 balanceOf 등으로 읽은 상태입니다. 표준적인 ERC-20 구현은 실제 잔액 변경과 Transfer event를 함께 처리하지만 EVM이 임의 계약에 대해 둘의 일치를 자동 강제하지는 않습니다. 성공 receipt, 공식 contract code, 해당 block의 balanceOf·storage 변화와 log emitter 주소를 함께 확인해야 로그만 만든 가짜 토큰이나 인덱서 오해를 피할 수 있습니다.
로그와 상태는 저장 위치가 다릅니다
Ethereum block에는 state_root와 receipts_root가 별도로 있고 receipt에는 status, gas와 logs가 포함됩니다. contract는 event를 emit해 앱과 indexer가 찾기 쉬운 기록을 만들 수 있습니다. storage는 다음 transaction 실행이 읽고 쓰는 지속 상태이며 log는 contract가 다시 읽는 저장소가 아닙니다.
ethereum.org의 smart contract anatomy는 검증된 transaction 뒤 contract가 event를 emit하고 frontend가 이를 처리할 수 있다고 설명합니다. UI가 log를 빠르게 반영해 활동 내역을 만들더라도 현재 상태 조회와 차이가 날 수 있습니다.
이벤트는 계약이 남긴 알림이고, 상태는 다음 실행이 실제로 참조하는 원장 값입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 로그와 상태는 저장 위치가 다릅니다
Ethereum block에는 state_root와 receipts_root가 별도로 있고 receipt에는 status, gas와 logs가 포함됩니다.
- Transfer 글자만 보고 자산 이동을 확정하지 않습니다
ERC-20 Transfer event의 signature와 indexed from·to, value 형식을 누구나 흉내 낸 contract에서 emit할 수 있습니다.
- 실패 거래의 로그는 최종 결과로 남지 않습니다
EIP-140은 execution이 revert하면 state changes뿐 아니라 accrued logs도 되돌아간다고 설명합니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
Transfer 글자만 보고 자산 이동을 확정하지 않습니다
ERC-20 Transfer event의 signature와 indexed from·to, value 형식을 누구나 흉내 낸 contract에서 emit할 수 있습니다. 유명 token과 같은 event가 보여도 emitter address가 공식 token contract가 아니면 그 자산의 이동이 아닙니다. 탐색기 라벨과 symbol보다 log.address를 확인합니다.
비표준 또는 악성 contract는 event만 emit하고 balance mapping을 바꾸지 않을 수 있습니다. 반대로 rebasing token이나 내부 회계는 단순 Transfer 합산만으로 현재 balance를 재현하기 어려울 수 있습니다. 표준 가정을 프로젝트별 구현에 무조건 적용하지 않습니다.
| 자료 | 보여 주는 것 | 한계 |
|---|---|---|
| Receipt status | 최상위 실행 성공 여부 | 세부 상태는 별도 |
| Event log | contract가 emit한 알림 | 진실성 자동 보장 없음 |
| balanceOf | 현재 token balance | 호출 block 지정 필요 |
| State diff | 변경 storage·balance | 노드·도구 지원 필요 |
| Trace | 내부 호출 경로 | 원 거래와 별도 tx 아님 |
실패 거래의 로그는 최종 결과로 남지 않습니다
EIP-140은 execution이 revert하면 state changes뿐 아니라 accrued logs도 되돌아간다고 설명합니다. 내부 call이 log를 emit한 뒤 상위 call이 revert하면 최종 성공 이벤트로 사용할 수 없습니다. receipt status와 호출 성공 여부를 먼저 확인합니다.
일부 trace 도구는 실패한 내부 실행 과정에서 생성됐다가 폐기된 정보도 디버깅용으로 보여 줄 수 있습니다. 이를 최종 receipt logs와 구분해야 합니다. 탐색기 탭 이름이 ‘events’라고 해서 모두 canonical 성공 로그인 것은 아니므로 데이터 출처를 확인합니다.
- 올바른 chain과 TxID를 확인합니다.
- receipt status를 먼저 봅니다.
- log emitter 주소를 공식 contract와 대조합니다.
- topics·data를 정확한 ABI로 decode합니다.
- 해당 block의 balanceOf와 state diff를 확인합니다.
인덱서는 로그를 해석해 별도 화면을 만듭니다
wallet과 analytics 서비스는 logs를 수집해 transfers, trades, approvals로 분류합니다. 새 block 처리, chain reorg, ABI 변경, 누락 구간 때문에 화면이 늦거나 다시 계산될 수 있습니다. 인덱서 결과는 편리하지만 노드의 확정 state와 동일한 시점이 아닐 수 있습니다.
ethereum.org data 문서는 onchain raw tables를 blocks, transactions, logs, traces로 나누고 indexer가 event를 질의 가능한 데이터로 바꾼다고 설명합니다. 두 서비스의 token history가 다르면 각자의 last indexed block과 contract filter를 비교합니다.
감사와 운영에서 둘을 함께 기록합니다
입금 시스템은 Transfer event를 감지한 뒤 receipt finality, 공식 contract, recipient, amount를 확인하고 내부 ledger에 반영해야 합니다. event 하나만으로 credit하면 가짜 emitter나 reorg에 취약합니다. balance 변화만 폴링하면 개별 원인을 잃을 수 있어 두 자료를 조합합니다.
사용자 조사 기록에는 TxID, block, receipt status, emitter, decoded event, 전후 balanceOf를 넣습니다. 프록시 token이면 proxy 주소에서 emit됐는지와 block 시점 implementation을 확인합니다. 이 증거가 있어야 ‘로그는 보이지만 잔액이 없다’를 정확히 설명할 수 있습니다.
자주 묻는 질문
Transfer 이벤트가 있으면 토큰을 받은 것 아닌가요?
공식 token contract가 emit했고 성공 receipt와 balanceOf가 일치하는지 확인해야 합니다.
revert 전에 emit된 이벤트도 탐색기에 남나요?
최종 receipt logs에는 남지 않습니다. trace 디버깅 화면에서 실행 흔적이 보일 수 있어 구분해야 합니다.
지갑 활동 내역과 balance가 다른 이유는 무엇인가요?
인덱서 지연·잘못된 contract 분류·reorg·비표준 token 구현이 원인일 수 있습니다.
