ZUTTO MAMORU(ずとまも)は「幼馴染との一生を」をコンセプトにかかげる成長型のNFTプロジェクトです。1人の小学生の女の子から始って、大人になり結婚し、墓場に入るまでのストーリーが描かれており、イラストが変化していきます。 ファウンダーは、tochiさん、デザイナーにまもるさん、ジェネの生成になおこママさん、監査にmasatakaさんとルブライトさんが参加しています。僕は、スマートコントラクトとフロントエンドの開発を担当しました。
- MY ROLE
- Front End Engineer
- Smart Contract Developer
- STACK
- Solidity
- Hardhat
- Next.js
- TypeScript
- Tailwind CSS
- Mantine
- viem / wagmi
- ethers.js
- Alchemy
CHAPTER 1
実装した機能
スマートコントラクト
- ERC721Aで複数ミントのガス代の軽減
- ダイナミックなtokenURIの実装
- 本体のNFTが移動したら紐付いているSBTも一緒に移動する
- ERC-4906でメタデータをリフレッシュ
- アクセスコントロール
- 詐欺防止機能とコントラクトブロックの実装
- プレセールを複数回実地できるようにする
フロントエンド
- マークルツリーによるユーザーがNFTを購入できるサイトの構築
- 枚数を指定してNFTを購入できる
上記の通り、ファウンダーの要望で普通のNFTと比べてスマートコントラクトは、かなり複雑なものになりました。
CHAPTER 2
スポットライト
本体のNFTが移動したら紐付いているSBTも一緒に移動する
当時、EIPで要件を満たせる規格を探しましたが、見つかりませんでした。 なので、最初は、ERC-5192をベースにゼロから作るつもりでしたが、EIPを漁っていたらERC-998という、ERC-721にコンポーザビリティ機能(他のトークンなどと接続できる機能)を持っている規格を見つけました。
ERC-998をそのまま使用することはできませんが、他のトークンと紐付ける部分のコードを参考にして、ERC-5192と組み合わせれば、要件を満たせるのでは?と仮説を立てました。結果はうまくいき、本体のNFTと子供のSBTを紐付けさせて、本体が移動したら一緒に移動するSBTを作ることができました。
コントラクトを用途ごとに分ける
今回のプロジェクトでは、コントラクトを機能ごとに分割し、合計6個デプロイしました。 コントラクトを分けた理由は、コードの可読性の向上、コントラクトのサイズの対策、コントラクトのアプデをできるようにするためです。 また、管理者が操作する重要な関数を一箇所にまとめることで、onlyOwnerをつけ忘れるなどのケアレスミスが起きにくくなるようにしました。
CHAPTER 3
チームとユーザーからのコメント
無事にフリミンスタートできたのもエンジニアさんのおかげです! ryujiさん、いつもありがとうございますー👏
なおこママさんとryujiさんと出会えたtochiさんはラッキーですねー! ryujiさんは勤勉な人だなぁと思ってましたが、ずとまものスマコンを拝見させていただいて正直リスペクトが倍増しました✨みんな驚くぞ~☺️
これは運営をほめ殺しにする回🤣 勿体ないお言葉ありがとうございます😭🙏 @orca48691 さんは常に最新情報を追いつつ、実現できる方法を提案して実装できて素晴らしいですよね✨ 【質問回答】ずとまも運営チームはどのように結成されたのか? - tochi @tochi1203 r.voicy.jp/LMKxxAobKyo #Voicy
ずとまも💓下駄箱編 ミントできました〜😍 声もめっちゃ可愛い〜🙌✨ #ずとまも
ずとまもミント完了✨ この先、この子がどんな成長をするのか、今から楽しみです☺️ #ずとまも @tochi1203
よし!家に帰ってきて餡音おだんごジェネ、SSS、ずとまも、CNCPassをミント完了! かわいすぎるやろおおおおおお❤ まもられええええええええええ🥰 #ずとまも
スタエフでずとまもの思い出SBTの話をしました。 マニアックなお話なので、訳分からんかもで恐縮ですが、よろしければお聞きください! とりあえず、ryujiさんが天才っていうのが伝われば満足です😆 stand.fm/episodes/66b57…
CHAPTER 4
学んだこと
学んだことは、複雑なスマートコントラクトの開発をする際に、なるべく新規で作成しない方が良いことです。 エンジニアはゼロからコードを書きたがる傾向がありますが、スマートコントラクトのコードは一度デプロイされると、世界中の人が見ることができます。 基本的に複雑なシステムを作るときは、バグがないコードを作ることはできないので、完全新規でコードを作成することはかなりのリスクがあります。
リスクを抑えるために、すでにデプロイされていて何年もハッキングがされていないコードをベースにコントラクトを作った方が、はるかにハッキングのリスクを抑えることができます。
なので、スマートコントラクトを開発するときは、なるべくゼロから作らず、信頼できるコードをベースに開発をした方が良いということを学びました。