EVM 거래의 입력 데이터(input data)는 계약에 건네는 호출 데이터(calldata)입니다. 일반적인 ABI 호출이라면 처음 4바이트가 함수 시그니처에서 뽑은 선택자(selector)이고, 나머지는 32바이트 단위로 인코딩된 인수입니다. 검증된 계약 ABI가 있으면 탐색기가 함수 이름과 주소·금액을 풀어서 보여 줄 수 있습니다. 하지만 선택자만으로는 충돌할 수 있고, 프록시·미검증 바이트코드·동적 인수에서는 해석이 틀릴 수 있습니다. 그래서 받는 주소(to)와 현재 구현 계약, 소스를 함께 확인해야 합니다.
입력 데이터는 계약 호출의 지시문입니다
ethereum.org는 거래의 입력 데이터가 임의의 데이터를 담는 선택 항목이며, Solidity 계약이 ABI 규칙으로 해석한다고 설명합니다. EOA끼리 ETH만 보내는 단순 송금은 보통 데이터가 비어 있습니다. 계약과 상호작용할 때는 함수와 인수가 담깁니다. 계약을 배포할 때는 받는 주소가 없고 데이터에 생성 코드가 들어갑니다.
먼저 체인, 받는 주소, 보낸 금액(value), 보낸 사람을 확인한 다음 입력 데이터를 읽습니다. 같은 바이트라도 계약 코드가 다르면 다르게 처리할 수 있으니 호출 데이터만 떼어 내 해석하지 않습니다. 프록시 주소라면 실제로 실행되는 코드는 현재 구현 계약에 있을 수 있습니다.
입력 데이터는 거래의 동작 설명서입니다. 하지만 그 설명서를 실제로 해석하는 쪽은 목적지 계약의 코드입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 입력 데이터는 계약 호출의 지시문입니다
ethereum.org는 거래의 입력 데이터가 임의의 데이터를 담는 선택 항목이며, Solidity 계약이 ABI 규칙으로 해석한다고 설명합니다.
- 처음 4바이트와 나머지 인수를 나눕니다
함수 선택자는 보통 keccak256('함수명(타입,타입)') 결과의 앞 4바이트입니다.
- approve와 transfer 인수를 실제 단위로 바꿉니다
approve(address spender,uint256 amount)를 풀었다면 승인받는 주소 전체와 원래 금액 값을 봅니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
처음 4바이트와 나머지 인수를 나눕니다
함수 선택자는 보통 keccak256('함수명(타입,타입)') 결과의 앞 4바이트입니다. 예를 들어 0xa9059cbb는 흔히 transfer(address,uint256)로 알려져 있습니다. 뒤따르는 32바이트 단위 칸에는 앞을 0으로 채운 주소와 정수 등이 ABI 규칙에 따라 놓입니다.
ethereum.org 예시는 검증된 소스가 있어 선택자가 transfer임을 확인하고 주소와 금액을 풀어냅니다. 선택자 데이터베이스에는 같은 4바이트에 후보가 여러 개 있을 수 있습니다. 정확한 계약 ABI와 바이트코드가 없다면 ‘가능한 함수’라고만 써야 합니다.
| 구간 | 의미 | 검증 |
|---|---|---|
| 0x 다음 4바이트 | 함수 선택자 | ABI·소스와 대조 |
| 고정 길이 칸 | 주소·부호 없는 정수 등 | 타입·소수점 자릿수 확인 |
| 오프셋 칸 | 동적 데이터 위치 | ABI 기준으로 추적 |
| 받는 주소(to) | 해석하는 계약 | 프록시 여부 확인 |
| 금액(value) 항목 | 함께 보낸 기본 코인 | 호출 데이터와 별개 |
approve와 transfer 인수를 실제 단위로 바꿉니다
approve(address spender,uint256 amount)를 풀었다면 승인받는 주소 전체와 원래 금액 값을 봅니다. 금액은 토큰의 소수점 자릿수를 적용해야 화면 단위가 됩니다. 2^256에 가까운 아주 큰 값은 무제한 승인으로 쓰일 수 있습니다. transfer의 수신자도 거래의 받는 주소와 다릅니다. 받는 주소는 토큰 계약이고, 호출 데이터 안의 주소가 실제 토큰 수신자입니다.
스왑 라우터 호출에는 경로, 수신자, 최소 수령액, 마감 시각이 겹겹이 들어갈 수 있습니다. 멀티콜(multicall)은 안쪽 호출 데이터를 다시 풀어야 합니다. 바깥 함수 이름이 ‘swap’이라는 것만 보고 최종 수신자와 승인을 모두 확인했다고 말해서는 안 됩니다.
- 올바른 체인과 받는 주소를 확인합니다.
- 검증된 소스와 현재 구현 계약을 찾습니다.
- 선택자 후보를 ABI와 대조합니다.
- 주소·금액·마감 시각을 실제 단위로 풉니다.
- 시뮬레이션과 영수증 결과를 서로 맞춰 봅니다.
프록시와 미검증 계약에서는 한계를 적어 둡니다
프록시 자체의 ABI만 보면 구현 계약의 함수가 빠져 있거나 오래된 ABI로 잘못 풀릴 수 있습니다. 탐색기의 ‘as Proxy’ 기능과 ERC-1967 구현 계약을 확인합니다. 업그레이드 직전과 직후에는 같은 프록시와 선택자가 다른 로직을 실행할 수 있으니, 그 블록 시점의 구현이 중요합니다.
소스가 검증되지 않았다면 선택자 이름 서비스의 추정값을 사실로 단정하지 않습니다. 바이트코드를 역컴파일해도 변수 이름과 의도까지 되살리지 못할 수 있습니다. 금액이 큰 거래라면 공식 계약, 감사받은 버전, 실제 시뮬레이션을 확보할 때까지 서명하지 않습니다.
실패와 로그까지 이어서 읽습니다
입력 데이터는 사용자가 요청한 지시이고, 영수증과 로그는 실행 결과의 일부입니다. 거래가 되돌려졌다면(revert) 입력에 transfer가 있어도 토큰 잔액은 바뀌지 않습니다. 반대로 멀티콜 안에서 여러 호출이 일어나면 실행 추적(trace)이 중간 경로를 보여 줍니다. 요청과 결과를 혼동하지 않습니다.
의심스러운 거래를 분석할 때는 TxID, 선택자, 풀어낸 인수, ABI 출처, 구현 계약 블록, 영수증 상태를 기록합니다. 시드나 개인키는 필요하지 않습니다. 탐색기 화면의 해석은 바뀔 수 있으니 원래 입력 데이터를 증거로 보존합니다.
자주 묻는 질문
0xa9059cbb면 항상 ERC-20 transfer인가요?
흔한 후보이지만 4바이트는 충돌할 수 있으므로 목적지 계약의 ABI와 검증된 소스를 확인해야 합니다.
거래의 받는 주소가 토큰을 받은 주소인가요?
ERC-20 transfer에서는 받는 주소가 토큰 계약이고, 실제 수신자는 호출 데이터의 인수에 들어 있습니다.
입력 데이터를 풀면 거래가 안전하다는 게 증명되나요?
아닙니다. 함수의 의도를 이해하는 단서일 뿐이며, 계약 코드·상태·프록시·실행 결과를 함께 봐야 합니다.
