스마트 계약 코드 개요

해당 파일럿 프로젝트는 총 2가지의 SmartContract를 가지고 있습니다.

글을 작성하고, 기록하는 MarketingReception Contract 유저의 보상이 되고, 유저의 지불 수단이 되는 MDX Contract 우리는 지불 수단의 역할을 수행하는 토큰을 만들기 위하여 ERC20 을 사용했습니다.

MDX (MadongX Token)

ERC20 표준을 사용했고 특별한 상황에 대비하기 위한 Pausable, 부정사용자를 막기 위한 BlackList, 관리자용 다중 송금 MultiTransferToken를 추가하였다.

마케팅리셉션

Marketing Contract는 마케팅 수신 동의한 유저에게 보상을 제공한다. 마케팅 수신 동의 관리를 위해서는 추가 데이터가 필요한다. 그래서 우리는 위와 같은 기능들을 RewardPool, UserStore, MarketingReceptionStore 세 가지의 Contract로 분리하였다. 각 Contract는 서로를 호출하지 않으며, 각자 Reward, UserData, MarketingReceptioneData를 관리한다.

개선사항

Gas 비용

Sign Up 처럼 Smart Contract에서는 특정 데이터로 인하여 조건문이 추가 되거나, 함수가 분리 되는 문제가 쉽게 발생합니다. 해당 상황에서도 UserData안에 userCount가 존재하지 않았다면 함수의 갯수가 줄어들고, 유저가 글을 등록할 때마다 호출 하는 함수안에서 검사 되는 조건도 줄어들어 Gas Used by Transaction이 줄었을 것입니다. userCount 변수로 인하여 줄어들 수 있는 Gas와 userCount의 필요성을 계산해볼 필요가 있었습니다.

어뷰징 방지

회원 가입, 마케팅 수신 동의 등 모든 Transaction은 User의 Private Key로 서명 합니다. 이 말은 User가 서비스를 통하여 접근 하는 방법 이외 직접 Contract의 함수들을 호출 할 수 있음을 의미합니다. 하지만 서비스에서 발생되는 모든 Transaction은 Fee Delegated로 작동 하기 때문에 유저에게 Transaction Fee 부담이 없는 반면 Contract에 직접 접근하는 것은 Transaction Fee를 User가 직접 지불해야하기 때문에 User 입장에서도 큰 이익이 없는 행동입니다. 하지만 글을 등록할 때 들어가는 Transaction Fee 보다 작성으로 얻을 수 있는 토큰의 가치가 크다면 User들 Transaction Fee에 관계 없이 어뷰징을 할 것입니다. 이를 가장 쉽게 해결하는 방법은 Transaction을 User의 Private Key가 아닌 관리자의 Private Key로 서명하는 것입니다만, 이것은 어뷰징을 쉽게 방지할 수 있으나, Klaytn의 Fee Delegated를 활용하지 못하는 것이고, '탈중앙화'를 잃는 의미가 될 수 있습니다.