Permit2란 무엇인가요?
Permit2 소개
Uniswap은 전통적인 ERC20 및 EIP-2612와 다른 새로운 토큰 승인 표준인 Permit2를 방금 출시했습니다. Permit2를 사용하면 사용자가 다양한 DApp과 상호작용하기 전에 체인 레벨 "approve" 작업이 필요 없으며, DApp 프로토콜이 먼저 토큰 승인을 획득할 수 있습니다. 설명에 따르면, 새로운 Permit2 프로토콜은 가스 절약, 승인/전송의 배치 작업 허용, 전통적인 ERC20 승인보다 더 유연하고, 원스톱 승인 관리를 지원하는 장점이 있습니다.
Uniswap은 처음에 자체 제품을 개선하고, 가스 비용을 최적화하며, 사용자 트랜잭션 프로세스를 단순화하고, 보안을 향상시키기 위해 Permit2와 Universal Router를 구상했습니다. 개념화 과정에서 Uniswap은 다른 애플리케이션이 이러한 컨트랙트를 통합함으로써 크게 이익을 얻을 수 있다고 느꼈습니다. Uniswap 자체는 공공 인프라 구축에 전념하고 있으므로, 광범위한 문서와 SDK를 포함하여 전체 개발자 생태계에서 사용할 수 있도록 이러한 컨트랙트를 설계했습니다.
Permit2가 얼마나 혁신적인지 설명하기 위해, Alice가 보유한 토큰을 이동해야 하는 컨트랙트의 예를 들어 이전 솔루션을 검토해보겠습니다.
전통적인 승인 모델
전통적인 실행 방식은 다음 다이어그램에 나와 있습니다.
Alice는 ERC20에서 approve() 함수를 호출하여 컨트랙트에 제어 한도를 부여합니다.
Alice는 컨트랙트에서 상호작용 함수를 호출하고, 이 함수는 다시 ERC20 토큰 컨트랙트에서 transferFrom()을 호출하여 그녀의 토큰을 이동시킵니다. 이 모델이 실행 가능하고(널리 존재하므로) 궁극적으로 매우 유연할 수 있음은 명백합니다. 프로토콜이 장기간 사용자의 토큰에 지속적으로 접근할 수 있기 때문입니다.
승인 컨트랙트는 기본적으로 시간 제한 없이 최대 토큰 양을 제어할 수 있는 승인을 받습니다. 각 DApp은 첫 번째 실행을 위해 일회성 승인이 필요하며, 이는 상당한 위험을 초래합니다.
하지만 두 가지 잘 알려진 실제 문제에 직면합니다:
불편한 사용자 경험: 사용자는 각 토큰에서 사용하려는 각 새로운 프로토콜에 대해 승인을 부여해야 하며, 이는 거의 항상 별도의 트랜잭션입니다(예: Uniswap에서 토큰 승인을 실행하지만 Transit을 사용하는 경우 여전히 재승인해야 함).
보안 취약: 컨트랙트는 일반적으로 무제한 승인 한도를 요구하며, 스왑 또는 기타 컨트랙트를 사용할 때마다 승인을 실행해야 합니다. 이것은 프로토콜이 악용되면, 프로토콜에 토큰을 소비하도록 승인한 모든 사용자가 승인된 모든 토큰이 전송될 수 있음을 의미합니다. (예: 토큰 사용 승인을 자주 접하게 되는데, 예를 들어 DeFi 운영 승인, 교환 승인, 다양한 DApp의 첫 사용 승인 등)
Permit (EIP-2612) 모드
EIP-2612는 토큰 승인을 반복 개선합니다. 사용자는 사전 승인 없이 트랜잭션에 승인 서명(Permit) 정보를 첨부하여 애플리케이션 컨트랙트와 상호작용할 수 있습니다.
ERC20의 EIP-2612 확장으로 활성화된 방법을 살펴보겠습니다. 일반적으로 다음과 같습니다:
Alice는 오프체인에서 "permit" 메시지에 서명하여, (EIP-2612) 토큰을 사용할 권한을 컨트랙트에 부여하고자 함을 나타냅니다.
Alice는 해당 컨트랙트와의 상호작용의 일부로 서명된 메시지를 제출합니다.
컨트랙트는 서명 승인 정보와 서명을 사용하여 토큰에서 "permit()" 메서드를 호출하여 컨트랙트에 권한을 부여합니다.
컨트랙트가 이제 권한을 가지므로, 토큰에서 transferFrom()을 호출하여 Alice가 보유한 토큰을 전송할 수 있습니다.
EIP-2612(Permit)의 요구사항은 관련 메서드가 ERC20 토큰 컨트랙트 내부에 작성되어야 하므로, 기존에 배포된 ERC20 컨트랙트는 지원할 수 없습니다.
이것은 일반적인 ERC20 승인 방법의 두 가지 문제를 해결합니다:
사용자는 온체인에서 추가 approve() 트랜잭션을 제출할 필요가 없습니다.
하나의 온체인 작업이 생략되므로, 일반적으로 무제한보다 더 합리적인 승인 양을 선택할 수 있으며, 더 중요한 것은 승인 메시지에 서명할 때 만료 시간을 설정할 수 있다는 것입니다.
EIP-2612는 토큰 승인을 더 안전하게 만들지만, EIP-2612 이전에 출시된 토큰은 서명 승인을 지원하지 않으며 모든 새로운 토큰이 이 기능을 채택한 것은 아닙니다. 따라서 프로토콜이 널리 사용되지 않습니다.
Permit2 승인 모델
Permit2는 두 모델을 결합하여, EIP-2612의 사용자 경험 및 보안 장점을 표준 ERC20 토큰에도 적용합니다.
Alice는 일반적인 방식으로 ERC20에서 approve()를 호출하여 Permit2 컨트랙트에 무제한 승인을 부여합니다.
Alice는 오프체인에서 Permit2 메시지에 서명하여, 프로토콜 컨트랙트가 그녀를 대신하여 토큰을 전송할 수 있음을 나타냅니다.
Alice는 프로토콜 컨트랙트에서 상호작용 함수를 호출하고, 서명된 Permit2 메시지를 인수로 전달합니다.
프로토콜 컨트랙트는 Permit2 컨트랙트에서 permitTransferFrom()을 호출하고, Permit2 컨트랙트는 승인(1에서 부여됨)을 사용하여 ERC20 컨트랙트에서 "transferFrom()"을 호출하여 Alice가 보유한 토큰을 전송합니다.
Permit2에 승인을 부여함으로써, Permit2 프로토콜을 사용하는 DApp은 추가 체인 레벨 승인이 필요 없이 712 로컬 서명을 한 번만 수행하면 되며, 가스 수수료를 줄이고 사용성과 보안을 향상시킵니다. 승인은 시간 제한이 있습니다. 예를 들어, 한 달 동안 부여되면, 한 달이 만료된 후 다시 사용하려면 하나의 712 서명만 필요합니다. Permit2에 승인을 부여함으로써, Permit2 프로토콜을 사용하는 DApp은 추가 체인 레벨 승인이 필요 없이 712 로컬 서명을 한 번만 수행하면 되며, 가스 수수료를 줄이고 사용성과 보안을 향상시킵니다. 승인은 시간 제한이 있습니다. 예를 들어, 한 달 동안 부여되면, 한 달이 만료된 후 다시 사용하려면 하나의 712 서명만 필요합니다.
프로토콜은 ERC20 토큰에서 transferFrom()을 직접 호출하여 전송을 실행하지 않고, 대신 표준 Permit2 컨트랙트의 permitTransferFrom()을 호출합니다. Permit2는 프로토콜과 ERC20 토큰 사이에 위치하여 permit2 메시지를 추적하고 검증한 다음, 궁극적으로 승인을 사용하여 ERC20에서 transferFrom() 호출을 직접 실행합니다. 이 간접성으로 인해 Permit2는 EIP-2612와 유사한 이점을 모든 기존 ERC20 토큰에 확장할 수 있습니다.
Permit2 프로토콜의 장점:
통합 토큰 관리
제어 가능한 승인 시간
매번 승인을 위한 트랜잭션을 보낼 필요 없음
Permit2의 가능한 위험
Permit2는 EIP 2612에서 파생되었으며 EIP 20 프로토콜의 확장이므로, 궁극적으로 Permit2는 ERC20의 보완일 뿐 대체품이 아닙니다. 결국 Permit2는 모든 기존 ERC20 데이터를 상속하지 않으며, 소위 원스톱 관리도 여전히 일부 초기 작업을 완료하기 위해 ERC20 컨트랙트의 approve 함수를 호출해야 합니다.
Permit2의 전체 프로세스는 다음과 같아야 합니다:
1. 사용자는 Permit2 컨트랙트에 ERC20 토큰의 최대 승인을 부여합니다.
2. 사용자는 Permit2 컨트랙트의 permit 함수를 통해 특정 승인을 관리합니다.
3. 제3자 프로토콜과 사용자는 Permit2에 이미 사용 가능한 승인 정보를 기반으로 중개자로서 Permit2 컨트랙트를 통해 토큰을 전송할 수 있습니다.
Permit2 프로토콜의 가능한 위험:
무제한 승인 문제를 해결한다고 주장하지만, 실제로는 상호작용하는 DApp에서 Permit2 컨트랙트로 승인 대상을 전환하는 것뿐이며, Permit2 컨트랙트의 보안은 중앙화된 승인 관리에 대한 더 높은 표준이 필요합니다.
토큰 승인에 만료 시간이 있지만, 이 시간은 여전히 무제한일 수 있으며, Dapp은 여전히 합리적인 만료 시간을 설정해야 합니다.
permit 함수 호출 프로세스는 트랜잭션을 보내지 않고도 수행할 수 있으며, 단지 제3자에게 전달을 위한 서명을 제공하기만 하면 되므로, 피싱에 사용되는 경우 더 은밀할 수 있습니다. 서명 메시지를 확인하는 비용이 증가하며, 일부 제3자 지갑은 서명 정보를 디코딩하고 표시하지 않을 수 있어 사용자 공격 위험이 증가합니다.
장점과 위험이 동시에 존재하므로, 우리에게는 일정한 판단 능력이 필요합니다. 구체적으로, 지갑은 향후 Permit2의 대규모 지원 가능성에 대한 사전 예방도 필요합니다(TokenPocket은 아직 Permit2의 파싱을 지원하지 않지만, 곧 지원할 예정입니다). 예를 들어, TokenPocket의 현재 승인 위험 경고 팝업 창은 위험 내용을 잘 표시할 수 있어, 제3자의 피싱이나 악의적인 승인과 같은 위험을 피할 수 있습니다.
알 수 없는 웹사이트를 열고 무분별하게 실행하지 마세요. 반드시 정규 DApp을 사용하고, 컨트랙트에 부여된 토큰 양을 가능한 한 제어하세요. 정기적으로 승인 확인 도구를 사용하여 검사하세요.
Last updated