ERC-2612 Permit vs Permit2: 서명 기반 토큰 승인 완벽 비교

dApp에서 토큰 하나를 스왑하려는데 익숙한 온체인 승인 거래 대신 ‘서명’만 요청받으셨나요? 더 안전해진 걸까요, 아니면 승인이 눈에 덜 보이는 곳으로 이동했을 뿐일까요? 이제 이 차이를 이해하는 것도 실전 크립토 지갑 보안의 일부예요. ERC-2612 Permit과 유니스왑 Permit2는 모두 ERC-20 승인 절차를 간소화하지만, 서로 같은 기술이 아니며 낯선 서명을 안전하게 만들어 주지도 않습니다.

이 글에서는 각 방식이 무엇을 허용하고, 서명이 어떻게 블록체인에 전달되며, 서명 전 무엇을 확인해야 하는지 비교해요. 교육 목적이며 투자 조언이 아닙니다(NFA). 스마트 컨트랙트와 서명에는 손실 위험이 있으니 최신 인터페이스와 주소를 직접 검증하고 스스로 조사하세요(DYOR).

Permit 서명은 어떤 문제를 해결하나요?

일반적인 ERC-20 토큰 사용에는 온체인 단계가 두 번 필요해요. 먼저 토큰 컨트랙트에서 approve(spender, amount)를 호출합니다. 그다음 dApp 컨트랙트를 실행하면, 승인 한도 안에서 transferFrom으로 토큰을 가져갈 수 있어요. 첫 승인은 가스비가 들고 확인도 한 번 더 기다려야 합니다.

은행 창구에서 자동이체 약정을 먼저 등록한 뒤 결제한다고 생각해 보세요. Permit은 은행에 직접 제출하는 대신 상점에 건네는 서명된 위임장과 비슷해요. 상점이나 중계자(relayer)가 실제 이용 거래와 함께 제출할 수 있습니다. 지출 권한은 여전히 내주지만, 내 계정이 별도 승인 거래를 보내는 대신 암호학적 서명으로 표현하는 거예요.

ERC-2612 명세는 ERC-20 토큰에 permit, nonces, DOMAIN_SEPARATOR를 추가합니다. 서명 데이터에는 소유자(owner), 사용 주체(spender), 금액(value), 논스(nonce), 기한(deadline)이 들어가요. 논스는 같은 서명의 재사용을 막고, 기한은 Permit을 제출할 수 있는 시간을 제한합니다.

ERC-2612 Permit은 어떻게 작동하나요?

ERC-2612는 토큰 컨트랙트 자체가 구현해요. 호환 토큰은 permit 함수를 제공하고, 사용자는 허용량(allowance)을 설명하는 EIP-712 구조화 데이터에 서명합니다. 중계자가 토큰 컨트랙트에 서명을 제출하면 컨트랙트가 서명·논스·소유자·기한을 검사해요. 모두 유효하면 허용량을 기록하고 승인 이벤트를 발생시킵니다.

흐름은 보통 이렇습니다.

1. dApp이 토큰 하나, 사용 주체 하나, 금액 하나, 기한 하나를 담은 Permit을 만들어요.
2. 지갑이 EIP-712 서명 요청을 표시합니다.
3. 오프체인에서 서명하므로 이 순간에는 온체인 거래가 생기지 않아요.
4. 중계자가 Permit을 제출하며, 허용량을 사용하는 작업과 묶기도 합니다.
5. 토큰 컨트랙트가 검증한 뒤 허용량을 기록해요.

가장 큰 한계는 호환성이에요. 토큰마다 ERC-2612를 올바르게 구현해야 합니다. 오래된 토큰이나 다른 Permit 변형을 쓰는 토큰에는 표준 흐름을 그대로 적용할 수 없어요.

유니스왑 Permit2는 어떻게 작동하나요?

Permit2는 ERC-2612를 구현하지 않은 일반 ERC-20에도 Permit과 비슷한 기능을 제공하도록 설계된 별도 공유 컨트랙트예요. dApp이 사용하기 전, 보통 토큰 소유자는 토큰 컨트랙트에서 Permit2 컨트랙트에 온체인 승인을 한 번 줍니다. 이후 Permit2가 서명 메시지로 더 좁은 권한을 관리해요.

핵심 경로는 두 가지입니다.

• AllowanceTransfer: 특정 사용 주체에 금액과 시간이 제한된 권한을 서명으로 설정해요. 이후 전송은 저장된 권한 범위 안에서만 성공합니다.
• SignatureTransfer: 서명이 소비되는 거래에서 한 번의 전송을 허용해요. 해당 사용 주체에 계속 남는 Permit2 허용량을 만들지 않습니다.

Permit2는 여러 토큰을 묶는 배치 작업, EIP-1271 기반 컨트랙트 지갑 서명, 만료 권한, 재사용을 막는 비순차 논스도 지원해요. 사용성과 통합은 일관되지만 메시지에 들어간 필드를 꼼꼼히 읽어야 하는 이유도 늘어납니다.

ERC-2612 Permit vs Permit2 비교

질문	ERC-2612 Permit	유니스왑 Permit2
권한을 어디서 검증하나요?	ERC-20 토큰 컨트랙트	공유 Permit2 컨트랙트
어떤 토큰을 지원하나요?	토큰이 ERC-2612를 구현해야 함	Permit2에 기본 승인을 주면 일반 ERC-20도 가능
핵심 권한은 무엇인가요?	토큰 허용량을 갱신	저장형 허용량 또는 일회성 서명 전송
만료는 어떻게 되나요?	서명의 제출 기한	서명 기한과 저장형 권한의 만료 시간
배치를 지원하나요?	ERC-2612 자체에는 없음	Permit2에서 지원
무엇을 신뢰해야 하나요?	토큰 구현, spender, dApp, 서명 표시	Permit2 배포 주소, spender, dApp, 서명 표시, Permit2 기본 승인

어느 한쪽이 언제나 ‘더 안전하다’고 말할 순 없어요. ERC-2612는 토큰 내부라는 비교적 좁은 범위를 갖지만 구현 차이가 있을 수 있습니다. Permit2는 일관된 제어와 일회성 전송을 제공하지만, 속이는 서명으로 공격자에게 권한을 줄 수도 있어요. 실제 안전성은 서명 필드, 검증된 컨트랙트 주소, 권한을 받는 spender에 달려 있습니다.

사라지지 않는 보안 리스크

가스비 없는 서명도 자산을 움직일 수 있어요

‘서명’은 단순 로그인이 아닙니다. 구조화 데이터 요청도 지출 권한을 만들 수 있어요. 메타마스크의 서명 피싱 안내는 악성 dApp이 오프체인 서명을 수집한 뒤 나중에 사용할 수 있다고 경고합니다. 서명 순간 가스비가 없다는 이유로 안전한 요청은 아니에요.

화면의 문구보다 spender가 중요해요

정교한 가짜 사이트는 화면에 ‘받기’, ‘인증’, ‘연결’이라고 쓰면서 실제 메시지에는 공격자가 통제하는 spender를 넣을 수 있습니다. 도메인과 컨트랙트 주소를 별도의 공식 출처에서 확인하세요. 지갑이 토큰, spender, 금액, 체인, 만료를 명확히 보여 주지 못한다면 블라인드 서명(Blind Signing)하지 말고 거절하는 편이 안전해요.

deadline과 허용량 만료는 같지 않아요

ERC-2612의 deadline은 서명된 Permit을 언제까지 제출할 수 있는지 제한해요. 일단 제출돼 토큰 허용량이 기록되면 일반 토큰 승인 규칙을 따릅니다. deadline이 기록된 허용량까지 자동으로 만료시키는 것은 아니에요. Permit2의 AllowanceTransfer 경로는 권한 자체에 만료 시간을 둘 수 있습니다. 화면에 표시된다면 서명 기한과 허용량 만료를 모두 확인하세요.

취소해도 이미 끝난 전송은 되돌릴 수 없어요

살아 있는 허용량을 취소하면 미래 사용은 막을 수 있지만, 이미 온체인에서 확정된 전송은 되돌릴 수 없습니다. 수상한 미사용 서명은 사이트 연결 해제만으로 해결되지 않을 수도 있어요. 지갑이나 프로토콜의 최신 사고 대응 지침을 따르고, 노출 가능성이 높다면 남은 자산을 새 계정으로 옮기는 방안도 검토하세요. 다급함을 노리는 미검증 ‘복구 서비스’는 피해야 합니다.

서명 전 5가지 점검

1. 출처: 저장한 주소나 독립적으로 확인한 공식 URL에서 dApp을 열었나요?
2. 체인과 컨트랙트: 예상한 네트워크가 맞고, 검증 컨트랙트가 공식 배포 주소인가요?
3. Spender: 권한을 받는 주소가 지금 실행하려는 dApp 작업의 주소인가요?
4. 토큰·금액·범위: 예상한 자산과 수량으로 제한됐나요? 무제한 값은 높은 신뢰를 전제로 한 의식적 선택으로 다뤄야 해요.
5. 기한과 만료: 서명 제출 가능 시간이 짧은가요? 계속 남는 허용량에도 적절한 만료가 있나요?

여기서 클리어 사이닝이 중요해요. EIP-712는 데이터를 구조화하지만, 지갑이 정확히 해석해 보여 줘야 하고 사용자도 의미를 이해해야 합니다. ‘구조화됨’이 ‘신뢰할 수 있음’을 자동으로 뜻하지는 않아요.

자주 묻는 질문

Permit2는 ERC-20 승인을 완전히 대체하나요?

보통은 아니에요. 일반 토큰은 먼저 토큰 단계에서 Permit2 컨트랙트에 승인을 줍니다. Permit2는 그 기반 위에서 dApp별 서명 권한이나 일회성 전송을 관리해요.

ERC-2612 서명은 무료인가요?

오프체인 서명을 만드는 순간에는 가스비가 들지 않아요. 하지만 누군가는 이를 온체인에 제출해야 하고, 중계자나 앱이 대신 부담하더라도 네트워크 비용은 발생합니다.

사용 전 Permit을 취소할 수 있나요?

취소 방식은 시스템과 지갑에 따라 달라요. 논스와 기한은 재사용과 유효 시간을 제한하지만, 사이트 연결을 끊으면 서명까지 취소된다고 가정하면 안 됩니다. 해당 토큰이나 Permit2 통합의 최신 공식 문서를 확인하고 악성 가능성이 있다면 빠르게 대응하세요.

Permit2 요청은 모두 거절해야 하나요?

아니요. Permit2는 실제 앱이 사용하는 합법적인 인프라예요. 출처, 검증 컨트랙트, spender, 토큰, 금액, 만료를 판단해야 합니다. 기술 이름만으로 안전하거나 악성이라고 결론 내릴 순 없어요.

실전 핵심 정리

ERC-2612는 호환 토큰 안에 Permit 로직을 둡니다. Permit2는 계속 남는 허용량과 일회성 서명 전송을 모두 제공하는 공유 권한 계층이에요. 둘 다 승인 과정의 불편을 줄이지만, 피싱 공격자가 원하는 가치 있는 권한을 표현할 수도 있습니다.

가스비가 표시되지 않아도 지갑이 서명을 요청하면 천천히 확인하세요. 출처, 컨트랙트, spender, 금액, 시간 제한을 검증하고 가능한 경우 범위가 제한된 권한을 사용하세요. 낯선 상호작용 뒤에는 활성 승인을 다시 살펴보는 게 좋습니다. 이 글은 교육 목적이며 투자 조언이 아닙니다(NFA). 크립토와 스마트 컨트랙트 사용은 전액 손실로 이어질 수 있으니 잃어도 되는 금액만 사용하고, 최신 사실을 직접 검증하며 항상 스스로 조사하세요(DYOR).