ZUTTO MAMORU

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
ZUTTO MAMORUのトップ画像

CHAPTER 1

実装した機能

スマートコントラクト

  • ERC721Aで複数ミントのガス代の軽減
  • ダイナミックなtokenURIの実装
  • 本体のNFTが移動したら紐付いているSBTも一緒に移動する
  • ERC-4906でメタデータをリフレッシュ
  • アクセスコントロール
  • 詐欺防止機能とコントラクトブロックの実装
  • プレセールを複数回実地できるようにする

フロントエンド

  • マークルツリーによるユーザーがNFTを購入できるサイトの構築
  • 枚数を指定してNFTを購入できる

上記の通り、ファウンダーの要望で普通のNFTと比べてスマートコントラクトは、かなり複雑なものになりました。

ZUTTO MAMORUのロードマップ

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 / ブロックチェーンエンジニア
ryuji / ブロックチェーンエンジニア
@orca48691

ずとまもフリーミント特にトラブルなく進んでよかったです😊 裏では使っているライブラリをアプデして改修しないとミントサイトでエラー出てしまっていたので昨日1日使って直してました笑

Image
8
Reply

なおこママさんとryujiさんと出会えたtochiさんはラッキーですねー! ryujiさんは勤勉な人だなぁと思ってましたが、ずとまものスマコンを拝見させていただいて正直リスペクトが倍増しました✨みんな驚くぞ~☺️

なおこママ@ずとまも/CNPR/ひと妻DAOジェネエンジニア
なおこママ@ずとまも/CNPR/ひと妻DAOジェネエンジニア
@5151Naoko

これは運営をほめ殺しにする回🤣 勿体ないお言葉ありがとうございます😭🙏 @orca48691 さんは常に最新情報を追いつつ、実現できる方法を提案して実装できて素晴らしいですよね✨ 【質問回答】ずとまも運営チームはどのように結成されたのか? - tochi @tochi1203 r.voicy.jp/LMKxxAobKyo #Voicy

6
Reply

CHAPTER 4

学んだこと

学んだことは、複雑なスマートコントラクトの開発をする際に、なるべく新規で作成しない方が良いことです。 エンジニアはゼロからコードを書きたがる傾向がありますが、スマートコントラクトのコードは一度デプロイされると、世界中の人が見ることができます。 基本的に複雑なシステムを作るときは、バグがないコードを作ることはできないので、完全新規でコードを作成することはかなりのリスクがあります。

リスクを抑えるために、すでにデプロイされていて何年もハッキングがされていないコードをベースにコントラクトを作った方が、はるかにハッキングのリスクを抑えることができます。

なので、スマートコントラクトを開発するときは、なるべくゼロから作らず、信頼できるコードをベースに開発をした方が良いということを学びました。

© 2024 ryuji