🔥 Solidity - 2
이번에는 ERC-20과 또다른 Defi 스시스왑에 대해서 간략하게 다시 공부를 하였습니다.
🔨 ERC-20 인터페이스
이떄까지 인터페이스라는 역할은 단수히 메뉴판의 역할을 한다고 생각을 하였습니다.
어떠한 함수, 이벤트 등이 있고 부수적으로는 에러코드 또한 작성을 해놓고 사용이 가능한 형태로 생각을 하였지만
이번에 심도있게 공부를 해보면서 이러한 역할도 있지만 부수적으로는 가스비를 절감하는 역할을 할수도 있다는 것을 알게 되었습니다.
A라는 컨트랙트가 인터페이스를 상속하여 함수를 정의하였다고 하였을떄
B라는 컨트랙트에서는 A라는 컨트랙트를 상속하는 것이 아니라 인터페이스를 상속하여
함수를 다시 오버라이딩?? 하는 방식으로 사용가능하다고 합니다.저도 이론적으로만 들어보았고 실제로 행해보지는 않았습니다.
- 왜냐하면 공부해야 할 양이 아직 많이 남아있기 떄문입니다..ㅠㅠ
이런 방식으로 작동시키게 되면 A라는 컨트랙트를 상속하는 것은 A에 있는 모든 코드를 상속하기 떄문에 무거워지지만
인터페이스만을 상속하면 작동하는 부분의 코드는 없기 떄문에 많은 부분에서 가스비를 절감할수 있는것으로 알고 있습니다
🔨 ERC-20 transferFrom
흠... 이전에 transferFrom에 대하여 간략하게 공부를 하였을떄
어차피 DAO형태라면 사용자가 사용할텐데 굳이 이걸 써야해..?? transfer그냥 쓰면 안되나??
이런생각을 하였습니다.
물론 사용하는 입장에서는 굉장히 편하지만 보안적으로는 우수하지 못한 방법이라는 것을 공부하면서 추가적으로 알게 되었습니다.
- 특정 사용자가 악의적인 행동을 하는 행위를 방지하지 못합니다.
그러기 떄문에 _approve를 통해서 CA에 자신이 사용하고자 하는 금액을 맡기는 편이 보안적으로 우수한 거래 방식이라고 생각을 바꾸게 되었습니다.
-
transferFrom이 ERC-20에서 가장 중요한 부분이라고 생각을 고쳐먹게 되었습니다
🔨 ERC-20 unchecked
openzeppelin의 ERC-20코드를 보면 unchecked라는 코드를 확인할수 있습니다.
이전까지는 ERC-20토큰을 사용할때에는 모르는 방법이였기 떄문에 후에 공부해보자하고 그냥 삭제하고 사용을 하였지만
나중에는 까먹은 상태였고...ㅠ 이제 다시 알아가면서 공부를 하게 되었습니다.
결과적으로 말하면 저장용량의 한계로 인해서 발생할수 있는 overflow를 체크하지 않는다는 역할을 합니다.
4byte를 표현하려면 최대 4개의 숫자가 이어서 나와야 합니다
ex - 1111
하지만 2진수로 표현하였을때 4개의 숫자가 표현이 안되는 경우
- 10000
4btye에 모두 담을수 없고 이런 경우에는 overflow가 발생을 하게 됩니다.기본적으로 Solidity에서는 이런 에러적인 부분을 모두 체크하고 넘어가기 떄문에 모든 부분을 검사한다. 라는 의미에서 가스비가 사용이 되고 있습니다.
하지만 절대적으로 overflow가 발생하지 않는 경우에 대해서 그냥 검사를 하지 않으면 그만큼의 가스비가 절감이 되게 될 것입니다.
- 예를들면 큰수에서 작은수를 뺼떄
- uint형으로 받게 되면 무조건적으로 양수가 되기 떄문에 이런 경우에는 unchecked가 포함이 되어야 합니다.
실제로도 ERC-20에서는 이런 부분을 고려하려 코드가 구성이 되어있습니다.
unchecked{
_approve(sender, _msgSender(), value);
}🔨 ERC-20 increase/decreaseAllowance를 사용하는 이유
최근에 추가된 함수로 _allowance의 양을 조절 하는 역할 입니다.
이전에는 단순히 _approve를 통해서 _allowance의 값을 수정을 하였지만 상황에 따라 사용자에게 금전적인 손해가 발생할수 있기 떄문에 이러한 함수를 추가 하였습니다.
A라는 사용자가 _approve를 통해서 1000원을 CA에 저장하였습니다.
이후 다른 사용자들은 1000원 만큼의 금액만 거래가 가능할 것 입니다.
이떄 만약 A라는 사용자가 1000원이 아닌 300원을 CA에 저장하는 것으로 바꾸고자 한다면
그냥 단순히 _approve를 실행시키면 됩니다.
근데 만약 _approve를 실행시키기 전에 다른 사용자가 1000원만큼의 금액을 지불하고 거래가 완료가 되고 A가 이후 _approve를 실행시키면
새로운 300이 생기게 될 것입니다.
- 이때 A는 300원만 사용하고자 하였지만 의도하지 않게 1300이 사용이 된 경우라고 할수 있습니다.이러한 상황을 막기 위해서 위와 같은 함수가 추가가 되었습니다.
이 함수들은 새롭게 금액을 설정하는 것이 아니라 기존의 금액에서 수정을 하기 떄문에 앞서 적은 예시와 같은 최악의 상황을 방지하는 것 입니다.
-
물론 _approve를 사용해도 문제는 없습니다.
🔨 거버넌스 토큰[스시스왑]
코드적인 부분은 다루지 않았습니다.
- 왜냐하면 기획자가 아니다 보니 토큰 지급에 대해서 밸런스 적인 부분이 많으 들어가 있기 떄문입니다.
block_chain을 공부를 하면서 거버넌스 토큰이라는 것에 들어만 보았지 제대로 어떻게 사용되는지는 알지 못하였지만 이번에 스시스왑에 대해서 살짝 발을 담가보면서 좀더 알게 되었습니다.
Uniswap과 같이 Defi시스템을 제공하는 스시스왑은 기본적으로 Uniswap과 같습니다.
- pair pool을 형성하여 거래, 유동성풀 제공 등등
다른점은 무엇이냐 바로 초기 유동성풀 제공자들에게 혜택을 주는 것이 다릅니다.
일단 초기의 유동성 풀에 돈을 예치하는 것은 굉장히 위험한 행위입니다.
- 새로 생긴 토큰을 구매하는 것과 비슷합니다.
- 가격이 어디로 갈지를 모르기 떄문이죠
그러기 떄문에 일단 안정적인 스왑을 위해서는 견고한 유동성이 있어야 하고
저희가 Defi에서 쉽게보는 많은 이자율은 이러한 유동성 풀이 견고하지 못하기 떄문에 발생하는 것 입니다.
이런 시스템적 작동방식을 보면 누군가는 총대메고 먼저 예치를 해야 합니다.
- 초기에는 굉장히 도박적인 시스템 이라고 생각합니다.
스시스왑에서는 이런 초기 제공자 들에게 스시토큰을 지급함으로써 사용자들을 끌어 모았고 해당 스시토큰을 또 예치함으로써 보상을 받는 방식으로 작동을 하고 있습니다.
좀더 현실적으로 예를 들어보자면
어느한 유튜버 A가 있습니다.
A의 유튜브에는 초반부터 댓글을 달아주고 영상을 봐주는 구독자들이 있을 것입니다.
A는 후에 토큰을 발행하여 원하는 네트워크를 구축하였습니다.
- 대표적인 예는 투표 기능, 리액션 제안 기능
A씨는 토큰을 발행할때 자신을 믿고 바라봐준 초기 구독자들에게 일정량의 토큰을 지급해줌으로써 유튜버로써의 삶을 계속 이어나가게 됩니다.
- 이 행위가 자신의 거버넌스 토큰을 초기 인원들에게 주는 스시스왑의 형태를 띄고 있는 것 입니다.이런방식으로 적용 가능합니다.
🔨 거버넌스 토큰에 관한 잡담
사실 제가 ERC-20토큰에서 가장 중요하게 생각하는 부분이 앞서 적은 내용과 비슷함과 동시에 같다고 생각합니다.
어떻게 보면 토큰을 통해서 관리자들이 원하는 행위를 사용자들에게 유도하고
관리자들이 원하는 행위를 해준 사용자들에게 토큰을 지급하는 행위
이러한 행위를 이끌어 내기 위해서 ERC-20토큰이 존재한다고 생각을 하며
이런 행위를 통해서 블록체인 네트워크가 구축이 되는 것 입니다.
제가 블록체인을 좋아하는 이유이자 블록체인이 대단한 기술이라고 생각하는 부분이 결국 ERC-20 토큰인거 같습니다.
ERC-20토큰을 통해서 민주적인 결정 및 부가적인 행동 이런 모든것들이 가능하다보니
정말 재미있는 생태계가 구성이 됨과 동시에 정말 창의적인 사람들이 많은 부분에서 성공할수 있는 기술리 되겠구나 라는 생각이 머리속에 떠나지 않았습니다..
코드적인 부분보다는 저는 이런 블록체인이 만들어 내는 환경을 굉장히 긍정적으로 평가하고 있고 이런 환경을 만들고 싶은 마음이 굴뚝같습니다 ㅎㅎ
앞으로 머 Solidity부분도 공부하고 Golang도 공부하는데에 있어 큰 원동력이 되었던 시간이었던거 같습니다.
감사합니다~!!
