Defi 보험 서비스를 제공하는 프로젝트이다.
가격 하락, Lido 언스테이킹 보험 상품을 판매한다.
보험 증서는 NFT 로 발행되어 개인 간 거래가 가능하며 NFT 소유자는 보험금을 청구할 수 있다.
3명의 팀원이 프로젝트에 참여했으며 각자 PM, frontend, smart contract 파트를 맡아 개발을 진행했다.
Github : https://github.com/INSURSAND
Web : https://props-frontend-eta.vercel.app/
Smart Contract : Solidity, Truffle
Frontend : ReactJS, TailwindCSS, Web3.js
프로젝트를 시작하기 전, 현재 운영되고 있는 Defi 보험 서비스를 조사했다.
기존의 Defi 보험 서비스들은 아래와 같은 문제가 있었다.
현재 서비스들의 문제점을 파악하고, 아래와 같은 차별점을 두고 개발했다.
보험 상품은 2가지이다.
10~90% 만큼의 Coverage Ratio 를 직접 설정할 수 있으며, 30일 또는 365일의 보험 기간을 선택할 수 있다.
보험 구매 시점의 자산 가격을 기준으로, 설정한 Ratio 이상 하락하게 되면 보험금을 청구할 수 있다.
Lido 의 이더리움 언스테이킹 출금 최대 대기기간인 5일만큼을 커버해준다.
현재 연결된 지갑의 Lido 출금 Request Id 를 선택하여 원하는 Ratio 를 설정하고 보험을 구매할 수 있다.
NFT 이미지를 통해 보험의 종류, 청구할 수 있는 보험금, 보험 계약 만료날짜 등을 확인 할 수 있다.
이미지를 통해 보험 계약 세부 사항을 확인 후, 보험금을 청구하면 된다.
주로 담당한 부분은 스마트 컨트랙트 개발이었다. 솔리디티에 대한 욕심도 있었고, 내가 제시한 아이디어로 진행하는 프로젝트이기에 더욱 컨트랙트 개발에 대한 욕심이 컸다.
컨트랙트에는 크게 4개로 나뉘었다.
- 거버넌스 투표
- 보험 NFT Mint
- Uniswap
- Lido finance
보험 계약부터 보험금 청구까지의 과정을 간단하게 설명하면,
보험료의 계산은, 어떤 기준으로 해야할지 막막했다.
현재 운영중인 다른 플랫폼도 기준이 명확하지 않고, 운영팀에서 상황에 맞게 조절하는 경우가 많았다.
플랫폼 운영자로써의 기준을 적용할지, 보험 구매자 입장으로써의 기준을 적용할지...
운영자의 입장으로써 보험료를 적용하면 수익은 생기겠지만 보험 구매자가 줄어들 것이고,
구매자의 입장으로 보험료를 적용하면 플랫폼의 수익이 생기지 않아, 보험기금 풀을 유지하기 어려울 것이다..
이 부분은 내가 깊게 생각할 수 있는 분야가 아니라 생각했기에, 단순하게 구매자의 입장에서 만족할만한 가격으로 보험료를 적용했다.
Uniswap V3 Factory dev Documents
현재 토큰의 가격 정보를 가져오기 위해 유니스왑 컨트랙트를 사용했다.
특히 Goerli 테스트넷에서 개발이 진행 중이었기에, 현재 사용 중인 스왑 풀을 찾기가 어려웠다.
그래서, ERC20 을 통해 만든 USDT, UNI, LINK, WETH 와 같은 테스트 토큰으로 직접 스왑 풀을 구성했다.
구성한 스왑 풀에 예치된 토큰의 수량을 확인해서 현재 토큰의 가격을 가져올 수 있게 했다.
이 과정에서 개발자 문서도 읽고, 구현하기 위해 여러 시행착오도 겪어보며 많이 배울 수 있었다.
리도는 유저들이 가장 많이 사용하는 이더리움 스테이킹 서비스 중 하나이다.
리도에 예치된 이더리움을 출금하고 싶을 땐 최소 1일, 길게는 5일의 출금 대기 기간이 소요된다.
사용자는, 출금 대기 기간 중의 이더리움의 가격하락에는 취약할 수 밖에 없다.
리도의 컨트랙트를 통해, 지갑 주소를 인자로 넣어 현재 진행 중인 출금 Request Id 값을 call 한 뒤,
Id 값을 인자로 넣어 진행 중인 출금의 정보를 얻을 수 있었다. 아래 사진처럼.
이 정보를 이용해서 보험료를 계산하고 보험에 대한 정보를 저장하여, 보험금 지급여부를 확인한다.
다행히도, 리도는 테스트넷을 운영 중이었기에 개발자 문서를 읽어보고, 컨트랙트를 하나하나 뜯어보며 보험계약에 필요한 것들을 캐낼 수 있었다.
컨트랙트를 하나씩 뜯어보며 컨트랙트의 보안에 대한 중요성도 느낄 수 있었다.
또한, 프록시 컨트랙트의 구조 그리고 사용하는 이유는 무엇인지, 리도는 어떤 방식으로 출금 대기 기간을
계산하고 스테이킹 보상을 지급하는지에 대해서도 배울 수 있었다.
세분의 심사위원 분들이 좋게 평가해주셨다. 하지만 가장 기억에 남는 한마디는..
웹3 에서는 비즈니스 모델을 만들기 어렵다는 것.
웹2 서비스도 비즈니스 모델을 만들기 어렵겠지만, 특히 웹3 에서는 더욱 어렵다.
블록체인을 쓰지 않아도 되는 경우도 있고 사용한다고 해도 가스비, TPS, 토크노믹스 문제도 있을 것이다.
블록체인과 탈중앙화를 사용한 서비스가 항상 옳은 것은 아니며, 오히려 더 많은 고민을 해야한다는 것.
아쉬웠던 점 부터 몇가지를 나열하자면,
개발 구조 설계
처음부터 컨트랙트 구조를 잘 설계하고 시작했어야 했지만, 무작정 컨트랙트 코드부터 작성하다보니 나중에는 mintNFT.sol
파일에 너무나 많은 코드가 쌓여 Contract Size Limit 을 넘겨 에러가 뜨기도 했다.
어쩔 수 없이 pure
함수들을 governance.sol
파일로 옮겨 import 해서 처리하기도 했다.
프로젝트 기록 미스
Git 은 잘 사용하였으나, 오직 discord 만을 사용하여 팀원들과 소통하여 회의록이 잘 정리되지 않았고, 개발 현황 정리가 되어있지 않아 커밋 메시지로 확인하곤 했다.
Chainlink 사용
ChainLink 의 dataFeed 를 사용하지 않았던 점도 아쉽다. 프로젝트를 시작할 때, uniswap 의 swap pool, dataFeed 둘 다 사용하여 토큰의 현재 가격 정보를 받아오고 싶었지만 시간적 여유가 부족해 사용하지 못하였다.
팀원들과의 협업과 소통이 정말 중요하다는 것을 배웠다. 주 2회 정기 회의에서 기획, 구성에 대한 회의를 하기도 했고, 상시로 통화하며 프론트엔드에서 필요한 call 함수를 만들고 잘 작동하는지 확인하기도 하고, 문제가 생기면 서로 머리를 맞대며 해결방안을 논의하기도 했다. 비록 디스코드의 대화로만 소통을 했지만 매일같이 통화를 하며 개발하다보니 힘들어도 컴퓨터 앞에 앉아있을 수 있었다.
소통만 하고 프로젝트 진행 과정이나 회의록은 작성하지 않아 다음 기회에는 노션을 활용하여 기획, 과정, 결과, 회고까지 정리해야겠다고 생각했다
Uniswap, Lido 컨트랙트 코드나 개발자 문서를 읽어보면서 배운 것이 가장 많다.
Uniswap 은 보험에서 가장 중요한 부분이었기에, 이더스캔에서 컨트랙트 구조를 하나하나 뜯어보기도 하고, 개발자 문서를 읽어보며 CPMM, CSMM 과 같은 AMM 모델을 찾고 직접 설계해보기도 하였고, Slippage 를 최소화하는 방법에 대해서도 찾아보며 DEX 에 대해 많이 배울 수 있었다.
Lido 는 개발자 문서를 읽으며, 우리 서비스에 접목시킬 수 있는 방법이 무엇일지 많이 고민하기도 했다. 마지막에 사용한 컨트랙트는 처음보는 Proxy 컨트랙트라 Proxy 에 대해 공부한 후에 분석하느라 상당히 고전하기도 했다.
현재 운영 중인 dApp 을 보며 어떤 것을 더 배워야 할지, 프로젝트가 끝나면 공부해야 할 방향에 대해서 다시 생각했다. Proxy 컨트랙트, 크로스 체인, AMM 그리고 가장 중요한 컨트랙트의 보안과 Audit 에 대해 공부하며 부족한 지식을 채워나갈 생각이다.
감사합니다. 이런 정보를 나눠주셔서 좋아요.