ERC1155
https://miro.medium.com/max/5000/1*NJPOy2Yisr1pRzVUn1HeWw.png
https://miro.medium.com/max/4080/1*j-TusCRF8RCv4e7_n8yNMw.jpeg
Enjin ゲームxブロックチェーンのプラットフォーム(シンガポール)が提案 向いてる
マスタ管理するトークンたくさん
コンテンツの交換が多対多で行われるもの
公式
実例
わかりやすい使用例
10個の薬草を1トランザクションで上薬草に変える
キャラクターとアイテムを一纏めにして一括処理したい
トランザクションにかかる時間の短縮や料金（gas）の低減につながるほか、アセットの大量生産が行いたい
ERC1155に対応しておけば他の対応しているゲームとのつなぎこみは楽そう？に見えるので、その点ではゲームデベロッパーにもメリットがありそう
ERC1155提案に至るモチベーション
1タイトルで100000種類のアイテムぐらいあるゲームをリリースしようとした場合、全部をトークン化してデプロイしてゲームスタジオが管理するのは現実的でない
取引所(ゲームの場合はゲーム運営？）を介さずに別トークンの交換を行いたい
FTとNFTを混合したゲームつくりたい
ERC1155が可能にすること
取引所(ゲームの場合はゲーム運営？）を介さずに別トークンの交換を行う
Before ERC1155
下図のAとBを仲介者なしで、交換する際 4トランザクション
After ERC1155
２トランザクションで、複数トークンをまとめて交換可能
https://miro.medium.com/max/503/1*XlKs23mB2BTzjMOHfCp9-w.png
複数トークンをまとめて転送したい
Before ERC1155
ERC20 やERC721では、１つずつ購入していた。
gasと完了時間のコスト高い
After ERC 1155
1つのトランザクションで1人or複数の受信者に任意数のトークンを送信可能
FTとNFT両方扱いたい
Before ERC1155
ERC20 やERC721どちらかだけのBlockchain Gameでは、収集がメインになっている。
NFTかFTのどちらかしか扱えない
互換性がない
ERC20 ... Fungibleなものにしか使えない (idがないので）
ERC721 ... idを持つような、それぞれ固有なものにだけ用いれる
ERC20 / ERC721はお互いに互換性がないし、混ぜて使うこともできない
例:銃弾,薬草などのNFT(非代替)である必要のないアイテムを扱う場合も、NFTとして扱って使う必要がある。
コスト割高
データリソースを無駄
ゲームアイテムの流動性が下がる
例2
あるゲーム内で、1つ1つ区別する必要のない「普通の剣」と、1つ1つパラメータの異なる「レアな剣」
「普通の剣」はFungibleが適切
「レアな剣」はNon Fungibleが適切
全てのアイテムをNon Fungibleなアイテムに分類してしまった場合
「普通の剣10コ」と「レアな剣1コ」を交換したいときに、「普通の剣10コ」を1つ1つ別々の剣として交換する必要がある。
そのため、交換の際に余計なトランザクションコストが発生してしまう。これはトランザクション手数料が大きな課題の一つであるブロックチェーンゲームにおいては大きな損失であると考える。
After ERC 1155
NFTとFTを両方扱える
交換したり、まとめて取引したり
hr.icon
実装部分
TokenID
256ビットのID
最初の1ビット(0,1)をNFT or FTのフラグ
次の127ビットをトークン特有のID
後ろ128ビットをそのトークンのインデックス
例
使う分には効用が同じ(トークン特有IDが同じ)
10個持っていたら後ろ128ビットを使ってそれぞれのIDはインデックスの分異なるといった感じ
必要に応じてunique indexをつけてNon Fungibleにも, Fungibleにも扱える
正確には、あるNFTにインデックスを付与してユニークな番号がついた同じ種別のNFTを複数作れるといった感じ
hr.icon
トークンの作成
1. アイテムの定義(create)
ERC1155では「アイテムID」と呼ばれる単位で全てのトークンを管理
create機能を実行し、アイテムの「型」を定義することからスタート
この時アイテムIDが発行→createが実行される度に、nonceと呼ばれるコントラクト内のカウンタが1ずつ増加し、アプリ全体でアイテムIDの一意性が保証
createを実行する際にはNFTとして作成するかFTとして作成するかを必ず指定する必要
両者は先頭IDの先頭ビットを「0」と「1」で区別
ただし、この段階では利用可能なトークンではなく、以下に記載する後続機能を呼ぶ出す必要
hr.icon
アイテムの生成
定義された型のトークンを利用可能にする場合、FT/NFTでそれぞれ指定の機能を実行する必要
FTの生成(mintFungible)
mintFungibleという機能を実行する必要
アイテムID
トークンの種類
create()で定義された種類のトークンを新規発行(追加発行)していくのがmintFungibleの役割
例
1回目のmintFungibleでは、10000を総発行量として新規発行
続いてmintFungibleを実行して5000を追加発行が可能
NFTの生成(mintNonFungible)
mintNonFungibleという機能を実行する必要
アイテムID
トークンの型
mintNonFungible実行時
128ビットが追加された最終的なNFTのアイテムIDが生成
同じ型のトークンを複数回生成した場合
追加分の128ビットは常に+1されて合成されるため、計算上被らない
、異なる種類の型を定義することができるため
好きなタイミングで新たなキャラクターやアイテムを追加していくことが可能
mintNonFungibleを実行した回数だけ同じ型のトークンが発行されるため、
例えば世界に50体しか存在しないキャラと10000体存在するキャラを同時に管理することも可能
hr.icon
トークンの移動
safeBatchTransferFrom
safeTransferFrom
hr.icon
トークンのメタデータ
トークンを後から自由に生成できる
メタデータをあとから自由に設定することはできない。
ゲームアイテムとして利用する際には、はじめにメタデータを注意深く設定する必要あり
ERC721事例を参考に、geneやskillと言ったメタデータを定義し、成長や変化のあるトークンの場合にはこれらの値を適切に変化させていくことで、キャラクターの成長などを表現できる?
ERC20事例を参考に、totalSupplyやnameといったパラメータに加え、そのアイテムがもつ特性に関する情報を含むパラメータとして、stringやuint型で、skillsやeffectsと言った配列型のメタデータを与えるなどが考えられるのではないだろうか。
URI値によるメタデータ拡張
文字列{id}がURIに存在する場合、クライアントはこれを16進形式の実際のトークンIDに置き換える必要あり
→一度にURIを定義することにより、多数のトークンに対して同じオンチェーン文字列を使用できる
置換された16進数IDの文字列形式
小文字の英数字である必要があります：0-9a-f0xプレフィックスなし。
必要に応じて64桁の16進文字長になるように、最初から0で埋める必要
URIの例：クライアントがトークンID 314592 (0x 4CCE0)を参照
メタデータJSONのローカリゼーション機能
hr.icon
参考リンク
日本語