教育目的の参考情報であり、投資助言ではありません。投資により損失が生じる可能性があります。
直接の回答
ERC-1155 はイーサリアムのマルチトークン規格です。一つのコントラクトで複数のトークン種別を管理でき、各 token ID は、代替可能な残高、非代替性アイテム、または実装が選択した別の供給設計を表せます。したがって、資産を特定するキーはトークン ID だけではなく、contract address + token ID です。
この規格は、単一および一括の残高照会、単一および一括の安全な転送、オペレーターへの包括的な承認、受取側コールバック、転送イベント、ならびに任意のメタデータ URI の動作を定義します。一方で、誰がミントできるか、供給量に上限があるか、メタデータが永続的か、トークンがどのような法的権利を与えるか、またトークンにどれだけの価値があるかは定義しません。これらの性質は、対象となるコントラクト、そのロール、外部依存関係について確認する必要があります。
仕組み
- 残高を特定します。
balanceOf(account, id)は、あるアカウントが一つの ID について保有する数量を返します。balanceOfBatch(accounts, ids)は、対応するアカウントと ID の組を照会します。二つのコントラクトがいずれも無関係な資産に ID1を使うことがあるため、完全な識別情報はチェーン、コントラクトアドレス、ID の組み合わせです。 - 呼出元を承認します。 保有者は自分の残高を転送するか、
setApprovalForAll(operator, true)を呼び出せます。この承認は、保有者がそのコントラクトで所有するすべての ERC-1155 ID に及びます。isApprovedForAll(owner, operator)で承認状態を確認できます。ERC-1155 には、一つの ID や数量だけに限定する標準の承認方法はありません。 - 単一または一括の転送を適用します。
safeTransferFromは一つの ID と数量を移動します。safeBatchTransferFromは並行するids配列とvalues配列を使い、両者の長さと順序は一致していなければなりません。一括処理は取引ごとの重複コストを減らせますが、すべての実装や処理内容で必ず安くなるわけではありません。 - コントラクトである受取先を確認します。 残高を更新して該当イベントを発行した後、規格に準拠したコントラクト宛て転送は
onERC1155ReceivedまたはonERC1155BatchReceivedを呼び出します。コールバックが未対応である、戻り値が誤っている、または受取を拒否した場合、通常は転送全体が取り消されます。この受取確認は誤って資産がロックされる可能性を下げますが、受取コントラクトが信頼できることや、引き出し手段があることを証明するものではありません。 - イベントから状態を再構築します。 すべてのミント、転送、バーンは
TransferSingleまたはTransferBatchに反映されなければなりません。ミントではゼロアドレスがfrom、バーンではゼロアドレスがtoになります。インデクサーはログから残高と ID ごとの純ミント供給量を導出できますが、全履歴、チェーンの再編成、コントラクトの移行を正しく処理する必要があります。 - メタデータを解決します。 任意の URI 拡張は
{id}を含む共通テンプレートを返すことがあります。クライアントはこれを、英小文字で表した十六進数のトークン ID に置き換えます。この値は左側をゼロで埋めた 64 文字で、0x接頭辞を付けません。実装とストレージの保証で別途確約されていない限り、メタデータは変更可能、利用不能、または誤解を招くものである可能性があります。
具体例
あるゲームコントラクトでは、ID 1 を金貨、ID 7 をアクセスパス、ID 42 を固有の剣に割り当てます。Alice は balanceOf(Alice, 1) = 500、balanceOf(Alice, 7) = 3、balanceOf(Alice, 42) = 1 を保有しています。
- Alice は
safeBatchTransferFromを呼び出し、ids = [1, 7, 42]とvalues = [120, 1, 1]を渡します。検証に成功すると、新しい残高は500 - 120 = 380、3 - 1 = 2、1 - 1 = 0となり、受取人がそれぞれの数量を得ます。 - コントラクトは
TransferBatchを発行します。受取人がコントラクトなら、onERC1155BatchReceivedを通じて一括転送を受け入れなければなりません。受け入れなければ取引全体が取り消され、三つの残高変更はどれも残りません。 - ID
42が非代替性トークンとして振る舞うのは、その発行と転送のロジックが供給量を1に保っているためにすぎません。ERC-1155 自体がこのルールを強制するわけではありません。同じコントラクトは、独自のアクセス制御に従って ID1を後から追加発行できます。
リスクと対策
- オペレーターの権限が広範です。
setApprovalForAllで承認された悪意のある、または侵害されたオペレーターは、そのコントラクトで保有者が所有するすべての ID を移動できる可能性があります。オペレーターのアドレスとコントラクトを確認し、必要に応じて別のウォレットを使い、不要になった承認を取り消してください。 - ミント、停止、アップグレード権限。 これらは実装上の機能であり、規格が保証するものではありません。ロールの保有者、プロキシ管理者、タイムロック、供給量に関する拡張、さらにアップグレードで残高や転送ルールを変更できるかを確認してください。
- メタデータと資産の不一致。 オンチェーンの ID が同じでも、URI やホストされた JSON は変更される可能性があります。コンテンツハッシュ、ストレージの永続性、発行者の確約、トークンコントラクト外で表される権利を確認してください。
- 連携時の誤り。 ウォレットやインデクサーは、一括配列の組を誤る、過去のイベントを見落とす、再編成を誤処理する、または異なるコントラクトやチェーンの同じ ID を混同することがあります。コントラクト呼出し、ログ、最終残高を突き合わせてください。
- 受取側とリエントランシーのリスク。 受取側コールバックは転送処理中に外部コードを実行します。実装と連携プロトコルには、適切な状態更新順序とリエントランシー対策が必要です。コールバックに対応しているだけでは、セキュリティレビューを受けたことにはなりません。
- コストと流動性のリスク。 一括転送でも Gas は消費され、必要条件の一つでも満たされなければ全体が不可分に取り消されます。市場の流動性、価格決定、ロイヤリティ、ブリッジ、償還、オフチェーンでの履行は ERC-1155 の範囲外です。
よくある誤解
- 「すべての ID が NFT である」。 一つの ID が任意の数量を持つことができます。非代替性は実装の供給量と意味付けによって決まります。
- 「一つのコントラクトは一つのコレクションを意味する」。 一つのコントラクトに無関係なトークン種別を多数含められ、別のコントラクトにある同じ数値の ID は別の資産を特定します。
- 「安全な転送なら資産も安全である」。 コールバックが確認するのは受取先との互換性であり、コントラクトの品質、価格、メタデータ、資産を回収できるかどうかではありません。
- 「一括処理は常に Gas を節約する」。 重複コストを避けられる場合は多いものの、実際の結果は実装、ID の数、ストレージ変更、コールデータ、ネットワークの手数料モデルによって変わります。