[Dev-Log] 2023 Spring 체인링크 해커톤

드림보이즈·2023년 6월 9일

한줄평 : 승객이 아닌 운전대를 잡았다고 생각하라


0. 오버뷰

기간 : 2023.04.28 ~ 2023.06.08 (6주)

주최 : 2023 스프링 체인링크 해커톤

주제 : 체인링크를 활용한 서비스 개발

팀명 : Trypto

인원 : 5명(프론트 2/백엔드 1/컨트랙트 1/기획 1)

제품 : 여행 계획, 뱃지를 활용한 여행 플랫폼

팀 노션 페이지

팀 깃허브 페이지

피그마 와이어프레임


1. 개발 스택

Front-end : Next & Tailwind

Back-end : Go & MongoDB

(큰 줄기만 포함)


2.개발 내용 : Contract 부분

Trypto의 핵심 서비스를 먼저 알아야 한다.

핵심 기능 1 : GPS에 따른 국가별 뱃지 NFT 발급

  1. 사용자가 '뱃지 받기' 버튼을 클릭
  2. gps를 통해 사용자 위치 정보를 파악
  3. 어느 국가인지 찾아
  4. 해당 국가 nft를 뱃지 형식으로 발급

여기서 컨트랙트는 어떤 부분을 맡아야 하는가?
서버가 없는 DApp이라면 1,2,3,4를 모두 할 수도 있을 것이고,
프론트에서 1,2,3번을 맡을 수도 있을 것이다.

여담이지만 컨트랙트를 작성하면서 느끼는 점이

컨트랙트 코드는 매우 섬세하고 민감하게 작성해야 한다.

장인 정신이 필요하다는 것이다.

왜?

비싸고 느리다.

때문에 컨트랙트 <----> 프론트, 백엔드 간의 "자원 분배"의 발란스가 매우 중요하다.

돌아와서 우리는 프론트,백엔드가 있기 때문에,

1,2 를 프론트에서,
3을 서버에서,
4를 컨트랙트에서 실행한다.

즉 컨트랙트는 NFT 발급만 하면 된다. openzepplin쓰면 5초만에 된다.

물론 해당 국가 메타데이터를 서버에서 주는지, 컨트랙트에서 찾아서 TokenUri를 쓰는지에 따라 또 달라질 것이지만 말이다.
(이 문제는 생각보다 복잡해지는데, 뒤에 따로 다루겠다)

지금은 'NFT 민팅' 기능만 알면 된다.

OpenZepplin Wizard에서 넣고 싶은 기능 넣으면 코드도 짜준다. 개발자 돈 주고 왜 씀?

우리는 컨트랙트 배포 후에 NFT를 계속 민팅하므로 Mintable

dNFT를 지원해야 되기 때문에 URI Storage

기능을 추가했다.

Dynamic NFT라 그래서 ㅈㄴ 새로운 줄 알았는데,
그냥 NFT 메타 데이터를 바꾸는 것일 뿐이다. TokenUri를 수정하는 게 전부다.
뭥미

핵심 기능 2 : 뱃지가 업그레이드되는 DNFT 구현

  1. 한국을 방문해 한국 뱃지가 있는 사용자가
  2. 한국에 재방문을 해서 뱃지 발급 버튼을 누르면
  3. 기존의 한국 뱃지가 브론즈에서 실버로 바뀐다!

나도 안다. 2번이 위화감이 드는게 당연하다.

'첫 뱃지 받자마자 계속 발급 누르면 되는거 아님?'
'GPS 조작하면 되는거 아님?'

오용 방지를 위한 필터를 백엔드나 컨트랙트에 걸 수 있다.

쿨타임을 설정해 놓을 수도 있고, 다른 조건을 걸 수도 있을 것이다.

그런 문제는 잠시 잊고

체인링크 서비스를 이용한 DNFT 구현

이 핵심이다.

앞에서 말했듯 DNFT를 만들려면 해당 NFT의 메타데이터만 바꾸면 된다.

굳이 체인링크 기능들을 쓸 필요가 없다. 사족이다.

억지일 수 있지만 복잡하게 갈 것이다.

  1. 백엔드에서 필터를 통과했다면
  2. 컨트랙트에서 해당 NFT id의 레벨을 +1 하며 mapping에 추가한다.
  3. 1분마다 Automation을 실행해서
  4. NFT id의 레벨이 1,2(실버,브론즈)인 모든 NFT의 메타데이터를 바꿔준다.
  5. mapping을 초기화 해준다(안 그러면 1분마다 이미 적용한 애들도 또 적용을 할테니)

체인링크 Automation === setInterval 이다.

다만 블록체인 위에서 작동하는 setInterval 이다.

해당 컨트랙트 주소를 알려주면, 체인링크 노드들이 주기적으로 컨트랙트에 적혀 있는

'PerformKeep'이란 함수를 실행하는 게 전부다.

여기서 살짝 심화로 들어가자면, 메타데이터를 바꾼다고 하지 않았는가?

저 메타데이터는 어디에 저장되어야 할까?
반드시 컨트랙트에 포함되어야지,
서버에서 값을 받아올 수 없지 않는가?
그렇다면 200국가면 200 x 2(실버,브론즈) = 400개의 uri를 배열로 저장해야 되네?
가스비 1억 나오겠네?
정말 Dapp에 적합한 서비스인가 생각해보자.

핵심 기능 3 (실패) : VRF를 이용해 유저에게 선물 교환권 NFT 발급

쉽게 말해
일정 주기로, 뱃지를 소유한 유저 중에서 랜덤으로 뽑아 선물 교환권 NFT 발급이다.

예를 들어,
1시간 마다 가방 NFT를 랜덤으로 한 사용자에게 발급해주고,
이를 사용하면 NFT를 0x0에 보내 소각하고
실물 가방을 보내주는 로직이다.

여담으로
말은 쉽지만 기획과 개발은 매우 어려웠다.
VRF를 쓰긴 써야 하는데, 프론트 백엔드는 너무 바쁘니,
기획에 말이 되면서, 개발은 쉬우면서,
아다리가 척척척 맞는 그런 아이디어가 필요했다.

그래서 생각한 것이 뱃지 형태로 이벤트 전용 NFT를 만들면 어떨까 였다.
프론트, 백엔드 아무 것도 안해도 된다. 컨트랙트만 만들면 된다.
이벤트 페이지 따로 없이 유저는 뱃지 페이지에 어느새 NFT가 추가되어 있는 것이다.
(물론 사용하려면 UI도 만들고 서버는 컨트랙트 함수 실행시켜야 겠지만)

다시 돌아와서
뱃지가 많은 사용자일수록 당첨 확률이 올라간다.
전체 nft 중에 1개를 뽑고, 그 주인을 찾는 로직이기 때문이다.

일정 주기 = Automation

랜덤 = VRF

위에서 말했듯 DNFT 기능으로 Automation 주기는 1분이기에,
컨트랙트에 따로 시간 측정 변수를 두고 10이면 실행시키는 함수를 만들면 될 것이다.

그러나 구현에 실패했다. 원인도 못 찾았다.

Automation 기능에 VRF를 넣어서 그런가,
너무 가스비가 많은지, 아니면 원래 1개의 컨트랙트에서 같이 못 쓰는 건지
Automation은 1분마다 실행되는데
10분마다 VRF가 실행되고 랜덤값을 받아오면 되는데 이 과정에서 Pending...이 뜨다가 실패한다.

자세한 원인은 직접 체인링크 엔지니어에게 물어보던지 해야겠다.

그냥 기능 4 : Data Feed로 환율 불러오기

여행 플랫폼에 환율 정보가 없으면 쓰랴.

유로 / 달러 환율을 체인링크 DON에서 제공하는 Data Feed 기능을 사용해 구현했다.

체인링크 노드들이 여러 곳에서 데이터를 취합한 신뢰성 높은 데이터다.

각 기능의 코드와 기술적 부분은 다른 포스팅에서 다룰 예정이다.


3. 배운점

  1. 해커톤이란 이런 것이구나
  2. 체인링크가 무엇이고 어떤 기능들을 하는지
  3. 솔리디티 능력치 향상
  4. 스마트 컨트랙트 프레임워크 : Foundry, Hardhat 학습,사용 경험
  5. 팀 플레이 경험치
  6. 테스트 프레임워크 Mocha, Chai 학습, 사용 경험
  7. 영어 능력 향상
  8. 새로운 기술 접한 경험 (Flow, Truflation, Space & Time)

4. 느낀점

전체적으로 아쉬워... 6.8 / 10 느낌

위에서 적었던 좋은 점들도 많았지만, 전체적인 느낌은 아쉽다.

4명은 취준생, 1명은 직장인이라 전력투구를 할 수 없었다.

  • 스케쥴도 다 다르고 우선순위 일이 있다 (취업 준비 / 직장 일)
  • 모두 해커톤 첫경험이다.
  • 새로 공부해야 할 내용이 많다.
  • 기간이 너무 길어서 오히려 마이너스다.

아쉬운 이유는 다 필요없고 하나다.
내가 열심히 안 했기 때문이다. 못한건가 안한건가?
살짝 애매하다. 잘 모르겠다.
이렇게 물어보자.
운전석에 앉았는가, 뒷자리에 앉았는가?
아무리 봐도 앞에 앉은 것 같진 않다.

물론 강의 영상 정리해서 공유하고, 자료도 얼마 없는 새로운 기술들 공부한다고 뺑이 친건 수고했다. 근데 내가 맡은 파트도 100% 완수를 못하고, 다른 파트에 도움을 주지 않은 것 같아 마음이 좀 그렇다. 나는 정말 앞에 앉아야 하는 스타일인가 보다.

1. 아이디어는 이미 80% 나와 있어야 한다.

시작 전에 이미 틀을 잡아놔야 한다. 안 그러면 이리 치이고 저리 치이고
기획에만 몇 주를 잡아 먹는다.
아이디어는 누구나 낼 수 있다. 동네 꼬마도 낼 수 있다. 기획자고 개발자고 상관없다.
모두의 목소리가 같은 힘을 가진다. 하나가 정복하기까지 시간이 매우 오래 걸리는게 당연지사.

세세한 디테일까지 어느정도 나와 있는 아이디어를 제시해놔야 순항한다.
거기에 여러 의견을 반영해 살을 붙이는 거지.
맨땅에서 아파트를 짓는게 아니라, 있는 아파트를 재개발해야 배가 순항한다.

2. 개발은 마지막에 김밥을 마는 부분이다.

김밥을 쌀 때 어떻게 하는가?

햄 잘라서 구워 놓고, 계란 풀어서 지단 부쳐서 잘라 놓고, 단무지 잘라놓고...

재료를 다 준비해 놓는다. 그리고 마지막에 모아서 말기만 하면 된다.

개발도 마찬가지다. 다른 준비를 완벽하게 해둔 뒤에 개발을 해야 한다.

김밥을 말다가 햄이 덜 구워졌다. 김밥 풀고 햄 다시 부치고 다시 넣어서 말고....

이 얼마나 비효율적인 프로세스인가?

시니어 멘토 분 말 틀린게 하나도 없다. 개발은 며칠이면 다 한다. 기획을 확실하게 끝내놓고 들어가야 낭비를 안한다.

개발 얼른 시작하고 싶은 마음은 알겠는데, 그 전에 플로우 차트, API 명세서, DB 스키마 모두가 붙어서 끝내고 넘어가야 한다. 반드시, 반드시

3. 항상 운전대를 잡았다고 생각해라

버스탈 생각 하지마라. 몸은 편한데 마음이 안 편하다. 그럼 결국 몸도 불편하다.
리더가 아니더라도 운전대를 잡았다고 생각하라.

profile
시리즈 클릭하셔서 카테고리 별로 편하게 보세용

0개의 댓글