이더리움 콜데이터 완전 정리: 트랜잭션 입력 데이터 해석법

지갑에서 컨트랙트 상호작용을 승인하려는데 입력 데이터가 끝없는 16진수처럼 보여 불안하셨나요? 이 문자열은 무작위 값이 아닙니다. 스마트 컨트랙트에 어떤 함수를 어떤 값으로 실행할지 전달하는 **콜데이터(Calldata)**예요. 모든 바이트를 손으로 풀지 않더라도 구조를 알면 블록체인 기초를 실제 서명 안전과 연결할 수 있습니다.

이 글에서는 Solidity ABI 표준 구조, 익스플로러의 해석 방식과 한계, 서명 전 확인 항목을 설명해요. 이더리움과 EVM 호환 체인을 기준으로 하며 정확한 해석에는 신뢰할 수 있는 인터페이스와 체인 맥락이 필요합니다.

이더리움 콜데이터란 무엇인가요?

이더리움 트랜잭션에는 목적지(to), ETH 수량(value), 수수료 설정, 논스(Nonce), 선택적인 입력 데이터(input data)가 들어갑니다. 목적지가 스마트 컨트랙트라면 입력에는 보통 애플리케이션 바이너리 인터페이스(ABI)에 따라 인코딩된 콜데이터가 담겨요.

식당 주문표를 떠올려 보세요. 첫 줄에는 메뉴, 나머지에는 크기와 옵션이 적힙니다. 주방은 주문표 형식과 메뉴판을 모두 알아야 뜻을 이해하죠. 이더리움 가상 머신(EVM)은 바이트를 받고, ABI는 자료형에 맞게 읽는 메뉴판 역할을 합니다.

콜데이터는 외부 호출 중 읽기 전용 입력입니다. 블록체인 상태에 남는 스토리지(Storage), 실행 중에만 쓰는 메모리(Memory)와 달라요. 단순 ETH 전송은 입력이 비어 있을 수 있습니다. 컨트랙트 배포에서는 기존 함수를 부르는 대신 생성 코드와 생성자 인자가 데이터 필드에 들어갑니다.

컨트랙트 호출은 어떻게 인코딩되나요?

일반적인 Solidity 호출은 다음 두 부분으로 나뉩니다.

0x | 4바이트 함수 셀렉터 | ABI로 인코딩된 인자

Solidity ABI 명세에서 함수 셀렉터(Function Selector)는 정규 함수 시그니처를 Keccak-256으로 해시한 값의 앞 4바이트입니다. 시그니처에는 함수 이름과 매개변수 자료형이 들어가며 공백과 반환형은 제외해요. transfer(address,uint256)의 널리 알려진 셀렉터는 0xa9059cbb입니다.

그 뒤는 인자예요. ABI 값은 보통 32바이트 워드 단위로 배치됩니다. 고정 길이 값에는 패딩이 붙고 문자열이나 가변 배열은 뒤쪽 데이터 위치를 가리키는 오프셋(Offset)을 사용해요.

셀렉터만으로 함수를 확정할 수 없는 이유

4바이트 조합은 한정되어 있어 서로 다른 함수 시그니처가 같은 셀렉터를 가질 수 있습니다. 공개 데이터베이스는 후보를 제시할 뿐, 배포된 컨트랙트의 인터페이스를 증명하지 못해요.

ABI 인코딩도 스스로 자료형을 설명하지 않습니다. 원시 바이트에는 “주소”나 “배열 오프셋”이라는 신뢰할 만한 라벨이 없어요. 정확한 체인과 주소에 연결된 ABI, 가능하면 검증된 소스 코드가 필요합니다.

안전하게 해석하는 순서

1. 체인과 목적지를 확인해요

먼저 네트워크와 to 주소를 봅니다. 같은 화면이 다른 체인에 연결될 수 있고 악성 주소가 정상 서비스를 흉내 낼 수도 있어요. 검색 광고나 DM이 아니라 프로젝트 공식 문서에서 주소를 확인하세요.

2. 검증된 소스와 프록시를 확인해요

신뢰할 수 있는 익스플로러는 검증된 소스와 ABI를 공개할 수 있습니다. 주소가 프록시(Proxy)라면 실행이 구현 컨트랙트에 위임될 수 있어요. 현재 구현 주소를 올바르게 식별하는지 확인해야 합니다.

3. 셀렉터를 ABI와 대조해요

앞 4바이트를 검증된 ABI의 함수와 비교합니다. 셀렉터 데이터베이스는 힌트로만 쓰세요. 컨트랙트 주소와 검증된 구현이 라벨 하나보다 강한 근거입니다.

4. 인자와 단위를 확인해요

선언된 자료형에 따라 값을 해석합니다. 토큰 수량은 최소 단위의 정수인 경우가 많아 사람에게 보이는 수량은 decimals에 따라 달라져요. 수신자, 승인 대상(Spender), 승인량, 최소 수령량, 기한, 토큰 ID, 배열 값도 살펴보세요.

5. 내 의도와 비교해요

“내가 하려던 행동만 정확히 승인하는가?”라고 물어보세요. 함수 이름만으로는 부족합니다. approve라면 토큰, 승인 대상, 한도를 함께 봐야 해요.

콜데이터·가스·로그·블롭의 차이

노드가 트랜잭션 바이트를 전파하고 처리하므로 콜데이터도 가스에 영향을 줍니다. 가격 규칙은 EIP-2028, EIP-7623 같은 업그레이드로 바뀌어 왔어요. 고정된 바이트당 비용을 가정하지 말고 최신 추정기를 사용하세요. 함수가 스토리지를 쓰거나 외부 호출을 하면 실행 비용이 더 커질 수 있습니다. 가스비 가이드에서 자세히 설명해요.

리스크와 한계

사람이 읽는 라벨도 틀릴 수 있어요

지갑과 익스플로러의 디코더는 메타데이터에 의존합니다. 검증되지 않은 ABI, 오래된 프록시 구현, 셀렉터 충돌, 악성 토큰 정보가 그럴듯하지만 잘못된 라벨을 만들 수 있어요. 디코딩은 가시성을 높일 뿐 신뢰성을 보장하지 않습니다.

콜데이터는 공개됩니다

트랜잭션 입력에 비밀을 넣으면 안 됩니다. 브로드캐스트된 콜데이터는 네트워크 참여자가 볼 수 있고 블록에 포함되면 공개 기록이 돼요. 16진수 표시는 암호화가 아닙니다.

시뮬레이션은 보장이 아니에요

지갑 시뮬레이션은 특정 시점 상태를 기준으로 효과를 추정합니다. 포함 전 상태가 바뀌거나 컨트랙트가 다른 경로로 실행될 수 있어요. 보조 확인 수단으로만 사용하세요.

해석된 호출도 위험할 수 있어요

정확히 해석된 호출도 무제한 승인, NFT 전송, 지갑 권한 변경, 약한 슬리피지 조건의 스왑일 수 있습니다. 위험은 가독성뿐 아니라 값과 컨트랙트 동작에 있어요. 클리어 사이닝과 블라인드 사이닝도 확인해 보세요.

서명 전 체크리스트

• 체인, 계정, 목적지를 확인했나요?
• 공식 자료에서 주소를 확인했나요?
• 검증된 소스, ABI, 프록시 구현을 확인했나요?
• 보안에 중요한 인자를 모두 읽었나요?
• 올바른 decimals로 토큰 수량을 변환했나요?
• 승인 대상, 수신자, 기한, 최소 수령량, 한도를 확인했나요?
• 시뮬레이션이 의도한 자산 변화와 맞나요?
• 설명되지 않는 입력과 재촉을 거절했나요?

FAQ

ABI 없이 해석할 수 있나요?

셀렉터와 32바이트 워드를 나눠 볼 수는 있지만 자료형의 신뢰성 있는 해석에는 정확한 인터페이스가 필요합니다. 패턴 추측은 증명이 아니에요.

서명 뒤 콜데이터가 바뀔 수 있나요?

서명된 필드를 바꾸면 서명이 무효가 됩니다. 다만 웹사이트가 서명 전 맥락을 오해하게 만들 수 있고 실행 결과는 변하는 상태에 의존할 수 있어요. 지갑의 최종 확인 화면을 검증하세요.

토큰 수량이 너무 크게 보이는 이유는 무엇인가요?

ABI에는 정수가 담깁니다. 지갑은 토큰의 decimals로 소수 수량을 표시해요. 토큰 주소와 소수점 자릿수를 함께 확인하세요.

빈 콜데이터는 안전한가요?

아닙니다. 목적지, 수량, 체인, 계정은 여전히 중요해요. receive나 fallback 로직이 있는 컨트랙트로 ETH를 보내면 코드가 실행될 수도 있습니다.

1차 출처

• Ethereum.org: 트랜잭션과 데이터 필드
• Solidity: Contract ABI Specification
• Solidity: Layout of Calldata
• EIP-2028
• EIP-7623

명령을 읽고 컨트랙트를 판단하세요

콜데이터는 화면의 버튼과 EVM이 실행하는 함수를 연결합니다. 체인과 주소, 신뢰할 수 있는 ABI, 셀렉터, 인자, 단위, 예상 결과 순서로 읽어 보세요. 디코딩이 버그나 피싱을 없애지는 않지만 내 의도와 비교할 근거를 줍니다.

이 글은 교육 목적이며 투자 조언이 아닙니다. 스마트 컨트랙트 트랜잭션은 되돌릴 수 없고 전액 손실로 이어질 수 있어요. 낯선 작업은 잃어도 되는 소액으로 시험하고 최신 1차 문서를 확인하며 스스로 조사하세요(DYOR).