---
title: "EIP-712 형식화 서명: 도메인, 다이제스트와 안전한 검증"
description: "EIP-712는 구조화된 Ethereum 메시지를 결정론적으로 표현하고 표시할 수 있게 하지만, 안전한 서명에는 정확한 도메인, 형식, 값, Nonce, 기한, 실행 내용과 서명자 정책 검증이 필요합니다."
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.
# EIP-712 형식화 서명: 도메인, 다이제스트와 안전한 검증
> 교육 참고용이며 투자 조언이 아닙니다. 투자로 인해 손실이 발생할 수 있습니다.
## 직접 답변
EIP-712는 Ethereum 애플리케이션이 형식화된 구조 데이터를 설명하고 해시하며 서명을 요청하는 방법을 표준화합니다. 요청에는 `types`, `primaryType`, `domain`, `message`가 포함되고, 다이제스트는 `keccak256("\x19\x01" || domainSeparator || hashStruct(message))`입니다. 따라서 인코딩이 결정론적이며, 이를 지원하는 지갑은 불투명한 해시보다 각 필드를 명확하게 보여줄 수 있습니다.
그러나 메시지를 진실하거나 안전하거나 취소 가능하거나 재사용 불가능하게 만들지는 **않습니다**. 애플리케이션은 권한을 올바른 체인과 검증자에 결속하고, 모든 필드를 명확하게 정의하며, Nonce와 시간 제한을 강제하고, 올바른 서명자를 검증하고, 실행 가능한 동작을 제한해야 합니다. 유효한 서명은 특정 검증 규칙에 따라 정확한 다이제스트가 승인되었다는 사실만 증명할 뿐, 서명자의 신원, 충분히 이해한 의도, 웹사이트나 컨트랙트의 안전을 증명하지 않습니다.
## 작동 원리
### 1. 동작과 검증 경로 식별
요청이 로그인, 주문, 투표, 토큰 allowance, 전송, 릴레이 호출 또는 다른 동작 중 무엇을 승인하는지 확인합니다. 다이제스트를 다시 만들고 서명을 소비하는 코드를 찾습니다. 외부 소유 계정은 보통 ECDSA 서명에서 주소를 복구해 검증합니다. 컨트랙트 계정은 ERC-1271 `isValidSignature(hash, signature)`와 성공 값 `0x1626ba7e`를 확인해야 할 수 있습니다.
### 2. 도메인 고정
정확한 `EIP712Domain` 형식과 값을 확인합니다. 표준 필드는 `name`, `version`, `chainId`, `verifyingContract`, `salt`이지만 실제 포함된 필드만 해시됩니다. 현재 체인, 배포된 코드, 의도한 검증자를 독립적으로 확인하십시오. 익숙한 이름, 토큰 기호, 프록시 라벨이나 체크섬 주소만으로는 부족합니다. ERC-5267 `eip712Domain()`은 컨트랙트 도메인을 공개할 수 있지만 지원은 선택 사항이며, 프록시와 업그레이드 동작도 검토해야 합니다.
### 3. 형식 그래프 재구성
`primaryType`에서 시작해 멤버 순서를 보존하고 참조된 구조체를 재귀적으로 수집합니다. `encodeType`은 참조된 구조체 정의를 형식 이름 순서로 정렬해 덧붙입니다. EIP-712는 고정 너비 정수, `address`, `bool`, `bytes1`부터 `bytes32`, 동적 `bytes`와 `string`, 배열, 구조체를 지원합니다. `uint`나 `int` 별칭, 고정소수점 형식, 순환 값은 표준에 정의되어 있지 않습니다.
### 4. 모든 값과 단위 해석
각 메시지 값을 선언된 형식과 애플리케이션 의미에 대응시킵니다. 전체 주소, 원시 정수 단위, 부호, 배열 순서, 수령자, spender, 자산, 금액, 수수료, 한도, 목적지, calldata 해시, 사람이 읽는 문자열을 확인합니다. 동적 `bytes`와 `string`은 `encodeData`에서 내용의 Keccak-256 해시로 표현되고, 배열은 이어 붙인 요소 인코딩의 해시를, 중첩 구조체는 자체 `hashStruct`를 사용합니다.
### 5. 다이제스트 독립 재계산
`typeHash = keccak256(encodeType(primaryType))`를 계산한 뒤 `hashStruct(message) = keccak256(typeHash || encodeData(message))`를 계산합니다. 같은 방식으로 도메인 구분자를 계산하고 ERC-191 버전 바이트 `0x19 0x01`과 결합합니다. 프런트엔드, 서명 라이브러리, 검증 컨트랙트, 독립 구현의 결과를 비교하십시오. JSON 모양이 같다고 해서 형식화 인코딩도 같다는 뜻은 아닙니다.
### 6. 재사용, 시간과 실행 통제 감사
EIP-712 자체에는 재사용 방지가 없습니다. 검증자가 의도한 서명자를 확인하고, 올바른 Nonce를 소비하거나 무효화하고, `deadline` 또는 유효 기간을 강제하고, 보안상 중요한 모든 실행 매개변수를 결속하는지 확인합니다. 릴레이어나 프런트러너가 먼저 제출해도 의도한 결과가 나와야 합니다. 도메인 분리는 실제 인코딩된 도메인 사이의 충돌만 방지하므로 누락되거나 잘못된 필드는 컨트랙트 간 또는 체인 간 재사용 경로를 남깁니다.
### 7. 최소 권한으로 서명하고 결과 대조
숨겨진 필드, 설명할 수 없는 형식, 무제한 값, 먼 기한, 알 수 없는 컨트랙트, 불일치하는 체인 ID, 블라인드 서명 화면, 불완전한 실행 맥락은 거부합니다. 정확한 형식화 데이터 JSON과 다이제스트를 보관하고 가능하면 용도 제한 계정을 사용하십시오. 제출된 트랜잭션, 영수증, 이벤트, 잔액, allowance, Nonce, 주문 상태와 최종성을 확인합니다. 사이트 연결을 끊어도 사용 가능한 서명이나 이미 생성된 권한은 취소되지 않습니다.
## 계산 예시
### 예시 1: 형식과 다이제스트 구성
`Order(address maker,address token,uint256 amount,uint256 nonce,uint256 deadline)`의 `typeHash`는 필드 순서를 포함한 이 정확한 문자열의 Keccak-256 해시입니다. 메시지 해시는 `keccak256(typeHash || maker || token || amount || nonce || deadline)`이며 각 인코딩 멤버는 32바이트를 차지합니다. 최종 다이제스트는 `0x1901`, 도메인 구분자와 메시지 해시를 더합니다. `amount`를 `250000000`에서 `250000001`로 바꾸면 다이제스트가 바뀌어 이전 서명이 무효가 됩니다.
### 예시 2: 단위와 기한
소수점 여섯 자리 토큰의 `250 USDC`는 원시 값 `250000000`으로 인코딩되며 `250`이 아닙니다. 현재 타임스탬프가 `1727000000`이고 기한이 `1727000900`이면 서명 가능 시간은 `900 seconds = 15 minutes`입니다. 지갑의 소수 표시와 로컬 시계는 보조 자료일 뿐이며, 검증자는 원시 정수와 선택한 온체인 시간 규칙을 사용합니다.
### 예시 3: 재사용 통제
주문에 Nonce `41`과 최대 체결량 `5 ETH`가 있다고 가정합니다. 검증자가 Nonce 41을 소비 처리한 뒤에는 서명 자체가 올바르더라도 두 번째 제출이 실패해야 합니다. 컨트랙트가 Nonce를 소비하지 않고 실행도 멱등적이지 않으면 같은 서명이 다른 `5 ETH`를 승인할 수 있습니다. 도메인 구분자만으로는 이런 재사용을 막지 못합니다.
### 예시 4: 컨트랙트 지갑의 유효성
서명자 A, B, C가 설정된 2-of-3 컨트랙트 지갑이 다이제스트를 승인했다고 가정합니다. A와 B의 서명에 대해 ERC-1271이 현재 `0x1626ba7e`를 반환할 수 있습니다. 모듈 업그레이드로 B가 D로 교체되면 동일한 서명 바이트도 무효가 될 수 있습니다. ERC-1271 유효성은 현재 컨트랙트 상태, 정책, 시간과 외부 호출에 의존할 수 있으므로 주소 복구만으로 판단할 수 없습니다.
## 위험
- 잘못되거나 누락된 `chainId`
- 위조되었거나 예상 밖인 `verifyingContract`
- 오해를 부르는 도메인 `name` 또는 `version`
- 업그레이드 후 바뀌는 프록시 구현 또는 도메인
- 잘못된 `primaryType` 또는 비슷한 라벨의 그림자 형식
- 멤버 순서, 의존성 순서 또는 인코더 불일치
- 주소 생략, 대체 또는 기만적 라벨
- 토큰 소수 자릿수 또는 부호 있는 정수와 없는 정수 오류
- 숨겨진 배열 항목, 중첩 구조체 또는 임의 `bytes` 페이로드
- 무제한 금액, 지나치게 넓은 범위 또는 공격자가 정하는 수령자
- 누락, 만료, 공유 또는 잘못 소비된 Nonce
- 누락, 지나치게 먼, 오버플로된 또는 모호한 기한
- 체인 간, 컨트랙트 간, 계정 간 또는 동작 간 재사용
- 릴레이어의 보류, 검열, 프런트러닝 또는 실행 경로 변경
- 서명 가변성 또는 지나치게 허용적인 ECDSA 복구
- ERC-1271 서명자, 모듈, 임계값, 상태 또는 코드 변경
- 지갑 렌더링, 블라인드 서명 또는 미지원 형식 오류
- 프런트엔드 JSON과 검증자 다이제스트의 차이
- 취소 또는 철회가 순서 경쟁에서 지는 상황
- 서명 프롬프트 결과를 영수증, 상태 변화 또는 최종성으로 오인
## 흔한 오해
### 오해 1: EIP-712 서명은 트랜잭션이다
이는 오프체인에서 서명한 메시지입니다. 릴레이어나 다른 참여자가 나중에 컨트랙트로 제출할 수 있고, 그 트랜잭션은 서명자가 보내지 않아도 Gas를 소비하고 상태를 바꿀 수 있습니다.
### 오해 2: 구조화된 표시라면 요청은 안전하다
형식화 필드는 검토 가능성을 높이지만 악의적인 스키마, 값, 컨트랙트, 라벨, 숨겨진 중첩과 불완전한 지갑 표시는 여전히 서명자를 속일 수 있습니다.
### 오해 3: 도메인 구분자는 모든 재사용을 막는다
인코딩된 도메인만 분리합니다. 같은 도메인에서의 재사용에는 Nonce, 기한, 취소, 체결 회계 또는 멱등성이 필요하고, 포함되지 않은 도메인 필드는 경계가 되지 않습니다.
### 오해 4: 예상한 주소를 복구하면 권한이 증명된다
복구는 EOA가 다이제스트에 서명했다는 사실만 증명합니다. 애플리케이션 의미는 검증하지 않으며, 컨트랙트 계정에는 일반 주소 복구가 아닌 ERC-1271 정책이 필요합니다.
### 오해 5: 페이지를 닫거나 지갑 연결을 끊으면 서명이 취소된다
복사된 서명은 검증자의 Nonce, 기한, 취소 상태 또는 정책이 무효화할 때까지 사용할 수 있습니다. 세션 상태가 아니라 관련 온체인 상태를 확인하십시오.
## 관련 주제
- [체인 ID](/ko/crypto/chain-id/)
- [ERC-2612 Permit Nonce와 기한](/ko/crypto/erc2612-permit-nonce-deadline/)
- [Permit2 서명 위험](/ko/crypto/permit2-signature-risk/)
- [지갑 승인](/ko/crypto/wallet-approval/)
- [지갑 서명](/ko/crypto/wallet-signature/)
## 출처
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (확인일: 2026-08-19)
- [ERC-191: Signed Data Standard](https://eips.ethereum.org/EIPS/eip-191) - Ethereum Improvement Proposals (확인일: 2026-08-19)
- [ERC-1271: Standard Signature Validation Method for Contracts](https://eips.ethereum.org/EIPS/eip-1271) - Ethereum Improvement Proposals (확인일: 2026-08-19)
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (확인일: 2026-08-19)
- [ERC-5267: Retrieval of EIP-712 domain](https://eips.ethereum.org/EIPS/eip-5267) - Ethereum Improvement Proposals (확인일: 2026-08-19)
- [EIP-2: Homestead Hard-fork Changes](https://eips.ethereum.org/EIPS/eip-2) - Ethereum Improvement Proposals (확인일: 2026-08-19)
- [Contract ABI Specification](https://docs.soliditylang.org/en/latest/abi-spec.html) - Solidity Documentation (확인일: 2026-08-19)
- [ERC-7730: Structured Data Clear Signing Format](https://eips.ethereum.org/EIPS/eip-7730) - Ethereum Improvement Proposals (확인일: 2026-08-19)
Source: https://wiki.fcontext.com/ko/crypto/eip712-typed-signature/index.mdx