본문으로 이동
Financial Context Wiki

지갑의 Calldata 해독

트랜잭션 호출 데이터, ABI 워드와 오프셋, 선택자 충돌, 프록시, 배치, 승인, 형식화 데이터 permit, 시뮬레이션과 사후 대사를 검증 우선 관점에서 설명합니다.

업데이트

교육 참고용이며 투자, 법률 또는 보안 조언이 아닙니다. 해독과 시뮬레이션은 모호성을 줄이지만 권한 부여, 실행, 자산 안전 또는 완결성을 보장하지 않습니다.

핵심 답변

Calldata는 이더리움 최상위 트랜잭션이나 내부 메시지 호출에 입력으로 전달되는 불변 바이트열입니다. 일반적인 Solidity 함수 호출은 4-byte 선택자로 시작하고 ABI 인코딩 인수가 뒤따릅니다. 그러나 calldata는 자기 서술 형식이 아닙니다. 런타임 코드, 프록시 구현 또는 스키마가 다르면 같은 바이트도 다른 의미를 가질 수 있습니다. 폴백 함수, 저수준 어셈블리 및 Solidity 이외의 프로토콜은 일반 함수 ABI를 따르지 않아도 됩니다.

따라서 지갑은 후보 함수명보다 더 많은 정보를 보여 줘야 합니다. 안전한 검토는 바이트를 chainId, 특정 블록, from, to, 네이티브 자산 value, 런타임 codeHash, 활성 구현 컨트랙트 및 신뢰할 수 있는 ABI에 연결합니다. 모든 중첩 호출을 엄격히 해독하고, 온체인 calldata와 EIP-712 서명을 구분하며, 명시된 상태에서 시뮬레이션한 뒤 블록 포함 후 실제 영수증과 상태 변경을 대사해야 합니다.

Calldata 해독
0 / 5
0 개 항목 검토; 5 개 항목 미해결

모든 항목을 검토해도 자산, 거래 또는 시스템의 안전이 입증되는 것은 아닙니다.

작동 원리

  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 운영자 권한이 취소됩니다.

관련 주제

출처

탐색

위키 검색...