Issue. 12: 컨트랙트 개발자가 알려주는 approve & allowance, ERC20Permit, Permit2 기본 개념 익히기

DApp을 써봤다면 예치하기 전에 먼저 얼마를 'approve' 하라는 팝업 창을 한번쯤은 봤을 것임. 그리고 approve 트잭을 보내면 귀찮게 예치 팝업이 그 후에 뜨고 그제서야 예치를 할 수 있음. 오늘은 그것과 관련된 얘기를 좀 해보려고 함. 왜? 의외로 approve, ERC20Permit, Permit2 등을 모르는 사람들이 많아서.

개발자가 아닌 사람도 최대한 이해할 수 있도록 적어보려고 하긴 했는데 모르겠으면 그냥 키워드 이 글에서 얻어서 더 찾아보는걸로.

1. approve & allowance

이게 왜 필요한지부터 설명해보자. 만약 DApp에서 유저가 소유하고 있는 ERC20 토큰을 x만큼 가져오고 싶다면, 가장 간단한 방법은 사실
그냥 유저가 .transfer 함수를 직접 호출해서 DApp 컨트랙트로 보내버리는 것이다.

근데 문제는, 이러면 토큰이 전송될때 컨트랙트가 custom logic을 실행할 수 없다는 점. 예를 들면 ERC20 토큰이 x만큼 들어왔을 때, msg.sender (트잭 쏜사람)의 포인트를 x만큼 온체인에 기록한다든지.

그래서 사람들이 생각해낸게 바로 .transferFrom 란 함수임. 이건 뭐 어떻게 작동하냐면, 유저가 직접 호출하는게 아니고, 유저가 상호작용하고자 하는 컨트랙트의 함수가 .transferFrom을 대신 호출해줌.

예를 들자면 이런 식으로.

function pullTokenFromUser() external {
    IERC20(TOKEN).transferFrom(msg.sender, address(this), 10); // 10 만큼 유저한테로부터 컨트랙트에 ERC20 송금
    points[msg.sender] += 10; // 10 포인트 주기
}

이렇게 하면 유저가 ERC20의 transfer를 직접 호출하지 않고, pullTokenFromUser를 호출하게 됨. 이점은 커스텀 로직이 실행 가능함. 대부분의 DApp들이 이렇게 돌아감.

근데 여기서 중대한 문제는 보다시피, 유저의 ERC20 토큰을 전송할 권한을 유저 본인이 아닌 스마트 컨트랙트가 가지게 된다는 것. 그러면 스마트 컨트랙트가 혹여나 악성 코드가 있거나 취약점이 있다면 누군가가 당신의 토큰을 가져가 버릴 수도 있다. 그래서 가끔씩 텔레그램 채널 보면 어디 해킹 사건 터니면 approve 해놓은거 revoke 하라는 말이 돌아다니는 거다 (https://revoke.cash 참고).

ERC20::approve 가 실행되면 내부적으로는 allowance라는 매핑 안에 유저가 해당 주소에게 전송 권한이 위임된 양을 증가시킨다. 그리고 transferFrom이 한번 호출될 때마다 allowance의 값이 감소하고, 0에 도달하면 에러가 나며 더 이상 전송할 수 없게 된다. 더 위임하고 싶으면 또 approve를 호출하면 됨.

만약 자꾸 쓰다보면 allowance가 계속 낮아져서 계속 approve해야 하는게 귀찮다 싶으면 보통 uint256의 가장 큰 숫자인 type(uint256).max 로 승인을 때려버리기도 한다. 기본적으로 이렇게 승인을 요구하는 DApp들이 많은데, 트잭 보내기 전에 월렛에서 이 값을 내가 직접 수정할 수 있으니 좀 안전하지 않을 것 같은 앱이다 싶으면 꼼꼼하게 체크해서 값을 낮추는게 좋은 방법.

그래서 approve를 꼭 사용해야 할 때 가장 좋은 security practice는 전송되어야 하는만큼만 승인하고, 다음에 또 전송해야 할때 또 approve 하는것임.

2. ERC20Permit

여기까지 읽었다면 approve의 문제가 무엇인지 당신은 이미 알고 있다. 안전하고 싶으면 컨트랙트와 상호작용 할 때마다 a. approve 트잭, b. 실제 컨트랙트 함수 호출 트잭으로 두 번 트잭을 보내줘야 한다. 귀찮고, 가스비도 더 나가고, 시간도 더 걸리고. 아무도 이걸 원하지 않는다.

그래서 사람들이 생각해낸게 ERC20Permit임.

사실 진짜 별거 없고, ERC20를 상속하는 컨트랙트인데 가장 중요하게는 permit이란 함수가 있음. 얘를 사용하면 ERC20::approve랑 컨트랙트의 custom logic을 한꺼번에 실행이 가능하다.

예를 들면 이렇게.

function pullTokenFromUserWithPermit(
    address token,
    uint256 amount,
    uint256 deadline,
    uint8 v,
    bytes32 r,
    bytes32 s
) external {
    // 여기서 approve 해버림
    IERC20Permit(token).permit(
        msg.sender,
        address(this),
        amount,
        deadline,
        v,
        r,
        s
    );
    // 유저한테서 토큰 가져오기
    IERC20(token).transferFrom(
        msg.sender,
        address(this),
        amount
    );
    points[msg.sender] += amount; // amount만큼 포인트 주기
}

근데 뭐가 달라져서 가능하냐면, 유저가 오프체인에서 누가 누구의 돈을 언제까지 얼마를 전송할 수 있는지에 대한 데이터에 서명을 하기 때문임. 서명은 100% 오프체인이기 때문에 가스비가 절대 들지 않음 (월렛에서 팝업 뜨고 버튼은 눌러주긴 해야함).

그러면 그 서명을 컨트랙트 함수에 갖다주면 서명이 올바른지 확인하고, 내부적으로 approve를 바로 실행해주고, 그 후에 바로 transferFrom을 호출할 수 있게 됨.

가장 중요 포인트는 두 번 보내야 하는 트잭이 하나가 된다는 점. permit이 approve를 내부적으로 실행시켜주기 때문에 그 후에 컨트랙트는 동일 트잭 내에서 실행시키고 싶은 로직을 실행시키면 됨.

(여기까지 잘 읽은 분들 중 질문이 생겼을 수도 있다. 그러면 pullTokenFromUserWithPermit 안에서 굳이 permit을 호출하지 않고 approve를 호출하면 되는 거 아닌가? 라는 질문이 들 수 있는데, 사실 이건 단순한 이유로 되지 않는다. 답은 본인이 직접 approve 함수 구현체를 찾아보시길)

3. Permit2

여기까지 읽었으면 수고했음. 이게 마지막임. ERC20Permit를 읽다가 문제를 발견했다면 그게 Permit2의 존재 이유일 가능성이 높다.

ERC20Permit은 가장 고통스러운 게, 이미 배포된 ERC20 토큰인데 ERC20Permit을 사용하지 않는 토큰이면 토큰 컨트랙트를 다시 배포/업글하지 않는 이상 ERC20Permit을 사용할 수가 없음 → 결국 approve & allowance 사용해야 하는 문제로 돌아감. 이거 말고 여러 문제가 있지만 일단 이것만 설명.

Issue. 12: 컨트랙트 개발자가 알려주는 approve & allowance, ERC20Permit, Permit2 기본 개념 익히기 파트 2.

그러면 어떻게 할 수 있느냐? 바로 'Permit2'라고 하는 또 다른 컨트랙트에 송금 권한을 위임하는 것이다. 참고로 Permit2는 공공의 이익을 위해 유니스왑이 그냥 개발, 배포해준 컨트랙트임.

그러니까 내가 상호작용해야 하는 예치 컨트랙트가 있다면, 이렇게 작동하게 된다.

a.
Permit2 컨트랙트에 ERC20::approve를 type(uint256).max로 해버림. 근데 이게 더 이상 문제가 안 됨. 왜냐하면 Permit2는 돈을 마음대로 쓸 수 있는 함수가 없기 때문 (Permit2는 '믿을 만한' 컨트랙트임).

b.
유저인 내가 예치 컨트랙트의 pullToken()같은 함수를 나의 서명을 인자로 호출하게 된다. 그러면 그 예치 컨트랙트의 함수는 더 이상 ERC20::transferFrom(나, address(this), ...) 를 호출하지 않고, Permit2::permitTransferFrom(...)를 호출해준다.

그러면 Permit2는 가지고 있는 무한 allowance 덕분에 내부적으로 ERC20::transferFrom(나, address(예치컨트랙트), ...)를 불러줄 수 있음.

c.
b 단계의 서명은 '누가 누구에게 언제까지 얼마를 송금할 수 있는지'에 대한 정보를 담고 있음. Permit2::permitTransferFrom이 그 서명을 검증하고 유효하면 바로 송금해줌.

요약하자면 ERC20Permit을 상속하지 않는 토큰을 송금하는 건 더 이상 문제가 되지 않음. 유저는 Permit2라는 믿을만한 컨트랙트에게 모든 송금 권한을 위임하고, 송금이 필요할 때마다 호출하고자 하는 함수에 서명을 같이 보내면 서명 검증 후 바로 송금이 됨.

말고도 많은 문제를 해결해 주는데, 그건 걍 직접 확인.

세줄요약

1. ERC20::approve 직접 호출은 가장 원시적인 방법. allowance 무한으로 때려박지 않는 이상 항상 트잭 두 번 보내야 함.
2. ERC20Permit을 상속하는 토큰 컨트랙트를 사용한다면 오프체인 서명으로 approve와 원하는 custom logic을 한 트잭만에 실행할 수 있음.
3. Permit2로 처음에 approve를 한 번만 해주면 ERC20Permit을 상속하지 않는 토큰 컨트랙트도 ERC20Permit과 같이 한 트잭만에 송금하고 싶은 수량을 확인하고 custom logic을 실행시킬 수 있는 이점을 누릴 수 있음.

왜 중요한가

👉 개발자: 되도록이면 개발할때 1은 지양하세요. 두 번 트잭 보내는 건 옛날 메타..
👉 유저: 월렛에서 서명할 때 뭘 서명하는지, approve할 때 무엇을 approve하는지 알고 버튼 누르세요.

최근 자주 하는 것: Aave나 Uniswap 등 Governance 포럼 들어가서 재밌어 보이는 글 확인하기.

트위터는 아무나 뻘글이고 진지글이고 다 싸지르는 곳이라면, governance forum은 한층 수준 높고 차분하고 진지한 분위기라 내용이 오염되지 않았고 DeFi 생태계에 어떤 재미있는 일이 벌어지고 있는지 자세히 알 수 있음.

예를 들어 최근엔 Sky의 USDS를 담보로 더 이상 지원하지 말자는 글을 살펴보고 있음. 이 글을 이해하려면 결국 Sky가 MakerDAO 시절부터 어떻게 지금까지 변모해 왔는지 알아봐야 해서 좋은 공부 주제임.

하여튼 앞으로 포럼에 댓글이나 글도 좀 남겨볼 예정. DeFi 공부할거면 governance 포럼 자주 들려보는 걸 추천함.

폴리마켓에서 안전하게 수익얻기

@Tripleshothero 님이 트위터에 폴리마켓에서 무위험 트레이딩으로 돈을 벌 수 있는 전략을 공유해주셨는데요.

저도 약간 관련된 내용으로 시간차 정보 arbitrage를 통해 돈을 버는 방법에 대해 예전에 혼자 리서치 한 게 있어서 재공유합니다. GTA VI 출시 날짜 마켓이었는데 시장이 뉴스에 반응하는 시간을 조사해 보았습니다. 폴리마켓 API 써가면서 데이터 추적해서 정성스럽게 만들었슴다.

결론은 시장보다 5분만 빨라도 돈을 벌 수 있다는 사실입니다. 뉴스 나온지 5분동안 가격 차트는 큰 반응을 안 했어요. 개발 좀 할 줄 아시면 트위터나 뉴스 자동으로 모니터링 하면서 트레이딩 해보는것도 나쁘진 않을 겁니다.

리서치 링크: https://9oelm.github.io/polymarket-research/gta

월요일을 깨워주는 주피터 (+ Fluid) vs 카미노 (+ 멀티코인 캐피탈) 솔라나 집안싸움 단편극

> 8월 중순 Jupiter Lend 트윗에 담보자산의 isolated risk와 'zero contagion risk' (전염 리스크 0, 그니까 isolated risk를 걍 다르게 말한거임)를 홍보함. 근데 사실 루핑/rehypothetication에 대한 risk도 다 가져가서 isolated risk는 아니었음. 원본 트윗은 삭제된듯.

> 8월 말 Jupiter Lend public 출시 → 출시후 지금까지 1.6B TVL까지 성장. 카미노는 Jupiter lend 출시후 약 1B 정도 TVL이 하락. 경쟁자에게 뺏겼다고 생각할 수 밖에 없는 상황.

> 9/22 솔라나 가격 하락 → 카미노에서 청산이 '507 달러'밖에 일어나지 않았고 안전하다는 트윗을 날림

> 9/23 Jupiter Lend를 함께 만든 Fluid의 코파운더 Samyak이 카미노 트윗은 구라고 explorer를 좀만 살펴봐도 규모있는 청산을 알아볼 수 있다고 트윗. 실제로 예시를 든게 1M, 0.5M 청산. 507달러는 너무했지.

> 9/23 카미노 트윗 지움.

> 11/28 Jupiter lend에서 Save, Marginfi, Kamino의 포지션을 클릭 한번만으로 Jupiter로 옮길 수 있는 'refinance' 기능 출시

> 12/2 카미노 스마트컨트랙트에서 Jupiter 프로그램을 차단해버림 → Jupiter 통해서 refinance 더 이상 불가

> 12/2 Jupiter 대장 Meow 폭발. Open finance의 가치를 훼손한다, 카미노는 자기네 유저 신경도 쓰지 않는다 등. (현재 트윗은 삭제됨)

> 12/7 카미노의 Marius가 Jupiter 거짓말쟁이들이다. 8월 트윗의 Isolated risk는 거짓이다라고 트윗.

> 12/7 카미노 투자사인 멀티코인 캐피탈의 파트너 Tushar가 Jupiter는 isolated collateral의 뜻도 이해하지 못했다. 바보들이라고 트윗.

> 12/7 Jupiter COO가 8월에 올린 트윗이 zero contagion risk는 아니었다며 사과하는 비디오 올림.

> 12/7 솔라나 재단 대장 Lily Liu가 "제발 그만해 나 너무 무서워! 이러다간 다 죽어...!"라고 트윗 올림

👉 $SOL, $JUP, $KMNO 가격 다 망했는데 집안싸움만 계속 하는중. defillama에서 1, 2위를 다투고 있는 이 두 프로토콜의 원한은 쉽게 안 풀릴 것 같음.
👉 경험상 이건 그냥 사실 마케터/소셜 미디어 담당자 잘못이 큼. 내 경험상 보통 소셜 미디어 담당자는 웹3 용어는 알지만 기술적인 깊이는 많이 없어서 검증하고 올렸여야 하는데 그걸 못한듯..

12/17 수 조엘과 커피챗 & 커뮤니티 네트워킹 기회

안녕하세요~ 조엘입니다. 다음주 12/17 수요일 18-22시 강남 localhost:web3 에서

1) 제가 한국 뜨기 전에 저와 간단하게 커피챗 하고 싶으신 분 (DeFi, web3, 취업, 개발, 해외생활 얘기 등)

2) 공통분모를 가진 제 커뮤니티 멤버들과 가볍게 네트워킹 하고 싶으신 분

이 있으실까요? 사인업 부탁드립니돠

https://luma.com/9cfvcmns

이벤트 홍보 그림은 3시간 걸려서 만들었습니다.

특히 해외 웹3 취업/커리어 관심 있는 분들께 많은 공유 부탁드립니다~

저번에 포스트로 올린 김프 모니터 오픈소스로 풀었습니다.

Golang은 2-3년 전(pre-chatgpt 시대)에 거의 처음 배우면서 써본거라 백엔드 코드 퀄리티에 문제가 많습니다 (레이스 컨디션도 있음).

https://github.com/9oelM/arbgrab

개인적 관심이 있으시면 한번 둘러보시죠. Enjoy.

리액트 신종 취약점 두 개 더 발표

*리액트는 개발자들이 애용하는 프론트엔드 라이브러리입니다.

저번주 모든 개발자를 패닉에 빠뜨린 리액트 취약점 React2Shell 그 이후.

한 시간 전 새로운 취약점 두개가 발견되었다고 발표가 있었네요. 물론 React2Shell만큼 크리티컬은 아니지만 무시할 수는 없는 수준의 취약점입니다.

세계최강기업 페북이 유지보수+버그바운티 운영하는 오픈소스 라이브러리도 이런데, 아무나 적는 스마트컨트랙트는 오죽할까요. Food for thought.

솔직히 대부분의 DAO는 토큰 발행과 토큰 효용성 창출을 위한 핑계임. 돈벌자니 토큰 발행은 해야겠고 프로토콜 방향성에 대한 권한 행사는 계속 하고 싶고. 걍 딜레마임. 최근 Aave 사건 보면서 느끼는 점.