탐색기의 ‘내부 거래(internal transaction)’는 대개 따로 서명된 이더리움 거래가 아닙니다. 외부 거래 하나가 실행되는 동안 계약이 CALL·DELEGATECALL·CREATE 등으로 만든 내부 호출을 추적(trace)해 보여 주는 표시입니다. 자체 거래 해시와 논스를 가진 새 거래가 아니며, 원래 거래의 성공·실패 상태를 그대로 따라갑니다. 금액 이동과 호출 경로를 이해하는 데는 쓸모가 있지만, 탐색기마다 보여 주는 방식이 다르고 프로토콜 합의 데이터에 담긴 독립 거래 목록과도 같지 않습니다.
외부 거래 하나가 호출 트리를 만듭니다
이더리움 거래는 개인키로 서명한 외부 소유 계정(EOA)이 시작하며 보내는 주소, 받는 주소, 논스, 금액, 입력 데이터, 가스를 담습니다. 받는 쪽이 계약이면 실행 도중 다른 계약을 부르고, ETH를 보내거나 새 계약을 만들 수 있습니다. 탐색기는 이렇게 겹겹이 이어진 실행을 ‘내부 거래’ 탭에 펼쳐 보여 줍니다.
내부 항목에는 원래 거래와 별개인 사용자 서명이나 계정 논스가 없습니다. 그래서 내부 거래 해시처럼 보이는 식별자가 있어도, 합의 계층의 거래 해시처럼 송금 증명으로 쓸 수는 없습니다. 언제나 부모 거래 ID와 호출 경로를 함께 기록합니다.
내부 거래는 새 봉투가 아니라, 한 거래 안에서 계약들이 서로 넘긴 호출을 탐색기가 펼쳐 본 실행 경로입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 외부 거래 하나가 호출 트리를 만듭니다
이더리움 거래는 개인키로 서명한 외부 소유 계정(EOA)이 시작하며 보내는 주소, 받는 주소, 논스, 금액, 입력 데이터, 가스를 담습니다.
- CALL과 DELEGATECALL은 맥락이 다릅니다
CALL은 다른 주소의 코드를 그 주소의 저장소 맥락에서 실행하며 금액을 함께 보낼 수 있습니다.
- 실패한 내부 호출과 최종 결과를 나눕니다
내부 호출이 실패해도 상위 계약이 오류를 처리하면 최상위 거래는 성공할 수 있습니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
CALL과 DELEGATECALL은 맥락이 다릅니다
CALL은 다른 주소의 코드를 그 주소의 저장소 맥락에서 실행하며 금액을 함께 보낼 수 있습니다. DELEGATECALL은 다른 구현 계약의 코드를 현재 호출자의 저장소·주소 맥락에서 실행합니다. 프록시가 구현 계약에 실행을 위임할 때, 추적 결과의 코드 주소와 상태가 실제로 쌓이는 프록시를 헷갈리면 안 됩니다.
CREATE·CREATE2는 실행 중 새 계약을 만들고, STATICCALL은 상태 변경을 허용하지 않는 읽기 호출입니다. 호출 유형을 보지 않고 보내는 주소와 받는 주소 목록만 읽으면 자산 소유자나 실제 실행 주체를 잘못 해석할 수 있습니다. 금액이 0인 호출도 토큰 상태를 바꿀 수 있습니다.
| 유형 | 핵심 의미 | 확인점 |
|---|---|---|
| CALL | 다른 계약 호출, 금액 전달 가능 | 호출 대상 성공 여부·금액 |
| DELEGATECALL | 호출자 맥락에서 외부 코드 실행 | 프록시 저장소 |
| STATICCALL | 상태 변경 없는 호출 | 조회 결과 |
| CREATE | 새 계약 배포 | 생성 주소·코드 |
| SELFDESTRUCT 관련 | 특정 금액 이동 가능 | 현재 EVM 규칙 확인 |
실패한 내부 호출과 최종 결과를 나눕니다
내부 호출이 실패해도 상위 계약이 오류를 처리하면 최상위 거래는 성공할 수 있습니다. 반대로 내부 호출들이 성공한 것처럼 보여도 그 뒤 상위 프레임이 되돌리기(revert)를 하면 전체 상태와 금액 이동이 롤백됩니다. 추적 결과의 성공 표시 하나하나와 최종 영수증 상태를 함께 봅니다.
이더리움의 REVERT 규칙은 실행 중 바뀐 상태와 로그를 되돌립니다. 디버그 추적은 버려진 호출 단계도 분석용으로 보여 줄 수 있으므로, 화면에 찍힌 금액이 최종 잔액에 반영됐다고 바로 결론 내리지 않습니다. 해당 블록 전후의 잔액과 상태 차이를 확인합니다.
- 부모 거래 해시와 영수증을 확인합니다.
- 호출 트리의 깊이와 유형을 봅니다.
- 프레임마다 보내는 주소·받는 주소·금액·성공 여부를 읽습니다.
- DELEGATECALL이라면 저장소 맥락을 확인합니다.
- 최종 잔액·로그·상태 차이를 맞춰 봅니다.
추적 결과는 노드가 실행을 재현해 만듭니다
Geth 문서에 따르면 EVM 추적은 거래가 실행한 옵코드마다 맥락 정보를 담은 구조화된 로그를 만들 수 있습니다. 추적은 분석과 디버깅에 강력하지만, 모든 RPC 제공자가 같은 메서드와 보존 기간을 제공하지는 않습니다. 아카이브 노드 접근이나 맞춤 추적기가 필요할 수 있습니다.
ethereum.org의 데이터 문서도 원시 데이터를 거래, 로그, 추적 등으로 나눕니다. 탐색기마다 내부 거래를 넣는 기준과 이름표가 달라 두 서비스 화면이 서로 다를 수 있습니다. 이런 차이는 체인 오류가 아니라 인덱서와 추적기 구현 차이일 가능성도 따져 봅니다.
세금·입금 기록에는 부모 관계를 보존합니다
계약에서 받은 ETH가 내부 이체로 보인다면 경제적 입출금으로는 중요하지만, 사용자가 따로 서명한 거래라고 적지 않습니다. 회계 시스템은 부모 거래 ID, 추적 주소, 금액, 상대 계약, 블록을 함께 저장해야 중복 집계를 피할 수 있습니다.
토큰 이동은 보통 이벤트 로그로 잡히며, 기본 자산의 금액 추적과는 자료 출처가 다릅니다. 스왑 한 번에서 외부 거래, 여러 토큰 이벤트, 내부 ETH 호출을 각각 더하면 같은 경제 행위를 여러 번 셀 수 있습니다. 프로토콜상의 의미와 실제 잔액 변화를 기준으로 묶습니다.
자주 묻는 질문
내부 거래마다 별도 거래 ID가 있나요?
보통 없습니다. 부모 거래 안의 호출 추적일 뿐이며, 자체 서명과 논스를 가진 별도 거래가 아닙니다.
내부 호출이 실패하면 전체 거래도 실패하나요?
상위 계약이 실패를 처리하면 전체는 성공할 수 있습니다. 최종 영수증과 호출 트리를 함께 확인하세요.
내부 이체가 보이면 ETH 잔액도 반드시 변했나요?
상위 프레임의 되돌리기로 롤백될 수 있으므로 프레임 성공 여부와 최종 잔액·상태 차이를 확인해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
