EVM transaction의 input data는 계약에 전달되는 calldata입니다. 일반적인 ABI 호출은 첫 4바이트가 함수 signature의 selector이고 나머지가 32바이트 단위로 인코딩된 arguments입니다. verified contract ABI가 있으면 탐색기가 함수명과 주소·금액을 풀어 보여 줄 수 있지만, selector만으로는 충돌 가능성이 있고 proxy·미검증 bytecode·동적 인수에서는 해석이 틀릴 수 있으므로 to 주소와 현재 implementation, source를 함께 확인해야 합니다.
Input Data는 계약 호출의 지시문입니다
ethereum.org는 transaction의 input data가 임의 데이터를 담는 선택 필드이며 Solidity contract가 ABI 규칙으로 해석한다고 설명합니다. 단순 EOA ETH 송금은 보통 data가 비어 있지만 contract interaction은 함수와 arguments를 담습니다. contract deployment는 to가 없고 data에 생성 code가 들어갑니다.
먼저 chain, to, value, sender를 확인한 뒤 input을 읽습니다. 같은 bytes라도 다른 contract code가 다르게 처리할 수 있으므로 calldata만 떼어 해석하지 않습니다. proxy address라면 실행 code는 현재 implementation에 있을 수 있습니다.
Input Data는 거래의 동작 설명서지만, 그 설명서를 실제로 해석하는 주체는 목적지 계약 코드입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- Input Data는 계약 호출의 지시문입니다
ethereum.org는 transaction의 input data가 임의 데이터를 담는 선택 필드이며 Solidity contract가 ABI 규칙으로 해석한다고 설명합니다.
- 첫 4바이트와 나머지 인수를 나눕니다
함수 selector는 보통 keccak256('함수명(타입,타입)')의 앞 4바이트입니다.
- approve와 transfer 인수를 실제 단위로 바꿉니다
approve(address spender,uint256 amount)를 decode했다면 spender 전체 주소와 raw amount를 봅니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
첫 4바이트와 나머지 인수를 나눕니다
함수 selector는 보통 keccak256('함수명(타입,타입)')의 앞 4바이트입니다. 예를 들어 0xa9059cbb는 흔히 transfer(address,uint256)로 알려져 있습니다. 이어지는 32바이트 words에는 앞을 0으로 채운 address와 integer 등이 ABI 규칙으로 놓입니다.
ethereum.org 예시는 verified source가 있어 selector를 transfer로 확인하고 주소와 value를 decode합니다. selector 데이터베이스에는 같은 4바이트 후보가 여러 개 있을 수 있습니다. 정확한 contract ABI와 bytecode가 없으면 ‘가능한 함수’로만 표현해야 합니다.
| 구간 | 의미 | 검증 |
|---|---|---|
| 0x 이후 4바이트 | function selector | ABI·source와 대조 |
| 고정형 word | address·uint 등 | 타입·decimals 확인 |
| offset word | 동적 데이터 위치 | ABI 기준 추적 |
| to address | 해석 contract | proxy 여부 확인 |
| value field | 함께 보낸 native coin | calldata와 별도 |
approve와 transfer 인수를 실제 단위로 바꿉니다
approve(address spender,uint256 amount)를 decode했다면 spender 전체 주소와 raw amount를 봅니다. amount는 token decimals를 적용해야 화면 단위가 되며 2^256에 가까운 큰 값은 unlimited allowance로 쓰일 수 있습니다. transfer의 recipient도 transaction의 to와 다릅니다. to는 token contract, calldata 안 주소가 실제 token 수신자입니다.
swap router 호출은 path, recipient, minimum output, deadline이 중첩될 수 있습니다. multicall은 내부 calldata를 다시 decode해야 합니다. 바깥 함수명만 ‘swap’이라고 보고 모든 최종 수신자와 approval을 확인했다고 말하면 안 됩니다.
- 올바른 chain과 to address를 확인합니다.
- verified source와 현재 implementation을 찾습니다.
- selector 후보를 ABI와 대조합니다.
- 주소·금액·deadline을 실제 단위로 풉니다.
- simulation과 receipt 결과를 교차 확인합니다.
프록시와 미검증 계약에서는 한계를 적습니다
proxy 자체 ABI만 보면 implementation의 함수가 없거나 오래된 ABI로 decode될 수 있습니다. explorer의 ‘as Proxy’ 기능과 ERC-1967 implementation을 확인합니다. upgrade 직전·직후에는 같은 proxy와 selector가 다른 logic을 실행할 수 있어 block 시점 구현이 중요합니다.
source가 verified되지 않았다면 selector 이름 서비스의 추정값을 사실로 단정하지 않습니다. bytecode decompile도 변수명과 의도를 복원하지 못할 수 있습니다. 고가 거래는 공식 contract, audit 버전, 실제 simulation을 확보할 때까지 서명하지 않습니다.
실패와 로그까지 연결해 읽습니다
input은 사용자가 요청한 지시이고 receipt와 logs는 실행 결과의 일부입니다. 거래가 revert했다면 input에 transfer가 있어도 token balance는 바뀌지 않습니다. 반대로 multicall 내부에서 여러 호출이 발생하면 traces가 중간 경로를 보여 줍니다. 요청과 결과를 혼동하지 않습니다.
의심 거래를 분석할 때 TxID, selector, decoded arguments, ABI 출처, implementation block, receipt status를 기록합니다. 시드나 private key는 필요하지 않습니다. 탐색기 UI의 해석이 달라질 수 있으므로 raw input을 증거로 보존합니다.
자주 묻는 질문
0xa9059cbb면 항상 ERC-20 transfer인가요?
흔한 후보지만 4바이트 충돌이 가능하므로 목적지 contract ABI와 verified source를 확인해야 합니다.
transaction to가 토큰을 받은 주소인가요?
ERC-20 transfer에서는 to가 token contract이고 실제 recipient는 calldata 인수에 들어갑니다.
Input Data를 decode하면 거래 안전성이 증명되나요?
아닙니다. 함수 의도를 이해하는 단서이며 contract 코드·상태·프록시·실행 결과를 함께 봐야 합니다.
