---
title: "지갑의 Calldata 해독"
description: "트랜잭션 호출 데이터, ABI 워드와 오프셋, 선택자 충돌, 프록시, 배치, 승인, 형식화 데이터 permit, 시뮬레이션과 사후 대사를 검증 우선 관점에서 설명합니다."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 지갑의 Calldata 해독
> 교육 참고용이며 투자, 법률 또는 보안 조언이 아닙니다. 해독과 시뮬레이션은 모호성을 줄이지만 권한 부여, 실행, 자산 안전 또는 완결성을 보장하지 않습니다.
## 핵심 답변
Calldata는 이더리움 최상위 트랜잭션이나 내부 메시지 호출에 입력으로 전달되는 불변 바이트열입니다. 일반적인 Solidity 함수 호출은 `4-byte` 선택자로 시작하고 ABI 인코딩 인수가 뒤따릅니다. 그러나 calldata는 자기 서술 형식이 아닙니다. 런타임 코드, 프록시 구현 또는 스키마가 다르면 같은 바이트도 다른 의미를 가질 수 있습니다. 폴백 함수, 저수준 어셈블리 및 Solidity 이외의 프로토콜은 일반 함수 ABI를 따르지 않아도 됩니다.
따라서 지갑은 후보 함수명보다 더 많은 정보를 보여 줘야 합니다. 안전한 검토는 바이트를 `chainId`, 특정 블록, `from`, `to`, 네이티브 자산 `value`, 런타임 `codeHash`, 활성 구현 컨트랙트 및 신뢰할 수 있는 ABI에 연결합니다. 모든 중첩 호출을 엄격히 해독하고, 온체인 calldata와 EIP-712 서명을 구분하며, 명시된 상태에서 시뮬레이션한 뒤 블록 포함 후 실제 영수증과 상태 변경을 대사해야 합니다.
## 작동 원리
1. 서명 대상 엔벌로프와 관찰 시점을 고정합니다. `chainId`, 블록 번호와 해시, `from`, `to`, 네이티브 자산 `value`, 입력 바이트, nonce 및 수수료 필드를 기록합니다. 지갑 또는 RPC 출처도 보존합니다. 다른 체인이나 블록에서 해독한 페이로드는 동일한 판단 대상이 아닙니다.
2. 해독하기 전에 객체 유형을 분류합니다. 트랜잭션, EIP-712 형식화 데이터 요청, ERC-2612 permit, ERC-4337 UserOperation 및 원시 personal-sign 메시지는 서로 다른 도메인과 스키마를 사용합니다. 모두를 트랜잭션 ABI로 억지로 해석하면 안 됩니다.
3. 고정한 블록에서 대상을 확인합니다. 런타임 바이트코드와 `codeHash` 를 읽고, 해당하면 프록시, 비콘 또는 구현 컨트랙트를 식별하며, 구현 및 관리자 스토리지 슬롯을 기록합니다. 그 정확한 코드 버전과 일치하는 ABI를 확보합니다. 선택자 레지스트리는 후보만 제공할 뿐 권위 있는 근거가 아닙니다.
4. 엄격히 해독합니다. 선택자는 반환형을 제외한 정규 함수 시그니처를 Keccak-256으로 해시한 앞쪽 `4 bytes` 입니다. 정적 값은 `32-byte` 워드를 차지하고, 동적 인수의 헤드에는 선택자 뒤 인수 블록 시작점을 기준으로 한 오프셋이 들어갑니다. 잘린 데이터, 범위를 벗어난 오프셋, 성립할 수 없는 길이, 잘못된 패딩 또는 설명되지 않는 후행 바이트는 거부합니다.
5. multicall, 중첩 calldata 및 위임 실행을 재귀적으로 펼칩니다. 각 하위 호출의 대상, 네이티브 자산 가치, 선택자, 인수, 호출 유형과 `allowFailure` 플래그를 나열합니다. `delegatecall` 을 사용하면 구현 코드는 호출자 주소, 잔액 및 스토리지 맥락에서 실행되고 `msg.sender` 와 `msg.value` 는 유지됩니다.
6. 권한 원장과 가치 원장을 분리해 만든 다음 시뮬레이션합니다. 수취인, spender, NFT 운영자, 토큰 원시 단위, decimals, 기한, 슬리피지 경계 및 네이티브 자산 가치를 기록합니다. 정확한 블록, 발신자와 value를 사용해 시뮬레이션하되 상태, 가격, 시간, 코드 및 트랜잭션 순서가 달라질 수 있으므로 결과는 조건부 스냅샷으로 취급합니다.
7. 서명 전에 중요한 필드를 모두 확인합니다. 블록 포함 후 영수증 상태, 로그, 이용 가능한 트레이스와 잔액, allowance 및 운영자 상태의 변화를 검사합니다. 포착된 하위 호출 실패와 최상위 성공을 구분하고, 리버트된 경우에도 gas를 반영하며, 필요한 완결성을 기다립니다. 설명할 수 없는 실패가 발생하면 무작정 다시 서명하지 말고 중단합니다.
## 계산 예시
- **정적 ERC-20 전송.** `transfer(address,uint256)` 은 일반적으로 선택자 `0xa9059cbb` 를 사용합니다. 선택자 하나와 ABI 워드 두 개는 `4 + 2 * 32 = 68 bytes` 입니다. 원시 수량 `1,500,000` 은 별도로 검증한 해당 토큰이 `6 decimals` 를 사용할 경우 `1.5 tokens` 로 표시됩니다. decimals는 외부 컨트랙트 메타데이터이며 이 인수들에 인코딩되지 않습니다. 선택자만으로 컨트랙트나 함수를 고유하게 식별할 수도 없습니다.
- **동적 bytes 오프셋.** `f(address,bytes)` 에서 페이로드가 `3-byte` 라면 두 워드짜리 헤드는 `64 bytes` 를 차지합니다. 동적 오프셋은 `0x40` 이며 선택자를 제외한 인수 블록 시작점부터 측정합니다. 테일에는 `32-byte` 길이 워드 하나와 `32-byte` 로 패딩된 데이터 워드 하나가 들어가므로 전체 calldata는 `4 + 64 + 32 + 32 = 132 bytes` 입니다. 오프셋을 0번 바이트부터의 절대 위치로 해석하면 네 바이트 뒤로 어긋납니다.
- **배치의 value 처리는 구현에 따라 다릅니다.** 외부 호출에 `1.00 ETH` 가 실리고, 해독한 세 하위 호출이 `0.20 ETH`, `0.30 ETH`, `0.10 ETH`, 합계 `0.60 ETH` 를 명시적으로 요청한다고 가정합니다. 남은 `0.40 ETH` 는 배치 코드에 따라 환불, 보유, 재전송되거나 리버트를 유발할 수 있습니다. 세 번째 하위 호출이 `allowFailure=true` 로 실패하면 앞선 호출은 확정될 수 있습니다. 원자적 구현이라면 모두 리버트될 수 있습니다.
- **permit은 서명 시점의 릴레이어 calldata가 아닙니다.** `1,000 USDC` 를 보유한 소유자가 `300 USDC`, nonce `41` 인 ERC-2612 permit에 서명합니다. 서명만으로는 잔액이나 allowance가 바뀌지 않습니다. 릴레이어가 성공적으로 제출하면 nonce는 `42`, allowance는 `300` 이 됩니다. 이후 spender가 `180` 을 사용하면 잔액은 `820`, 남은 allowance는 `120` 입니다. 사이트 연결을 끊어도 이 권한은 취소되지 않습니다.
## 위험
- 잘못된 체인, 포크, 블록 태그 또는 트랜잭션 엔벌로프를 기준으로 해독합니다.
- 위조된 도메인, 대상 주소 또는 수취인에 서명합니다.
- 충돌 가능성이 있는데도 `4-byte` 선택자를 고유 식별자로 간주합니다.
- 추측한 ABI, 오래된 ABI 또는 올바르게 검증되지 않은 ABI를 사용합니다.
- 검증된 소스라는 표시는 믿으면서 현재 런타임 `codeHash` 와 일치하는지 확인하지 않습니다.
- 검토와 실행 사이에 일어난 구현, 비콘 또는 관리자 업그레이드를 놓칩니다.
- 프록시 함수와 구현 함수 사이의 선택자 충돌을 무시합니다.
- `delegatecall` 이 호출자의 스토리지 맥락에 상태를 기록한다는 점을 잊습니다.
- 잘못된 동적 오프셋, 길이, 패딩 또는 후행 바이트를 받아들입니다.
- 대상, 가치 또는 권한을 숨기는 중첩 배치를 펼치지 않습니다.
- 구현이 하위 호출 실패를 포착하거나 허용하는데도 원자성을 가정합니다.
- 토큰 인수가 무해해 보여 최상위 네이티브 `value` 를 무시합니다.
- decimals를 잘못 적용하거나 전송 수수료형 및 리베이스 토큰을 표준 ERC-20으로 간주합니다.
- 무제한 ERC-20 allowance를 부여하거나 allowance 갱신 경합을 잘못 처리합니다.
- NFT `setApprovalForAll` 이 컬렉션 전체에 미치는 권한 범위를 간과합니다.
- EIP-712 형식화 데이터나 ERC-2612 permit을 트랜잭션 calldata로 오인합니다.
- nonce, 기한, 검증 컨트랙트, 체인 도메인 또는 재사용 방지 경계를 놓칩니다.
- 오라클, 타임스탬프, 대기 상태, MEV 또는 코드가 변할 수 있는데 시뮬레이션을 고정된 결과로 여깁니다.
- 영수증 상태, 로그 또는 제공업체 트레이스를 완전한 경제 상태 증명으로 간주합니다.
- 침해된 UI를 통해 무작정 다시 서명하거나 블록 포함, 리오그 및 완결성 위험을 무시합니다.
## 흔한 오해
- 함수 선택자만으로 컨트랙트가 실행할 작업을 고유하게 식별할 수 있습니다.
- 검증된 프런트엔드 요약은 서명할 바이트와 현재 구현에 완전히 일치합니다.
- `value=0` 인 트랜잭션은 토큰, NFT 또는 위임된 자산을 옮길 수 없습니다.
- 시뮬레이션 성공이나 성공 영수증은 안전성과 의도한 경제적 결과를 증명합니다.
- dapp 연결을 끊으면 승인, permit 및 NFT 운영자 권한이 취소됩니다.
## 관련 주제
- [트랜잭션 시뮬레이션](/ko/crypto/transaction-simulation/)
- [지갑 승인](/ko/crypto/wallet-approval/)
- [지갑 서명](/ko/crypto/wallet-signature/)
## 출처
- [Contract ABI Specification](https://docs.soliditylang.org/en/latest/abi-spec.html) - Solidity Documentation (확인일: 2026-08-12)
- [Introduction to Smart Contracts](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#delegatecall-and-libraries) - Solidity Documentation (확인일: 2026-08-12)
- [Transactions](https://ethereum.org/developers/docs/transactions/) - Ethereum.org (확인일: 2026-08-12)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (확인일: 2026-08-12)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (확인일: 2026-08-12)
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (확인일: 2026-08-12)
- [ERC-721: Non-Fungible Token Standard](https://eips.ethereum.org/EIPS/eip-721) - Ethereum Improvement Proposals (확인일: 2026-08-12)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (확인일: 2026-08-12)
Source: https://wiki.fcontext.com/ko/crypto/calldata-decoding-wallet/index.mdx