[블록체인 연구소] <2023 APTOS 서울 해커톤> 참가기 PART. 02
[블록체인 연구소] <2023 APTOS 서울 해커톤> 참가기 Part 1. 먼저보고 가기
근데 사실 아직까지 우리만의 차별점이랄게 없었다.
이때 또 고민의 기로에 놓였다.
이거 저거 다 매시업하고 무근본으로 가느냐
VS
과감히 제외하고 심플하게 가느냐
우리의 결정은 해커톤이니 만큼 이때 하고 싶은거 다 해보기로 했다.
그래서 구현하고자 하는 기능들을 하나씩 적어 최소한의 MVP를 잡아보았다.
먼저 인큐베이팅 플랫폼이다 보니 기본적으로
- DApp 리스트를 보여주는 기능
- 각 DApp 별로 퀘스트를 포함한 상세정보가 포함된 기능
- 퀘스트를 수행하는 기능
- 잘 수행했는지 검증하는 기능
- 지갑연동 기능
- 누적 경험치(포인트)를 확인하고 이를 어디에 써먹을 수 있는지 보여주는 기능
- 실제 포인트로 미니게임이나 기부 등을 수행하는 기능
얼추 이정도는 포함되어야 했다.
그리고 또 하나 중요한 것은 우리 플랫폼은 토큰과 리워드 포인트 그리고 이를 사용할 수 있는 엔터테이먼트까지 포함된 플랫폼이기 때문에 이에 대한 토크노믹스설계가 필요했다.
강민님의 수학과 학력을 이때 뽕 뽑아야지 언제 뽑겠는가?
역시나 강민님은 기존의 디파이 사용경험과 수학적 두뇌를 조물조물하여 다음과 같은 토크노믹스를 설계하였다.
개발 착수
가장 중요한 건 APTOS 해커톤이고, APTOS 스마트 컨트랙트의 근간인 Move부터 최대한 활용해야 했다.
처음엔 우리 프로젝트에서 Move가 어디에 쓰일지, 쓰일데가 있는건지 조차 가늠할 수 없었다.
그래서 온체인 트랜잭션에 해당하는 케이스를 퀘스트를 수행하는 쪽으로 가닥을 잡고, 시간이 남는다면 경험치를 받는 것도 컨트랙트화 하기로 했다.
그래서 사용자가 달성해야 하는 미션1, 2, 3, 4에 그럴싸한 액션들을 설정하고 이를 직접 Move로 구현해주었다.
초기 의도는 1 DApp = 1 Mission 으로 하기로 했는데 현빈님 의견으로 그렇게 되면 컨텐츠가 너무 없어 보이고 차라리 한 댑에서 여러 미션을 달성해 나가는 방법이 좋겠다고 제안했다.
듣고보니, 그리고 실제로도 적용해보니 그 편이 훨씬 알차 보였다.
여기저기서 곡소리가 들려왔다.
안 그래도 신생 플랫폼이나 비주류 언어들은 데이터베이스가 없어 참고할 만한 것도 부족한데 Move는 에러를 숨쉬듯 뱉어내지··· 구글링 해봤자 건질만한 것도 없지···
거의 이 Move 담당자들은 학습과 현업과 개발을 그 짧은 시간에 병행해야만 했기에 버틴것 만으로 대단하다고 봐야 한다.
이거 준비하면서 어디선가 Move 개발자 LEAK으로 Move 개발자 시급이 $1200까지 올랐다는 공식보도(를 했다는 어떤 포스트)를 보며 설마 설마하면서 웃었는데, 어쩌면 진짜였을수도 있다고 시간이 지날수록 실감이 났다.
물론 지금은 시간이 많이 흘러 많이 떨어졌겠지만 ANYWAY.
현빈님의 경험에 따르면 맨 처음엔 백서를 읽어볼 때도 도식을 이해하기 어려우셨다고 한다.
월렛 월렛 코인 코인 마이코인 마이코인···?
이게 무슨···
주소는 또 왜 저렇게 생겼고···?
모듈 굴러가게 하는 것 자체는 앱토스 샘플코드나 다른 서비스 모듈코드같은 레퍼런스가 어느정도 있어서 크게 어렵진 않았다.
생각보다 컴파일러도 친절해서 좋았고.
다만 type-argument 같은 개념도 아직 많이 헷갈려서 해커톤이 끝난 이후에도 앱토스와 친해지기 위한 추가적인 연습은 과제로 남아있다.
우여곡절 끝에 최종적으로 Move 쪽은 승용님과 현빈님께서 총 4개의 함수를 담은 모듈을 구현하여 배포해주었다.
Fn1: $(module_addr)::proto01::claim_money
Fn2: $(module_addr)::proto01::swap_money_to_dao
Fn3: $(module_addr)::proto01::lock_dao
Fn4: $(module_addr)::proto01::claim_nftTarget chain은 데브넷을 활용하여 테스트를 진행했고 APTOS는 무제한 faucet을 받을 수 있어서 테스트 트랜잭션을 발생시키기도 수월했다.
- module_addr
0x4cfecf3e217f8d23587150290da32d23121fe364bd9eb5008cb0cd10cc05081f - resource_addr (코인, NFT 정보 보관)
0xcaec1eb1883b2999fcfcb235242e153f28e4a0717005f69f9ca8472f9ccf584d - 모듈 소스
https://testnet.tracemove.io/account/0x4cfecf3e217f8d23587150290da32d23121fe364bd9eb5008cb0cd10cc05081f?tab=modules - 모듈 배포
APTOS Move publish — profile PT1
다행히 우리가 하고자 하는 것들에 대한 샘플들이 여러개 있어서 code flatten만 하여 기능 병합은 이슈없이 구현할 수 있었다.
잠깐, Move contract의 구조와 blockchain interact를 설명하자면,
먼저 interactions for each step & life cycle
- Accepting: Accepting the transaction
- Sharing: Sharing the transaction with other validator nodes
- Proposing: Proposing the block
- Executing and Consensus: Executing the block and reaching consensus
- Committing: Committing the block
위와 같은 5단계의 stage 포함하고있다.
다음 create transaction
요약하자면
- Unsigned txn 작성
- 적절한 salt를 적용하여 서명메시지 생성 후 클라이언트 private key로 위 txn에 서명
- Authenticator를 생성하고 트랜잭션 작성
- 만들어진 트랜잭션을 BCS serialize
의 과정을 거친다고 보면된다.
그리고 Move Structure
APTOS는 컨트랙트 언어로 MOVE를 사용하는데, Move는 토큰 위변조, 이중 지불 등 비정상 행위를 Move 언어 자체에서 처음부터 방지하는 친 스마트 컨트랙트적인 언어이고 일반적인 OOP나 PP프로그래밍 랭기지와는 근본적으로 성질이 다르다.
Move 모듈은 Global State를 업데이트하기 위한 규칙이 정의되어 있고, Account 퍼블리싱, 리소스 타입 선언, sign txn & submitting txn 등 트랜잭션을 처리하기에 최적화된 언어이다.
하나의 모듈안에 여러개의 fn을 선언하고 각각의 functionId와 ARG들을 넘겨 호출하는 식으로 동작한다.
위와 같은 구조에 기반하여 우리는 모듈을 만들어 배포한 후 리소스들을 확보하였다.
해결해야하는 또 하나의 난제 verify
컨트랙트를 실행하여 온체인액션을 하는 것까진 어찌저찌 한다쳐도 이를 어떻게 검증할지가 문제였다.
그래서 레퍼런스들을 리서치하며 다들 어떻게 해결했는지 보려 했는데 이조차도 자료들이 너무 없어 쉽지 않았으나, 강민님이 제안한 솔루션으로 바로 돌파구를 찾아냈다.
검증 방식은 아래와 같다.
- Get account transactions
: 연결된 account로 조회 후 등록된 DApp의 resource account로 맵핑 하여 verify - Get transaction by hash
: API단에서 트랜잭션 발생 후 return되는 tx hash값으로 조회하여 verify
위 조건들을 대전제로 하여 API를 설계했고 결과는 Y/N 형식으로 반환이 된다.
참고로 중복검증을 방지하기위해 별도의 DB를 구축하여 계정별로 flag 필드를 추가하여 verification 로직에 추가해주었다.
