###### tags: `SAIGATE`
# ブロックチェーン 開発共有ドキュメント
開発の報告と共有の内容をこちらのドキュメントにまとめます。
詳細な情報は別紙で共有しますが、日次の報告や作業内容はこちらに記載します。

## Github
https://github.com/saigate-dev/sain_nft_blockchain

## ToDoリスト
- [x] WEB3でのUI連携開発
- [x] Openseaの仕様確認
- [x] 開発箇所の整理・実装

- [x] コントラクト開発
- [x] NFT部分とERC20部分のコントラクトの統合
- [x] ERC20トークン部分
- [x] 既存コントラクトの実行テスト
- [x] ユーザー情報の検証フロー確認
- [x] NFT部分
- [x] 検証フローの使い回しができるか確認
- [x] NFTのトランスファー開発
- [x] NFTのMint部分の開発

- [ ] mint周りの仕様の変更

- [x] バックエンドへの開発内容共有
- [x] 必要情報のリストアップ

- [ ] ブラウザ版UI
- [ ] ポップアップ部分確認

- [ ] スマホ版UI
- [x] 遷移まとめと不足分の共有資料作成
- [ ] Metamaskアプリとの連携機能作成

- [x] 決済処理について
- [x] 通知が必要なのであれば通知機能のお願い
- [x] 決済画面のデザインをfigmaに反映

- [ ] コントラクト安全性確認
- [ ] リエントランシー攻撃に対しての対処
- [ ] 算術オーバフロー・アンダーフローに対する対処

- [ ] 動作確認項目
- [ ] NFTの送付
- [ ] 支払いの実行
- [ ] ロイヤリティ、手数料の支払い

- [ ] 上田方式のデータの書き込み方
- [ ] ハッシュしなかった際に発生するデータ量

## 11/16 報告書
### mint部分の仕様変更について
購入後にPolygonscanを見た際に、公式アカウントが保有者の最初に来ていてほしい。
基本的な操作の流れは以下、
1. mint(一次流通のみ)
2. Transfer NFT
3. Transfer Matic

mint (address to ,tokenId){
address to (事務所の公式アドレス)
tokenId (任意)

transferNFT (address from, address to, tokenId)
address from (事務所公式アドレス)
address to (購入者アドレス)

transferMatic (address from ,address to, address sain, address artist,uint fee,uint roiyality ,amount)
address from (購入者アドレス)
address to (出品者アドレス)
address sain (SAIN公式アドレス)
address artist(ロイヤリティ送付先アドレス)
uint fee (手数料割合)
uint roiyality (ロイヤリティ割合)
amount (合計金額)

## 11/12報告書
* Metamaskユーザーアドレスの保存方法検討共有
* Metamaskアプリとの連携機能作成
* 通知が必要なのであれば通知機能のお願い

### Metamaskユーザーアドレスの保存方法検討共有
https://metamask.github.io/api-playground/api-documentation#eth_accounts

RPC APIで連携する。
データの型や動作についてはリンクを参照

### Metamaskアプリとの連携機能作成
https://docs.metamask.io/guide/mobile-getting-started.html#why-you-and-your-users-should-use-metamask-mobile

### 通知が必要なのであれば通知機能のお願い
通知が必要な場面の整理が必要。現段階ではオークションで落札決定時に通知を送る必要がある。

この部分のリンクで動作する。
リンクづけができれば、サービス内ポップアップについては追加開発は必要ないと思われる。

## 11/10報告書
### 実行タスク
* コントラクト統合部分開発
* ブロックチェーン関連部分UI整理

### コントラクト統合部分開発

## 11/7報告書
### 実行タスク
* コントラクト統合部分開発

### コントラクト統合部分開発
統合部分の開発は実装できました。

これで、Polygonに接続している場合、Maticでの取引が可能になっている点を確認すれば、機能としては大丈夫かと思います。
残りの実装としては、Openstore機能でtransferの前に Mintされていなかたらmintしてから送付するという機能の実装かと思います。

糸永さんの方からいただくデータ一覧に関しては8日午前中での共有、実装必要内容の共有まで行えればと思います。

その前に機能として問題がないかを全体で合意を取らないといけないと思うので、その部分については確認してからお願いしようと思います。

**【ここまで　23:25段階での共有】**

## 11/5報告書
### 実行タスク
* コントラクト統合部分開発

### コントラクト統合部分開発
現在の実装では、ERC20トークンの企画を読み込むことで決済コントラクトを構築している。
そのため、Openseaの仕様に合わせるとMaticをWETHに変換してから送金し、受け取ったのち再度Maticに戻すという設計になる。

この実装を取り入れた理由は、maticを持ってさえいれば追加の金銭的コストをかけることなく、決済が可能であり、決済を実現するというアプリケーションとしての最低限の機能を実装することができるからである。

しかし、仕様書の条件とは変わってしまうため、Maticのまま決済を行う方法を調査した。

その結果、nanakusaが9月（攻撃流出事件）以降使用しているコントラクトを分析した結果、ERCトークン規格のままMaticでの決済が可能でありそうだということがわかった。その他署名の要求などセキュリティ面に関しても、参考になる部分があるので、今後の実装に応用する。

今後の開発としては、nanakusaを参考にNFTと決済部分の実装を進め、週末でのコントラクトの完成を目指す。そして目処が立ち次第、糸永さんに要件を共有する。

また、上記に伴って、Matic以外での決済の危険性が出てきたため、その対処法としてメタマスクのネットワーク接続状況を取得し、polygonに接続していない場合は決済画面に進めないような仕様にするアイデアがある。

これについては全体で合意をとって進めていきたい。

## 11/4 報告書

### 実行タスク
* ERC規格整理
* Payable関数について
* コントラクト統合部分開発

### ERC規格整理
#### ERC721
ERC721は現在NFTを発行する際に最もよく利用される規格です。この規格では、トークンの基本機能とも言える所有や転送に関わる最低限の機能が定義されています。また、発行するトークンが一意になるようにトークンIDと呼ばれるものを設定することで代替不可能性を保証しています。

また、NFTでよく見かける画像や動画などのコンテンツやNFTのタイトルなどといった情報を扱うための方法もオプショナルではありますが定義されています。このような情報はメタデータと呼ばれ通常外部のサーバーに保存されることが多いです。このメタデータの定義の方法や保存先からデータを持ってくる方法もこの規格で定義されています。

#### ERC1155

> ERC1155 is a novel token standard that aims to take the best from previous standards to create a fungibility-agnostic and gas-efficient token contract.
**Openzeppelin Docs**

ERC1155は、別名マルチトークンスタンダードと呼ばれ、複数種類のトークンをまとめて扱うことにフォーカスした規格です。すでに紹介したERC721や、代替可能トークンのスタンダードであるERC20などさまざまなトークンを発行するための規格はすでに存在していますが、複数種類のトークンを転送する際などにはガス代が高くなる傾向にあります。

そこでこの規格では、非代替トークンも代替トークンもまとめて扱えるようするための処理が定義されています。また、複数のアドレス宛にまとめてトークンを送ることもできるため、その意味でもガス代節約と利便性向上の意味で注目されています。

例えば、ブロックチェーンを利用したゲーム内でキャラクターやキャラクターが保有するアイテムなどがNFTとして扱われている場合を考えてみましょう。仮に、アイテムと一緒にキャラクターを転送したい場合、それらを別々に送っているとトークンの数だけガス代がかかってしまい高額になってしまいます。しかし、この規格を利用するとまとめてトークンを転送できるのでガス代を節約することが可能になります。このことはより柔軟で創造的なNFTのユースケースを考える上で大きな意味を持ちます。

#### 上記の説明を受けて
ERC721で十分かと思います。

理由としては、複数のトークンを同時に販売するケース（OpenseaでのBandle販売。要するにセット売り）などは今回のSAINでは想定しておらず、単一のトークンの移動になると考えられるからです。マルチトークンとはいうものの、基本的に規格をまたいで同時にペイメントにもNFTにも使える設計というニュアンスではなく、そのトークンをERC20のようにもERC721のようにも使えるという話のように見受けられました。

### Payable関数について
コントラクトに対してEtherを送金することができます。
また、送金されたコントラクトは、受け取ったEtherを別のアドレス（例えばコントラクトを作成した人のアドレス）に送金することもできます。

送金を受け取る関数がPayable、送金するのがWithdraw関数になります。

これはロイヤリティを支払うときなどに使う要素だと思います。
しかし、これはあくまでもERC721,ERC20のトークンをどのように操作するかの話であるので、どちらにせよトークン規格のベーシックな読み込みは必要になると考えられます。

#### 上記の説明を受けて
実装は昨日の予定通り、20と721トークンの実装で進めたいと思います。

### コントラクト統合部分開発
コードの参考はOpenSeaやRelableを参考にしています。
開発が必要な部分は認証が必要な場合、それを一括で行うことができるか。そのデータをDBが持っている場合、その情報の共有、コントラクトないからの関数呼び出しの場合は関連関数の実装が必要なります。
また、それぞれの実装でsolidityのバージョンが違い、そのままだとコンパイルが通らないので、バージョンの調整が必要になります。

### 開発中の問題
開発の中で、出てきた新しい問題を以下で説明します。
解決方法についても検討しますので、コメントがあればください。
#### NFTの送付について
NFTの送付を行う際に、購入者や運営者がコントラクトの呼び出しをした場合、msg.senderは購入者・運営者になります。そのため、NFTの送付をするには、コントラクトにアプルーブを行う必要があります。
ここの実装はイーサリアム版Openseaが参考になるので参考にしています。

今日中の完成はできませんでしたが、明日の完成を目指します。
そして週末から、フロントの開発にできればと思います。

## 11/3 報告書

### 実行タスク
* NFTトランスファー コントラクト開発
* NFT Mint部分開発

上記の作業に関しては完了しました。
githubに連携しましたのでコントラクト確認したい場合は参照してください。　　
https://github.com/saigate-dev/sain_nft_blockchain/tree/main

基本的にERC721の規格と1155の企画がNFTには存在しています。
とにかく動くものをとのことだったので、簡単に作れた721から作成しましたが、1155の特徴を鑑みた上でそちらの方がいいとなれば、イーサリアム版オープンシーなどを参考に1155も開発します。

現在のソースコードでは個別にコントラクトが書かれていますが最終的には一つのファイルにまとめて単一のコントラクトで20と721の取引が可能になるようにします。

明日は統合部分の開発ができればと思います。