탐색기의 ‘internal transaction’은 보통 별도의 서명된 Ethereum transaction이 아니라 하나의 외부 transaction을 실행하는 동안 contract가 CALL·DELEGATECALL·CREATE 등으로 만든 내부 호출을 trace한 표시입니다. 자체 transaction hash와 nonce를 가진 새 거래가 아니며 원 transaction의 성공·실패 상태에 종속됩니다. value 이동과 호출 경로를 이해하는 데 유용하지만 탐색기 제공 방식이 다르고 protocol consensus 데이터의 독립 transaction 목록과 같지는 않습니다.
외부 거래 하나가 호출 트리를 만듭니다
Ethereum transaction은 private key로 서명한 EOA가 시작하며 from, to, nonce, value, input, gas를 가집니다. to가 contract면 실행 중 다른 contract를 부르고 ETH를 보내거나 새 contract를 만들 수 있습니다. 탐색기는 이 중첩 실행을 ‘internal transactions’ 탭에 펼쳐 보여 줍니다.
내부 항목에는 원 거래와 별개인 사용자 signature나 account nonce가 없습니다. 그래서 내부 거래 hash처럼 보이는 식별자가 있어도 consensus transaction hash로 송금 증명을 대신할 수 없습니다. 항상 부모 TxID와 call path를 함께 기록합니다.
내부 거래는 새 봉투가 아니라, 한 거래 안에서 계약들이 서로 넘긴 호출을 탐색기가 펼쳐 본 실행 경로입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 외부 거래 하나가 호출 트리를 만듭니다
Ethereum transaction은 private key로 서명한 EOA가 시작하며 from, to, nonce, value, input, gas를 가집니다.
- CALL과 DELEGATECALL은 맥락이 다릅니다
CALL은 다른 address의 code를 그 주소의 storage 맥락에서 실행하고 value를 전달할 수 있습니다.
- 실패한 내부 호출과 최종 결과를 나눕니다
내부 call이 실패해도 상위 contract가 error를 처리하면 최상위 transaction은 성공할 수 있습니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
CALL과 DELEGATECALL은 맥락이 다릅니다
CALL은 다른 address의 code를 그 주소의 storage 맥락에서 실행하고 value를 전달할 수 있습니다. DELEGATECALL은 다른 implementation code를 현재 caller의 storage·address 맥락에서 실행합니다. 프록시가 implementation에 delegate할 때 trace의 code address와 상태가 귀속되는 proxy를 혼동하면 안 됩니다.
CREATE·CREATE2는 실행 중 새 contract를 만들고 STATICCALL은 상태 변경을 허용하지 않는 읽기 호출입니다. call type을 보지 않고 from·to 목록만 읽으면 자산 소유자나 실제 실행 주체를 잘못 해석할 수 있습니다. value가 0인 호출도 token state를 바꿀 수 있습니다.
| 유형 | 핵심 의미 | 확인점 |
|---|---|---|
| CALL | 다른 계약 호출·value 가능 | callee success·value |
| DELEGATECALL | caller 맥락에서 외부 code | proxy storage |
| STATICCALL | 상태 변경 없는 호출 | 조회 결과 |
| CREATE | 새 contract 배포 | 생성 주소·code |
| SELFDESTRUCT 관련 | 특정 value 이동 가능 | 현재 EVM 규칙 확인 |
실패한 내부 호출과 최종 결과를 나눕니다
내부 call이 실패해도 상위 contract가 error를 처리하면 최상위 transaction은 성공할 수 있습니다. 반대로 내부 호출들이 성공한 듯 보여도 이후 상위 frame이 revert하면 전체 상태와 value 이동이 롤백됩니다. trace의 각 success flag와 최종 receipt status를 함께 봅니다.
Ethereum REVERT 규칙은 실행 상태 변경과 logs를 되돌립니다. 디버그 trace는 폐기된 호출 단계도 분석용으로 보여 줄 수 있으므로 표시된 value가 최종 balance에 반영됐다고 바로 결론 내리지 않습니다. 해당 block 전후 잔액과 state diff를 확인합니다.
- 부모 transaction hash와 receipt를 확인합니다.
- call tree 깊이와 type을 봅니다.
- 각 frame의 from·to·value·success를 읽습니다.
- delegatecall이면 storage 맥락을 확인합니다.
- 최종 balance·logs·state diff를 대조합니다.
Trace는 노드가 실행을 재현해 만듭니다
Geth 문서는 EVM tracing이 transaction이 실행한 opcode마다 contextual metadata를 담은 structured log를 만들 수 있다고 설명합니다. trace는 분석·디버깅에 강력하지만 모든 RPC provider가 같은 method와 보존 기간을 제공하지는 않습니다. archive 접근이나 custom tracer가 필요할 수 있습니다.
ethereum.org data 문서도 raw data를 transactions, logs, traces 등으로 구분합니다. 탐색기마다 internal transaction 포함 기준과 라벨이 달라 두 서비스 화면이 다를 수 있습니다. 차이는 chain 오류가 아니라 indexer·tracer 구현 차이일 가능성도 조사합니다.
세금·입금 기록에는 부모 관계를 보존합니다
contract에서 받은 ETH가 internal transfer로 보이면 경제적 입출금에는 중요하지만 독립적으로 사용자가 서명한 거래라고 쓰지 않습니다. 회계 시스템은 parent TxID, trace address, value, counterparty contract, block을 함께 저장해야 중복 집계를 피할 수 있습니다.
토큰 이동은 보통 event logs로 잡히며 native value trace와 자료원이 다릅니다. 한 swap에서 외부 transaction, 여러 token events, 내부 ETH calls를 각각 합산하면 같은 경제 행위를 중복 계산할 수 있습니다. protocol 의미와 실제 balance 변화를 기준으로 묶습니다.
자주 묻는 질문
내부 거래마다 별도 TxID가 있나요?
보통 없습니다. 부모 transaction 안의 call trace이며 자체 서명·nonce를 가진 별도 거래가 아닙니다.
내부 호출이 실패하면 전체 거래도 실패하나요?
상위 contract가 실패를 처리하면 전체는 성공할 수 있습니다. 최종 receipt와 call tree를 함께 확인하세요.
internal transfer가 보이면 ETH 잔액도 반드시 변했나요?
상위 revert로 롤백될 수 있으므로 frame success와 최종 balance·state diff를 확인해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
