초록
이더리움에서 ERC20 토큰은 기업이나 사용자들이 탈중앙화 애플리케이션(DApp)을 구축하는 데 널리 활용됩니다. 많은 ERC20 토큰은 높은 가치를 지니며 암호화폐 시장에서 유통되고 있습니다. 또한 DeFi 생태계의 급속한 발전으로 인해 ERC20 토큰 거래가 더욱 빈번해졌습니다. ERC20 표준에 기반하여, approve() 메서드는 DApp이나 다른 사용자에게 토큰을 출금할 수 있는 권한을 부여하기 위해 호출됩니다. 실제로 많은 DApp이 사용자에게 무제한 승인을 요구하며, 이러한 설계는 심각한 문제를 야기했습니다. 일련의 사건들이 발생하여 사용자와 DApp 모두에게 막대한 손실을 초래했습니다.
0xffffff. 서문
오랫동안 논의되어 온 주제인 "무제한 승인"은 DeFi의 급격한 발전과 일부 보안 사고를 계기로 다시 주목받고 있습니다. 수많은 보안 사고에서 영감을 받아, 우리는 "무제한 승인"에 대해 다양한 측면에서 종합적인 조사를 다시 한번 시도합니다. 동시에, 제29회 블록체인 빌리지 컨퍼런스에 초청받아 이 문제에 대해 발표하게 되었습니다.
읽기 권장 사항:
- 이더리움 입문자라면, 블로그 전체를 읽으시길 강력히 권장합니다.
- 이더리움 전문가이며 무제한 승인에 대한 경험이 있으신 분이라면, 0x2 섹션부터 읽기 시작하셔도 됩니다.
0x0. 배경
"무제한 승인이란 무엇인가?"에 대한 논의를 시작하기 전에, 먼저 "ERC20 토큰에서 승인이란 무엇인가?"에 대해 다시 한번 짚어보겠습니다.
ERC20 토큰
이더리움에서는 이더(Ether) 외에도 다양한 토큰들이 높은 가치를 지닌 채 암호화폐 시장에서 유통되고 있습니다. ERC20은 가장 널리 사용되는 토큰 표준입니다. 저희의 미완성 통계에 따르면, CoinGecko(토큰 가격을 집계하는 웹사이트)와 Uniswap(현재 가장 유명한 탈중앙화 거래소 중 하나)에서 각각 5,600개 이상, 44,000개 이상의 ERC20 토큰이 기록되어 있습니다.
승인 메커니즘
승인 과정은 주로 세 가지 주체(송신자, 지출자, 토큰 컨트랙트)와 ERC20 표준의 두 가지 함수(approve, transferFrom) 및 두 가지 변수(balanceOf, allowance)와 관련이 있습니다(아래 그림 참조).
승인 과정을 이해하기 위해, 아래 그림을 제시하고 approve와 transferFrom 함수가 토큰 컨트랙트의 상태를 어떻게 변경하는지 설명합니다.
- (1단계) 초기 상태로, 송신자는 컨트랙트에 100개의 토큰을 보유하고 있으며 지출자는 송신자로부터 승인된
allowance가 없습니다. - (2단계) 송신자가
approve함수를 호출하여 지출자에게 100개의 토큰에 대한 권한을 부여합니다. 따라서allowance[sender][spender]가 0에서 100으로 증가하며 송신자의balanceOf에는 변화가 없습니다. - (3단계) 마지막으로, 지출자가
transferFrom을 호출하여 송신자로부터 자신에게 80개의 토큰을 이전합니다. 결과적으로 송신자와 지출자 모두의balanceOf가 업데이트되고(각각 20과 80), 지출자의 allowance는 20으로 감소합니다.
실제 세 가지 유형의 승인
실제 세계에서, 승인 금액에 따라 모든 승인을 세 가지 유형으로 분류할 수 있습니다.
- 제로 승인： 승인 금액이 0인 경우. 이는 기본적으로 사용자/송신자가 특정 플랫폼/지출자로부터 자신의 allowance를 취소하려는 것을 의미합니다.
- 무제한 승인： 승인 금액이
uint256의 최대값(0xffff...ffff) 또는 토큰의 총 공급량과 동일한 경우. 이 유형의 승인은 많은 DeFi 플랫폼(거래소, 대출 플랫폼 등)에서 자주 사용됩니다. - 기타 승인： 이 유형은 나머지를 포함합니다. 사용자들은 일반적으로 플랫폼이나 지갑이 지원하는 수정 기능을 기반으로 이 승인을 실행합니다.
0x1. 실제 사고 사례
앞서 언급한 승인 문제와 관련된 실제 사고 사례들도 있습니다. 발표에서 우리는 그 중 두 가지(UniCat, Bancor Finance) 사례를 자세히 살펴보았습니다. 해당 사고에 대해 더 알고 싶으시다면, 아래에 제공된 링크를 참조하시기 바랍니다:
- UniCat 사고：링크
- Bancor Finance 사고: 링크
- Primitive Finance: 링크1, 링크2
- Furucombo: 링크，링크 (중국어)
- DeFi Saver: 링크
- Degen Money: 트위터
0x2. 측정 조사
이 섹션에서는 오프체인과 온체인 측면 모두에서 상세한 조사 결과를 제시합니다. "무제한 승인"의 현재 상황을 더 잘 이해하기 위해, 우리는 프론트엔드 사용자의 역할을 맡아 측정을 수행합니다.
실제 승인 과정
위 그림은 프론트엔드 사용자가 승인 트랜잭션을 완료하기 위해 여섯 단계를 거칠 수 있음을 보여줍니다. 네 가지 주요 주체(프론트엔드 사용자, 지갑, 플랫폼, 토큰 컨트랙트)가 있습니다. 이제 단계별로 흐름을 살펴보겠습니다:
1단계, 2단계： 먼저, 대부분의 프론트엔드(모바일, 웹사이트) 사용자들은 자신의 지갑을 선택한 플랫폼에 연결하고 서비스 요청을 보냅니다.
3단계： 그런 다음, 플랫폼에서 사용자의 지갑으로, 플랫폼은 필요한 데이터(가장 중요하게는 승인 금액)와 함께 승인 트랜잭션을 구성하고 확인을 위해 사용자의 지갑으로 전송합니다.
4단계, 5단계： 승인 트랜잭션을 수신한 후, 지갑은 사용자에게 해당 정보를 표시하고 사용자의 확인을 기다립니다.
6단계： 사용자가 트랜잭션을 확인하면, 지갑은 검증을 위해 네트워크에 트랜잭션을 전송합니다. 또한, 검증된 트랜잭션은 토큰 컨트랙트의 상태(Allowance[User][Platform])를 수정합니다.
(다음 섹션에서는 먼저 각 유형의 측정(오프체인 및 온체인)에 대한 동기를 소개합니다. 그런 다음 다양한 측면에서 측정 결과와 발견 사항을 제시합니다.)
오프체인 조사
동기
실제 승인 과정에서, 프론트엔드 사용자들이 지갑과 플랫폼의 사용자 인터페이스와 직접 상호작용한다는 것을 쉽게 알 수 있습니다. 따라서 우리는 잘 알려진 지갑 15개와 24개의 DeFi(탈중앙화 금융) 플랫폼을 선정하여 오프체인 조사를 수행합니다.
(조사 결과는 아래에 표시된 두 그림에 요약되어 있습니다.)
또한, 우리는 주로 승인에 대한 설명과 유연성을 고려합니다:
- 설명
- 지갑: 1) 지갑이 승인 트랜잭션의 적절한 정보(사용자, 지출자, 토큰, 승인 금액 포함)를 표시하는지 여부; 2) 지갑이 "무제한 승인"에 대해 특별한 경고를 제공하거나 사용자에게 알리는지 여부
- 플랫폼: （기준 1）플랫폼이 웹 UI에서 승인 트랜잭션에 대한 적절한 설명을 제공하는지 여부; （기준 2）플랫폼이 사용자에게 승인 트랜잭션의 존재를 알리는지 여부; （기준 3）플랫폼이 사용자에게 두 개의 트랜잭션이 순차적으로 실행된다는 것을 알리는지 여부
- 유연성: 지갑이든 플랫폼이든, UI가 승인 금액에 대한 수정 기능을 제공하는지 여부
(다음 섹션에서는 위의 두 가지 측면이 지갑과 플랫폼 모두에서 어떻게 수행되는지 결과를 보여줍니다. 지갑과 플랫폼 각각에 대해 두 가지 사례를 선택합니다.)
0x222. 지갑: Metamask & Coinbase
우리는 Coinbase 지갑과 Metamask(크롬 확장 프로그램) 지갑에 대한 조사 결과를 제시합니다. Google Play 스토어의 정보(아래 그림 참조)에 따르면, Coinbase와 Metamask 모두 100만 회 이상의 설치 수를 기록하고 있습니다. 그런데 Coinbase는 더 많은 고객 리뷰를 받았으며 더 높은 점수를 기록하고 있습니다.
두 지갑 조사를 위해, 우리는 Compound 플랫폼의 스왑 기능을 테스트하는 데 사용합니다. Compound 플랫폼은 기본적으로 사용자에게 무제한 승인을 설정합니다.
지갑 1: Metamask
아래 그림에서 볼 수 있듯이, 사용자들이 Compound에서 구성한 승인 트랜잭션을 검토하는 동안, 지출자 주소, 승인 서명, 승인 금액(2단계)을 포함한 완전한 정보를 기본적으로 확인할 수 있습니다. 더욱이, Metamask는 사용자가 "편집" 버튼을 통해 승인 금액을 수정할 수 있도록 허용합니다(2단계, 3단계, 4단계).
지갑 2: Coinbase
Metamask 지갑과 비교하여, Coinbase 지갑은 중요한 정보를 전혀 표시하지 않습니다. 사용자는 승인 트랜잭션을 확인한 후에야 더 많은 세부 정보를 확인할 수 있습니다(아래 그림). 2단계, 3단계, 4단계는 승인 트랜잭션이 대기 중이거나 완료된 상태일 때만 표시됩니다. 따라서 Coinbase 지갑은 승인 트랜잭션의 필요한 정보를 숨기고 승인 금액에 대한 수정 기능을 제공하지 않습니다.
0x223. 플랫폼: Bancor & Curve Finance
이 섹션에서는 Bancor와 Curve Finance를 비교할 것입니다. 아래 그림에서 볼 수 있듯이, defipulse의 최신 통계(2021년 8월 7일 기준)에 따르면, Curve Finance와 Bancor는 총 잠금 가치 기준으로 각각 1위와 5위의 DEX(탈중앙화 거래소)입니다.
두 플랫폼 조사 설정을 위해, Metamask 지갑을 사용하여 두 플랫폼이 제공하는 스왑 기능을 테스트합니다.
플랫폼 1: Bancor
Bancor에서 스왑 기능을 테스트하는 동안, 승인 트랜잭션의 필요성을 설명하고(아래 그림) 사용자에게 두 가지 옵션(무제한/제한 승인)을 제공합니다. 무제한 승인 외에도, Bancor의 제한 승인은 사용자가 스왑에 사용하려는 정확한 allowance 금액만 요구합니다.
플랫폼 2: Curve Finance
그러나 Curve Finance에서는 '흥미로운' 일이 발생합니다. 아래 그림에서 볼 수 있듯이, 스왑을 요청하는 동안 Curve Finance의 UI는 **"10 USDT를 거래소에 승인해 주세요"**라고 표시하지만(아래 그림), Metamask는 무제한 승인 트랜잭션을 수신합니다. 이는 사용자에게 명백히 오해를 유발하는 정보입니다.
이후, Curve Finance에 해당 문제를 확인하려고 시도했을 때, 그들은 우리의 우려를 인정하면서 이는 **"사용자들이 매번 승인하는 것을 좋아하지 않기 때문"**이라고 말했습니다(아래 그림).
Curve Finance와 마찬가지로, Yearn Finance의 UI도 동일한 문제를 가지고 있습니다. (우리는 발표에서 이를 언급하고 증거를 제시했습니다.)
0x23. 온체인 조사
0x231. 동기
체인 상의 "무제한 승인" 상황을 더 깊이 이해하기 위해, 우리는 (2021년 4월 30일까지의) 모든 트랜잭션을 수집하여 조사를 계속합니다. 아래 그림에서 볼 수 있듯이, "무제한 승인"의 수가 최근 매우 빠르게 증가하고 있습니다. 우리의 조사에서, UniswapV2의 도입이 "무제한 승인" 성장을 촉진하는 주요 요인으로 보입니다. 측정 결과를 바탕으로 이 점에 대해 더 자세히 설명하겠습니다.
동시에, 토큰과 플랫폼 모두의 관점에서(사용자 자신보다 가장 관련된 용어이므로) "무제한 승인"을 탐색하기 위해, 두 가지 측면에서 조사를 수행합니다:
- "무제한 승인"의 분포
- 위험 분석
0x232. "무제한 승인"의 분포
아래 그래프를 이해하는 데 도움이 되도록, 그림에서 언급된 각 용어를 먼저 설명합니다:
- Y축 (최대 승인 비율): 값이 클수록 -> 전체 승인 트랜잭션 중 "무제한 승인"의 비율이 높음
- X축 (활성도): 값이 클수록 -> 플랫폼이나 토큰이 더 활발함. 활성도 값은 승인 트랜잭션 수와 첫 번째 및 마지막 승인 트랜잭션 사이의 시간 차이에 따라 결정됨
- 점 크기: 크기가 클수록 -> 토큰 또는 플랫폼이 더 많은 승인 트랜잭션에 관여됨
(아래 두 그림은 승인 트랜잭션에 가장 자주 관여된 상위 1000개의 토큰/플랫폼만 보여줍니다)
（플랫폼）
（토큰）
플랫폼: 플랫폼 그래프를 보면, UniswapV2가 세 가지 측면 모두에서 다른 플랫폼들을 명백히 압도하고 있습니다. 이것이 바로 우리가 **"UniswapV2의 도입이 '무제한 승인' 성장을 촉진하는 주요 요인으로 보인다"**고 주장하는 이유입니다.
토큰: 분포 측면에서, USDC, USDT, DAI는 위에서 정의한 세 가지 측면 모두에서 가장 좋은 성과를 보입니다. 이 토큰들은 모두 스테이블 코인으로, 스테이블 코인이 암호화폐 시장에서 거래 수행에 일반적으로 사용된다는 점을 감안하면 당연한 결과입니다. 다른 주목할 만한 토큰들(상위 10개 토큰)은 최대 승인 비율 측면에서 매우 유사합니다.
0x233. 위험 분석
이전 결과에 따라, USDC, USDT, DAI(상위 3개 토큰)와 두 플랫폼(Bancor, UniCat)을 선정하여 위험 분석을 수행합니다. 동시에, 승인된 토큰의 위험을 명확히 이해하는 데 도움이 되도록 두 가지 용어를 정의합니다(아래 그림 참조).
위험 금액
- 토큰의 경우, 위험 금액은
transferFrom함수를 호출하여 전송될 수 있는 토큰의 총량과 같습니다 - 플랫폼의 경우, 위험 금액은
transferFrom함수를 호출하여 전송될 수 있는 단일 토큰의 총량과 같습니다
위험 비율
- 특정 토큰을 기준으로, 위험 비율은 해당 고정 토큰의 총 공급량에 대한 위험 금액의 비율을 나타냅니다
토큰： 아래 그림에서 볼 수 있듯이, USDC와 USDT는 1년 반 동안 상당히 안정적입니다(위험 비율이 약 10% 수준). DAI는 연중 중반에 급격한 하락을 경험한 후 결국 안정세를 찾습니다(역시 약 10%이나 변동이 더 많습니다). 이 현상은 특정 이벤트나 DAI의 작동 메커니즘을 나타낼 수 있습니다. 따라서 우리가 그 원인을 탐구하기 위해 해야 할 작업이 아직 남아 있습니다.
플랫폼： 플랫폼에 대한 위험 분석에 대해, Bancor(BNT 토큰)와 UniCat(UNI 토큰) 모두의 위험 금액 추세 그래프(아래 그림)를 제시합니다.
Bancor의 추세 그래프는 즉각적인 증가와 하락을 보여줍니다. 이는 팀이 버그가 있는 컨트랙트에서 취약한 토큰을 안전한 곳으로 얼마나 빠르게 이전했는지를 완벽하게 보여줍니다.
UniCat의 추세 그래프에서는 몇 가지 명백한 하락이 실제로 UniCat의 백도어 공격으로 인해 발생했음을 확인합니다.
0x3. 기존 솔루션
앞서 언급했듯이, "무제한 승인"은 오랫동안 생태계에서 존재해 온 주제입니다. 다양한 논의를 통해, 승인 과정을 개선하기 위한 몇 가지 솔루션이 실제로 제안되었습니다:
- ERC777
- EIP2612
솔루션에 들어가기 전에, "무제한 승인"의 근본적인 동기를 다시 한번 상기시켜 드리겠습니다:
- approve/transferFrom 모두에 두 개의 트랜잭션이 필요합니다
- 맞춤형 승인은 사용자가 거래나 입금 전 매번 승인하도록 강제합니다(즉, 더 많은 트랜잭션 수수료를 지불해야 함)
- 플랫폼은 한 번의 무제한 승인을 요청함으로써 사용자 경험을 극대화하려 합니다
0x31. ERC777
2017년에 제안된 토큰 표준인 ERC777은 ERC20 토큰의 승인 과정을 개선하기 위해 다음과 같은 특징을 가지고 있습니다:
- 사용자는 원하는 금액으로 자신의 토큰을 전송할 수 있도록 운영자(예: 거래소)를 "승인"할 수 있습니다
- 사용자는 반복적으로 승인을 위한 트랜잭션을 제출할 필요가 없습니다
- 사용자는 "무제한 승인"의 위험에 대해 걱정할 필요가 없습니다
결론적으로, ERC777을 통해 사용자는 승인된 운영자와 함께 원자적 구매를 달성할 수 있습니다.
그러나 ERC777의 단점도 명확합니다:
높은 트랜잭션 수수료. 표준에 적용된 훅으로 인해(자세한 내용은 여기를 참조하세요). 사용자는 신뢰할 수 있는 운영자를 선택해야 합니다(이는 다시 사용자에게 질문을 던집니다).
0x32. EIP2612
EIP2612에 대해, 이 제안에서 저자는 사용자가 서명된 메시지를 트랜잭션 검증에 사용할 수 있어 allowance를 수정하기 위한 트랜잭션 수수료를 지불할 필요가 없다고 설명합니다. 더 직접적으로 말하면, EIP2612를 통해 승인 트랜잭션은 무료가 됩니다. 더욱이, 이 제안은 현재 UniswapV3의 대출 공급자 토큰에서 사용되고 있습니다.
0x4. 결론
결론적으로, "무제한 승인"은 사용자가 여러 승인 트랜잭션을 실행하는 비용을 실제로 줄여줍니다. 그러나 우리의 조사를 통해, 일부 플랫폼과 지갑은 편의성과 보안의 싸움에서 여전히 무해한 척하고 있습니다. 더욱 나쁜 것은, 그 중 일부는 잘못된 정보를 표시하여 사용자를 오도하려 한다는 점입니다. 따라서 "무제한 승인"을 사용하는 대신, 플랫폼과 지갑이 처음부터 사용자를 보호하기 위해 더 안전한 UI나 프로토콜 개발을 진지하게 고려해야 한다고 제안합니다. DeFi 사용자로서, 보안 의식을 구축하는 것은 익스플로잇의 결과가 아니라 처음부터 인식을 갖는 것이어야 합니다. 우리는 이더리움에서 안전하고 번영하는 환경을 구축하는 것이 커뮤니티의 책임일 뿐만 아니라 우리 각자의 책임이라고 믿습니다.
