2. Incentive Token Community_MulX

MulX community concept

Untitled

Flow Chart
System Architecture
DB Schema

API Docs

Category	Method	EndPoint	기능
home	GET	/	홈 (없음)
USERs	POST	user/signup	회원가입
	POST	user/login	로그인
	GET	user/:email	회원정보 조회
POSTs	POST	post	게시글 작성
	GET	post	모든 게시글
	GET	post/:post_id	특정 게시글 (post_id)
	GET	post/search/email/:email	특정게시글 (email)
	POST	post/search/nickname	특정게시글 (nickname)
	PATCH	post/update	게시글 수정
CONTRACTs	POST	contract/faucet	테스트 ETH 받기
(요청할 때마다 0.1 ETH 전송)
	GET	contract/faucet/:address	테스트 ETH 조회
	POST	contract/token	ERC20 토큰 보상
	GET	contract/token/:address	ERC20 토큰 조회
	POST	contract/transfer	ERC20 토큰 전송
NFTs	POST	nft/mint	NFT 발행
	GET	nft	모든 NFT data
	GET	nft/:address	특정 NFT 조회 (address)
	GET	nft/search/:tokenId	특정 NFT 조회 (tokenId)
	POST	nft/price	보유 NFT 판매가 변경
	GET	nft/price/:tokenId	특정 NFT 판매가 조회
	POST	nft/buy	ERC20 토큰으로 NFT 구매

회원가입
로그인
회원정보조회
게시글 작성
모든 게시글 data
특정 게시글 (post_id)
특정 게시글 (email)
특정 게시글 (nickname)
특정 게시글 수정
테스트 ETH 받기 (요청할 때마다 0.1 ETH 전송)
테스트 ETH 조회
ERC20 토큰 보상
ERC20 토큰 조회
ERC20 토큰 전송
NFT 발행
모든 NFT data
특정 NFT 조회 (address)
특정 NFT 조회 (tokenId)
보유 NFT 판매가 변경
특정 NFT 판매가 조회
ERC20 토큰으로 NFT 구매
시나리오 테스트
시연영상
Git repo
- https://github.com/codestates-beb/beb-09-second-mulX
Backend 기술스택
- Node.js (express framework)
  - multer: image file frontend 와 DB 에 저장 및 응답 위한 middleware
  - ethers.js: Ethereum 기반 블록체인과 상호작용 library
- sequelize (ORM)
- MySQL (DB)
- NFT.storage (IPFS: metadata 와 url 을 하나로 묶어서 저장 및 응답)
- Smart contract
  - Hardhat
  - node
    - local: ganache
    - testnet: Sepolia
      - All that node api: testnet 연결
Review
- 학습과정 중에 가장 어렵게 느껴지던 back-end 쪽을 자원하여 진행
- express framework 기반으로 sequelize 사용해서 MySQL에 연결하고 스마트 컨트랙트는 Hardhat을 사용해서 진행 (기본 익히는 데 중점)
  - 개인적으로 Hardhat 을 익혀서 단위 테스트, 시나리오 테스트를 hardhat 으로 해보려 했는데 시간과 역량 부족으로 Remix와 etherscan으로 보면서 함
- 최소한의 기능만 넣었지만 API 만드는데 허덕허덕
  - API Docs 하고 실제 코드하고 신경쓴다고 써도 실수 및 Frontend 와 mismatch 발생
  - Backend 개발이 최대한 빨리 진행되야 Frontend 와 맞춰볼 수 있는 시간확보 가능
    - backend 는 postman 으로 상당부분 frontend simulation 이 가능하지만, frontend 의 경우 dummy 로 simulation 하기에는 부가적인 작업이기도 하고, 맞췄을 때 안 맞는 부분이 생기는 것 같음.
- Smart contract 구현할 때 ERC20 토큰으로 NFT 구매 기능이 생각보다 까다로움
  - ERC20 transferFrom 을 위해 sender 가 smart contract 주소에 구매금액 approve
  - ERC721 transferFrom 을 위해 owner 가 smart contract 주소에 approve
    - NFT 구매를 위해 ERC20 approve 하고 ERC721 계약을 연달아 호출해서인지 nonce 가 종종 꼬이는 문제발생 → 지갑을 ethers의 NonceManager 사용하여 관리
      - const nonceBuyerWallet = new ethers.NonceManager(buyerWallet);
    - 구현: mint 할 때 NFT가 발행자에게 minting되면 발행자는 바로 smart contract 에 approve 하게 구현 → 판매금액에 맞춰 다른 구매자가 사면 무조건 사짐 (살때마다 조금씩 가격이 높아지도록 추가기능 생각만 함) → owner 가 안팔고 소장하고 싶으면 문제발생(발표시간에 질문나옴 but 생각하고 있던 부분) → owner 가 판매금액을 설정하는 기능 api에 추가 (판매금액을 완전 높게 설정하면 구매의욕 X) → 등산 난이도에 따른 기준으로 NFT 판매금액이 정해지는 concept 에 위반하는 문제발생 → owner 의 판매금액설정 기능은 api 만 존재하고 frontend에서는 반영하지 않음→ mulX 구성원은 자신의 등반 노력을 MulX token을 최대한 확보하여 부자되는 것이 목표(소장보다는 NFT 판매가 활성화되어 수익을 높임)라고 생각하고 정신승리(이겼다!!!) → token economy는 잘 설계해야 한다는 교훈
- ganache 로 기능구현 완료하고 마지막날 testnet (sepolia)에 올림
  
  (위 시나리오 테스트는 최종 버전은 아니지만 큰 틀에서는 비슷함)
- testnet 환경이었는데도 배포 및 tx 에 따라 ETH 수수료가 부담 됨
- 일반 tx 와 smart contract 배포에 따른 ETH 수수료 차이를 느꼈음
  - 상태변화 보려고 get 함수를 많이 넣었는데, testnet 이니까 하고 그냥 삭제 없이 올린 것도 원인 중 하나 → smart contract 는 최적화가 개발비와 직결
  - 작은 프로그램인데도 몇 십배 이상은 차이 남
  - Ethereum은 지금 현재 시점 기준 가스비로 인한 한계 존재. layer 2 향방 주시필요
    - ETH 보유자는 가격이 올라가기를 기대하지만, 올라가면 가스비 비용상승으로 인한 서비스 제공자의 부담으로 타 체인 이탈 가능성이 높아짐
- 블록체인 실시간 tracking 기능 역시 구현해보고 싶었는데 아쉬움
- 총평
Reference