create an architecture of mint implementation

[toru-toruto]

create an architecture of mint implementation

[toru-toruto]

https://app.diagrams.net/#G1ZNDLPwCfZSW7Af_RpVIc5ry6ediC1z5e

[toru-toruto]

問題点：
IPFS上の暗号化された楽曲データとコントラクト上のトークンが、お互いに保存先の情報を持つ必要がある。

• Lit Protocolで指定するアクセス条件に、コントラクト上のトークンIDが必要
• コントラクト上のトークンには、楽曲データのCIDを含むメタデータのuriが必要

そのため現状では、まずメタデータのuriを含まずにmint(?)してトークンIDを取得、トークンIDを利用して暗号化しIPFSに保存、最後にメタデータのuriをコントラクト側に保存するようにしている。

ただ、この方法はトランザクションが2回発生してしまう。

その他の方法検討：

• トークンのlengthから事前にトークンIDを割り出す案。この方法ではlengthの取得からトークンの投稿までに、他のトークンが投稿された場合に不整合が発生すると考えられる。
• ProfileNFTを想定すると、楽曲IDについては自分だけが投稿できるリストとなるため不整合は発生しない。一方で、ProfileNFT自体のIDについて不整合が発生する可能性がある。楽曲の投稿より前にProfileNFTを生成する手順を挟むのはどうか？

[knagato]

手順

1. zipAndEncryptFiles('rowAudio.mp3') -> { encryptedAudioFile, symmetricKey }
2. uploadIPFS(encryptedAudioFile) -> CID
3. createNFT(NFTMetadata, CID) -> { contractAddress, tokenId }
4. accessControlConditions := { contractAddress, tokenId }
5. saveEncryptionKey(accessControlConditions, symmetricKey)