ERC-1155

ERC-1155とは？

ERC-1155は、1つのスマートコントラクトで多種類のトークンを管理できるEthereumのトークン規格です。1つのERC-1155コントラクトに、代替可能トークン、非代替性トークン、準代替性トークン、またはこれらを組み合わせた資産を含めることができます。

公式のERC-1155仕様では、残高、送金、バッチ操作、承認、受取側コールバック、イベント、メタデータ、インターフェース検出に関する共通ルールが定められています。

ERC-1155は一般に「マルチトークン規格」と呼ばれています。各トークン種類はトークンIDで識別され、固有の供給量、メタデータ、用途、希少性、経済的特性を持つことができます。この設計により、大規模な暗号資産アプリケーションで資産ごとに別のスマートコントラクトをデプロイする必要性が減ります。ERC-1155は、ブロックチェーンゲーム、デジタルコレクティブル、会員権、イベントチケット、報酬システム、トークン化されたインベントリ、複数の関連資産を扱うアプリケーションに特に適しています。規格に準拠すると相互運用性は向上しますが、トークンの真正性、価値、希少性、安全性が保証されるわけではありません。

ERC-1155はなぜ作られたのか？

従来のEthereumトークン規格は、通常、1種類の代替可能資産または1つの固有資産コレクションを対象としていました。数百種類の通貨、ゲームアイテム、チケット、コレクティブルを含むプロジェクトでは、多数の個別コントラクトが必要になる場合がありました。コントラクトを追加するたびに、デプロイコスト、コードの重複、管理作業、統合の複雑さが増します。ERC-1155では、これらのトークン種類を1つのコントラクトと共通の送金システムで管理できます。また、複数のトークンIDを1回の呼び出しで照会または送金できるバッチ操作にも対応しています。バッチ処理により、重複するトランザクション処理を減らし、複数資産を扱う操作を簡素化できます。この規格は大規模なトークンシステムを想定して設計されましたが、ブロックチェーンゲームに限定されません。

ERC-1155の仕組み

ERC-1155コントラクトは、アカウントアドレスとトークンIDの組み合わせごとに個別の残高を記録します。たとえば、1つのウォレットがトークンID 1を500単位、トークンID 2を3単位、トークンID 3を1単位保有できます。トークンID 1は代替可能な通貨、トークンID 2は限定アイテム、トークンID 3は固有のNFTを表すことができます。この3つの残高は、同じスマートコントラクト内に存在できます。トークンを送金すると、コントラクトは対象トークンIDについて送信者の残高を減らし、受取人の残高を増やします。コントラクトは標準化されたイベントを出力し、ウォレットやブロックチェーンインデクサーが変更を確認できるようにします。受取人がスマートコントラクトの場合、ERC-1155は受取側コールバックを実行し、そのコントラクトがトークンを受け入れることを確認します。

ERC-1155のトークンIDとは？

トークンIDは、ERC-1155コントラクト内の1種類のトークンを識別する符号なし整数です。同じトークンIDが別のコントラクトに存在しても、同じ暗号資産を表すとは限りません。したがって、ERC-1155資産はブロックチェーンネットワーク、コントラクトアドレス、トークンIDの組み合わせで識別されます。あるコントラクトのトークンID 100がゲーム内リソースを表す一方、別のコントラクトではイベントチケットを表すことがあります。この規格では、トークンIDを0から始めたり、単純な連番にしたりする必要はありません。開発者はアプリケーションの設計に応じてIDを割り当てられます。ユーザーは表示名や画像だけに頼らず、コントラクトアドレス全体とトークンIDを確認してください。

ERC-1155の代替可能トークン

同じトークンIDに交換可能な単位が多数存在する場合、そのIDは代替可能資産として機能できます。たとえば、ゲームでトークンID 10をゲーム内通貨として100万単位発行できます。各保有者はトークンID 10に紐づく数量残高を持ちます。同一IDの単位は、通常、コントラクトで定義された同じ特性を持ちます。ERC-1155のコアインターフェースでは、トークンIDごとの個別のシンボル、decimal値、名称は定義されていません。必要な表示情報は、メタデータやカスタム関数を通じてプロジェクトが提供する必要があります。

ERC-1155の非代替性トークン

あるトークンIDの供給量を1単位に制限すると、そのIDはNFTとして機能できます。その単位を保有するアドレスが、IDで表された固有資産の実質的な所有者となります。同じコントラクト内の別のIDで、異なる固有アイテムを表すこともできます。ERC-721とは異なり、ERC-1155では各トークンIDの供給量が自動的に1に制限されるわけではありません。トークンIDを非代替性とする場合、コントラクトのミントロジックで一意性を確保する必要があります。ERC-1155のアイテムが固有であるという主張を信頼する前に、実際の供給量制御を確認してください。

ERC-1155の準代替性トークン

準代替性トークンは、ライフサイクルのある段階では複数の交換可能な単位を持ち、その後、異なる意味や用途を持つ場合があります。イベントチケットは一般的な例です。同じエリアのチケットはイベント前には交換可能でも、イベント後は個別の体験に紐づくコレクティブルになることがあります。限定版のゲームアイテムにも準代替性モデルを利用できます。ERC-1155は、トークンIDを代替可能、非代替性、準代替性のいずれかに正式分類していません。分類は供給量、メタデータ、送金ルール、アプリケーションの動作によって決まります。

ERC-1155のコア関数

ERC-1155のコアインターフェースには、残高確認、トークン送金、オペレーター権限管理の関数が含まれます。

主な関数は

、、、、、です。

ERC-1155はERC-165によるインターフェース検出にも対応する必要があります。コアインターフェースでは、公開ミント、公開バーン、ロイヤリティ、総供給量、トークンのdecimals、個別トークンの承認は定義されていません。これらの機能は、任意の拡張機能やカスタムロジックで追加できます。

balanceOf関数

関数は、1つのアカウントが保有する1つのトークンIDの数量を返します。

アカウントアドレスとトークンIDの両方が必要です。通常1つのコントラクトが1種類のトークンを表すERC-20とは異なります。また、ERC-721の残高がコレクション内でアドレスの保有する固有NFT数を数える点とも異なります。ERC-1155の1つのIDに対する残高は、0、1、またはそれ以上の整数になります。ゼロアドレスへの残高照会は失敗する必要があります。

balanceOfBatch関数

関数は、複数の残高を1回の呼び出しで取得します。

呼び出し元は、アカウントアドレスの配列とトークンIDの配列を渡します。各アカウントは、同じ配列位置にあるトークンIDと組み合わせられます。2つの配列の長さは同じでなければなりません。1つのアカウントの複数ID、または複数アカウントの1つのIDを照会できます。これにより、ウォレット、ゲーム、ポートフォリオアプリケーションが必要とする個別のブロックチェーン呼び出しを減らせます。

safeTransferFrom関数

関数は、1つのトークンIDの指定数量をあるアドレスから別のアドレスへ送金します。

呼び出し元はトークン保有者、またはその保有者が承認したオペレーターでなければなりません。送信者は選択したIDの単位を十分に保有している必要があります。受取人にゼロアドレスは指定できません。この関数では、アプリケーション固有のデータを格納できるbytesフィールドも指定できます。

単一送金に成功すると、

イベントが出力されます。

受取人がスマートコントラクトの場合、必要なERC-1155受入確認に合格する必要があります。

safeBatchTransferFrom関数

関数は、複数のトークンIDと数量を1回のトランザクションで送金します。

呼び出し元は、トークンIDの配列と、それに対応する送金数量の配列を渡します。各数量は、同じ配列位置のIDに適用されます。配列の長さは同じでなければなりません。送信者は、バッチ内のすべてのトークンを十分に保有している必要があります。必要な送金の1つでも失敗すると、通常、トランザクション全体が取り消されます。

操作に成功すると、1つの

イベントが出力されます。

バッチ送金のメリット

複数の関連資産をまとめて移動する場合、バッチ送金によりトランザクションコストを減らせる可能性があります。プレイヤーは、通貨、素材、装備、コレクティブルを1回のトランザクションで送金できます。報酬コントラクトは、複数種類のトークンを1回の操作で受取人に配布できます。バッチ処理により、資産の一群をまとめて交換する操作も簡素化できます。全資産が移動するか、トランザクション全体が失敗するためです。節約できるガス代は、ID数、ストレージ変更、受取側のロジック、ネットワーク状況によって異なります。非常に大きなバッチは、トランザクションのガス上限を超えたり、サービス妨害のリスクを生じさせたりする可能性があります。アプリケーションはユーザーが指定できるバッチサイズに実用的な上限を設けてください。

ERC-1155のオペレーター承認

ERC-1155は、コレクション全体に適用されるオペレーター承認を使用します。

関数を使うと、トークン保有者はオペレーターを承認または取り消しできます。

承認されたオペレーターは、その保有者が当該コントラクト内で保有するすべてのERC-1155トークンIDを送金できます。この権限は、保有者が後から同じコントラクトで受け取るトークンにも適用される場合があります。コア規格では、1つのIDだけ、または数量を限定して承認することはできません。この広範な権限は利便性を高める一方、重大なセキュリティリスクを伴います。悪意あるオペレーターは、承認が有効な間に対象となるすべてのトークンを持ち出す可能性があります。

isApprovedForAll関数

関数は、オペレーターが所有者のERC-1155残高を操作する権限を持つかどうかを返します。

戻り値は

またはです。

承認は、それが付与されたコントラクト内でのみ適用されます。別のERC-1155コントラクトの資産や、別の規格のトークンに自動的に適用されることはありません。ユーザーはオペレーター承認を定期的に確認し、不要な権限を取り消してください。ウォレットをウェブサイトから切断しても、ブロックチェーンに保存された承認は削除されません。

細かな承認を可能にする拡張機能

保有者が1つのトークンIDだけ、または限られた数量だけを承認したい場合、広範なオペレーターモデルは適さない可能性があります。

提案中のERC-5216 Allowance拡張では、トークンIDと数量に応じた、より細かな承認が定義されています。

この拡張機能はERC-1155のコア規格には含まれず、すべてのコントラクトに存在するとは限りません。ウォレットは、トランザクションがコレクション全体への権限を与えるのか、限定的な権限を与えるのかを明確に説明する必要があります。

ERC-1155の受取コールバック

標準のセーフ送金でERC-1155トークンを受け取るスマートコントラクトは、適切な受取コールバックを実装する必要があります。

単一送金のコールバックは

です。

バッチ送金のコールバックは

です。

受取側はオペレーター、以前の保有者、トークンID、数量、付随データを確認できます。必要な値を返すと、トークンを受け入れます。誤った値を返すか処理を取り消すと、トークン送金全体が取り消されます。この仕組みにより、ERC-1155資産を処理できないスマートコントラクトへの誤送金を減らせます。

受取インターフェースIDと戻り値

ERC-1155受取インターフェースIDは

です。

の期待される戻り値はです。

の期待される戻り値はです。

受取コントラクトは、コールバックを実行したERC-1155コントラクトを検証してください。呼び出し元を確認せずにコールバックデータを受け入れると、悪意あるコントラクトが偽の入金記録を作成する可能性があります。受取確認を通過しても、受取コントラクトが将来、安全に出金できるとは限りません。

受取コールバックとリエントランシー

ERC-1155の受取コールバックは、元のトランザクションが完了する前に外部コントラクトのコードを実行します。悪意ある受取側は、元の送金が進行中に別の関数を再度呼び出す可能性があります。この挙動によって、リエントランシーが発生する経路が生じます。ERC-1155仕様では、受取コールバックの前に残高変更と送金イベントを実行する必要があります。トークンとやり取りするアプリケーションは、独自の会計処理と認可ロジックを引き続き保護する必要があります。開発者は、同一関数と異なる関数への再入を試みる悪意ある受取コントラクトを使い、両方のコールバックをテストしてください。

最新のERC-1155実装ドキュメントでも、コントラクトへの送金がリエントランシーのリスクを生じさせる可能性があると注意喚起されています。

ERC-1155イベント

コア規格では、

、、、イベントが定義されています。

これらのイベントログにより、ウォレット、ブロックチェーンエクスプローラー、インデクサーはトークンの動きを追跡できます。ERC-1155は、正しく出力された送金イベントから供給量や残高の履歴を再構成できるよう設計されています。すべてのイベントは、それを出力したコントラクトアドレスと併せて解釈する必要があります。悪意あるコントラクトでも、よく知られたイベント名を出力できますが、真正なプロジェクトを表すとは限りません。

TransferSingleイベント

イベントは、オペレーター、送信者、受取人、トークンID、数量を記録します。

通常の送金では、送信者と受取人のアドレスはゼロではありません。ミントでは送信者にゼロアドレスを使用します。バーンでは受取人にゼロアドレスを使用します。ゼロ数量の送金でも、適切なイベントを出力する必要があります。

TransferBatchイベント

イベントは、1回の操作で送金された複数のトークンIDと数量を記録します。

IDと値は、対応する配列位置に保存されます。イベントにはオペレーター、送信者、受取人も記録されます。バッチミントではゼロアドレスを送信者に使用します。バッチバーンではゼロアドレスを受取人に使用します。正確な残高と供給量を計算するには、インデクサーがイベント配列のすべての要素を処理する必要があります。

ApprovalForAllイベント

イベントは、所有者がオペレーターを有効または無効にしたことを記録します。

所有者、オペレーター、承認状態が含まれます。このイベント自体がトークンを送金することはありません。オペレーターが所有者に代わって今後の送金を開始できるかどうかを変更します。承認を取り消しても、権限が有効な間に完了した送金は元に戻りません。

ERC-165インターフェース検出

ERC-1155はERC-165によるインターフェース検出を必須としています。

ERC-1155のコアインターフェースIDは

です。

対応コントラクトは、この識別子を指定して

を呼び出したときにを返す必要があります。

ERC-165規格は、対応インターフェースをコントラクトが共通の方法で公開する仕組みを定めています。

インターフェース検出により、アプリケーションが未対応の関数を呼び出すのを防ぎやすくなります。肯定的な応答だけでは、すべての関数が正しく安全に実装されていることを個別に証明できません。

ERC-1155のメタデータ

ERC-1155には任意のメタデータURI拡張機能が含まれています。

この拡張機能では、トークンIDのメタデータの保存先を返す

関数が追加されます。

インターフェースIDは

です。

URIは通常、名称、説明、画像、属性、その他のトークン情報を含むJSONドキュメントを指します。

コア規格では、各トークンIDに個別のオンチェーン

、、関数は必須ではありません。

プロジェクトはメタデータやカスタムインターフェースを通じて、これらの情報を追加できます。

{id}メタデータのプレースホルダー

ERC-1155のメタデータURIには、プレースホルダー

を含められます。

アプリケーションはこのプレースホルダーを、要求されたトークンIDの小文字の16進数表記に置き換えます。先頭のゼロを含め、整形後の値は64桁の16進数でなければなりません。

プレフィックスは付けません。

この方法により、1つのベースURIで多数のトークンIDのメタデータ保存先を表せます。置換を誤ると、アプリケーションが別の資産のメタデータを取得する可能性があります。

メタデータ保存のリスク

ERC-1155のメタデータは、ウェブサーバー、コンテンツアドレス型ネットワーク、またはオンチェーンに保存できます。サーバー上のメタデータは変更されたり、消失したりする可能性があります。コンテンツアドレス型ストレージは完全性を高められますが、コンテンツの継続的な可用性が必要です。オンチェーンメタデータは外部ホスティングへの依存を減らせますが、保存や更新のコストが増える場合があります。変更可能なURIを使うと、ユーザーがトークンを取得した後に管理者が名称、画像、説明、属性を変更できる可能性があります。ユーザーは誰がメタデータを管理しているか、また永続性の保証を検証できるか確認してください。

ERC-1155トークンのミント

ミントとは、ERC-1155トークンIDの新しい単位を作成することです。コア規格では公開ミント関数や、誰がトークンを作成できるかは定義されていません。実装によって、管理者、スマートコントラクト、ガバナンスプロセス、その他の認可された役割にミントを制限できます。

単一ミントでは、送信者をゼロアドレスとする

を出力します。

バッチミントでは、送信者をゼロアドレスとする

を出力します。

スマートコントラクトへのミントでは、通常、適切な受取コールバックが実行されます。供給量や希少性に関する主張を信頼する前に、ミント権限を確認してください。

ERC-1155トークンのバーン

バーンとは、コントラクトのルールに従ってトークン単位を流通から取り除くことです。コア規格では、公開バーン関数は必須ではありません。コントラクトによっては、保有者、承認済みオペレーター、管理者、またはプロトコルロジックにトークンのバーンを許可できます。バーン時には、受取人をゼロアドレスとする送金イベントを出力します。あるIDの現在の単位をすべてバーンしても、同じIDを再びミントできないとは限りません。結果は実装のミント権限と供給量制御によって異なります。

総供給量と列挙

ERC-1155のコアインターフェースには

関数が含まれていません。

コントラクトがイベント要件を正しく守っている場合、ミントとバーンのイベントから供給量を再構成できます。実装に任意の供給量追跡拡張機能を追加し、IDごとの総供給量を返すこともできます。

最新のERC-1155コントラクトライブラリには、供給量追跡、バーン、一時停止、URI保存の拡張機能が含まれています。

ERC-1155には、既存の全トークンIDや保有者を一覧表示するコア関数もありません。アプリケーションでは、オフチェーンでイベントをインデックス化して一覧を構築するのが一般的です。

ERC-1155のロイヤリティ

クリエイターロイヤリティはERC-1155のコア規格に含まれていません。

任意のERC-2981ロイヤリティ規格を使うと、コントラクトはロイヤリティ受取人と推奨額を通知できます。

ロイヤリティ額は、指定された販売価格を使って計算されます。ERC-2981はロイヤリティ情報を伝えますが、すべての送金時に支払いを自動的に強制するものではありません。販売を伴わない送金もあり、これがトークンコントラクトですべての移動をロイヤリティ対象として扱えない理由の1つです。ロイヤリティ設定を管理者が変更できるか確認してください。

ERC-1155の標準エラー

元のERC-1155仕様では、Solidityの最新のカスタムエラーは定義されていません。

Final（最終版）のERC-6093エラー規格では、ERC-1155コントラクトで一般的なエラー名が定義されています。

残高不足、無効な送信者、無効な受取人、オペレーター承認の不足、無効なオペレーター、配列の長さの不一致などに関するエラーが含まれます。エラーを標準化すると、ウォレットや開発者がトランザクションの失敗を一貫して説明しやすくなります。既存のERC-1155コントラクトに、これらのエラーへの対応義務はありません。

ERC-1155とERC-20の比較

ERC-20では、通常1つのコントラクトが1種類の代替可能トークンを表します。ERC-1155では、1つのコントラクトで多数のトークン種類を表現できます。ERC-20は使用者ごとの数値指定Allowanceを使用しますが、ERC-1155のコア機能はコレクション全体へのオペレーター承認を使用します。ERC-1155には、バッチ送金とスマートコントラクト受取人への必須受取コールバックが含まれます。ERC-20のコア規格には、これらの機能はありません。プロジェクトが1種類の代替可能な暗号資産だけを必要とする場合、ERC-20の方がシンプルな選択肢となる場合があります。

ERC-1155とERC-721の比較

ERC-721は、個別に所有される非代替性トークンID向けに設計されています。有効なERC-721トークンIDには1人の所有者がいます。ERC-1155は、アカウントとトークンIDの組み合わせごとに数量残高を保存します。これにより、同一コントラクト内で、あるIDに交換可能な単位を多数持たせ、別のIDの供給量を1にできます。ERC-1155は標準化されたバッチ送金にも対応しますが、ERC-721では通常NFTを1つずつ送金します。すべての資産が固有である場合、ERC-721の方がシンプルなモデルとなる可能性があります。

ERC-1155の主なユースケース

ブロックチェーンゲームでは、1つのERC-1155コントラクトで通貨、素材、武器、キャラクター、土地を管理できます。イベントシステムでは、別々のトークンIDで異なるカテゴリ・数量のチケットを発行できます。会員権プロジェクトでは、複数のアクセスレベルや特典パッケージを作成できます。デジタルアーティストは、各作品の交換可能な複数の複製からなる限定版を発行できます。金融アプリケーションでは、トークンIDを使って満期日、請求権、ポジションカテゴリ、リスクグループを識別できます。報酬システムでは、複数のポイント種類や実績アイテムを1回のバッチトランザクションで配布できます。この規格自体は、トークンが法的に強制力のある権利や実世界資産を表しているか検証しません。

ERC-1155の承認リスク

オペレーター承認を狙ったフィッシングは、ERC-1155保有者にとって大きなリスクです。

悪意あるウェブサイトが、確認、アカウント接続、報酬へのアクセスを装って

を要求することがあります。

承認後、オペレーターはユーザーが当該コントラクトで保有するすべてのERC-1155トークンを送金できる可能性があります。所有者が取り消すまで、この権限は有効なままになることがあります。署名する前に、ネットワーク、トークンコントラクト、オペレーターアドレス、権限の種類を確認してください。オペレーター承認の取り消しに、ウォレットのリカバリーフレーズや秘密鍵が必要になることはありません。

バッチ操作のリスク

バッチ操作では、配列内の位置関係を正しく保つ必要があります。トークンIDと数量が一致しない場合、トランザクションは失敗する必要があります。インデックスの誤りによって、資産が誤った数量で送金される可能性があります。ユーザーが指定できる非常に大きな配列は、過剰なガスを消費したり、関数を利用不能にしたりする可能性があります。受取コントラクトは、バッチを受け入れる前に各IDと数量を検証する必要があります。開発者は、空の配列、重複ID、長さの不一致、大きなバッチ、非対応の資産IDをテストしてください。

供給量と真正性のリスク

現在1単位しか存在しないために、トークンIDが固有に見えることがあります。認可されたアカウントが後から追加の単位をミントできる可能性もあります。別のコントラクトで同じトークン名、ID、画像、メタデータをコピーすることも可能です。コントラクトアドレスとネットワークは、ERC-1155トークンの識別に不可欠です。ミント権限、供給量上限、アップグレード権限、メタデータ制御を確認してください。ERC-1155への互換性は、真正性、希少性、担保による裏付け、投資価値を証明しません。

アップグレード可能なコントラクトのリスク

ERC-1155コントラクトは、アップグレード可能なプロキシを通じて動作する場合があります。認可された管理者は、ミント、送金、承認、メタデータ、手数料、その他の動作を変更できる可能性があります。アップグレードで脆弱性を修正できる一方、有害なロジックが導入されることもあります。アップグレードキーが侵害されると、コントラクトが管理するすべてのトークンIDが危険にさらされる可能性があります。ユーザーはアップグレード権限、タイムロック、マルチシグ制御、緊急権限を確認してください。正しいインターフェースに対応していても、コントラクトが分散型または不変であるとは限りません。

開発者がERC-1155を実装する方法

独自の残高ロジックが必要でない限り、積極的に保守され、レビュー済みの実装を基に開発してください。

最新のERC-1155開発ガイドでは、マルチトークン残高、バッチ操作、受取確認、一般的な拡張機能を説明しています。

ミント機能と管理機能には、明確なアクセス制御を設けてください。供給量制限は、プロジェクト文書への記載だけでなく、コントラクトコードで適用する必要があります。実装では、必須の送金・承認イベントをすべて出力する必要があります。テストでは、単一送金、バッチ送金、ミント、バーン、オペレーター権限、無効な受取人、配列の不一致、悪意あるコールバックを検証してください。対応するすべての拡張機能について、ERC-165のインターフェース識別子が正しいことも確認してください。

ユーザーがERC-1155トークンを評価する方法

最初に、ブロックチェーンネットワーク、コントラクトアドレス、トークンIDを確認します。次に、トークンが代替可能、非代替性、準代替性のどれを想定しているか特定します。3つ目に、現在の供給量、ミント権限、供給量上限を確認します。4つ目に、ウォレットに関連付けられた有効なオペレーター承認を確認します。5つ目に、メタデータの保存方法と変更可能性を確認します。6つ目に、管理者、一時停止、凍結、ロイヤリティ、アップグレードの権限を特定します。7つ目に、ソースコード、監査、インシデント履歴を確認します。ただし、保証とみなしてはいけません。8つ目に、トークンが実際に提供するユーティリティ、償還権、法的請求権を理解します。9つ目に、受取コントラクトに信頼できる出金手段があるか確認します。10番目に、価値の高い資産を送る前に、使い慣れていないコントラクトを少額でテストします。

ERC-1155のバッチ送金の例

AliceがトークンID 1を100単位、トークンID 2を5単位、トークンID 3を1単位保有しているとします。AliceはBobに、ID 1を10単位、ID 2を2単位、ID 3を1単位送りたいと考えています。

Aliceのウォレットは、3つのIDと対応する数量を含む配列を使って

を呼び出します。

コントラクトはAliceの残高を検証し、呼び出し元が認可されていることを確認します。各IDについてAliceの残高を減らし、Bobの残高を増やします。

コントラクトは移動内容を記録する1つの

イベントを出力します。

Bobがスマートコントラクトの場合、トークンコントラクトは

を呼び出します。

受取人が正しい値を返すと、トランザクションは完了します。残高、権限、配列、受取確認のいずれかが失敗すると、トランザクション全体が取り消されます。

ERC-1155でよくある間違い

よくある間違いの1つは、すべてのERC-1155トークンIDがNFTを表すと思い込むことです。もう1つは、現在の単位数が1のIDについて、最大供給量も恒久的に1だと思い込むことです。3つ目は、コントラクト内のすべてのトークンIDが対象になることを理解せず、オペレーターを承認することです。4つ目は、ウォレットを切断すればオンチェーンの承認が削除されると思い込むことです。5つ目は、メタデータが利用可能であることをトークンがミント済みである証拠とみなすことです。6つ目は、すべてのコントラクトが総供給量関数を提供していると思い込むことです。7つ目は、長さや位置を確認せずにバッチ配列を処理することです。8つ目は、受取コールバックやリエントランシーのリスクを無視することです。9つ目は、報告されたロイヤリティが自動的に強制されると思い込むことです。10個目は、インターフェースへの準拠を真正性、希少性、安全性の証明とみなすことです。

よくある質問

ERC-1155とはどういう意味ですか？

ERC-1155は、1つのコントラクトで多数の代替可能、非代替性、準代替性トークンを管理するEthereumのマルチトークン規格です。

ERC-1155は暗号資産ですか？

ERC-1155は技術規格であり、これを実装したコントラクトからさまざまな種類の暗号資産を作成できます。

ERC-1155のインターフェースIDは何ですか？

ERC-1155のコアインターフェースIDは

です。

ERC-1155受取インターフェースIDは何ですか？

受取インターフェースIDは

です。

ERC-1155で代替可能トークンを作成できますか？

はい。1つのトークンIDで、複数アカウントに配布された交換可能な単位を多数表せます。

ERC-1155でNFTを作成できますか？

はい。コントラクトが供給量を1に制限すれば、トークンIDをNFTとして機能させられます。

準代替性トークンとは何ですか？

ある状況では単位同士が交換可能でも、後に個別の意味、ステータス、用途を持つトークンです。

1つのERC-1155コントラクトで多数の資産を管理できますか？

はい。1つのコントラクトで、供給量、メタデータ、用途が異なる多数のトークンIDを管理できます。

balanceOfは何を返しますか？

指定された1つのトークンIDについて、アカウントが保有する数量を返します。

balanceOfBatchは何をしますか？

複数のアカウントとトークンIDの組み合わせの残高を、1回の呼び出しで返します。

safeBatchTransferFromとは何ですか？

複数のトークンIDと数量を1回のトランザクションで送金し、受取人がスマートコントラクトの場合に受取確認を行います。

setApprovalForAllは何をしますか？

1つのERC-1155コントラクト内で、呼び出し元が保有するすべてのトークンIDをオペレーターが管理できるよう承認します。

ユーザーは1つのトークンIDだけを承認できますか？

ERC-1155のコア承認関数ではできませんが、任意の拡張機能でより限定的な権限を設定できます。

ERC-1155の承認は自動的に期限切れになりますか？

いいえ。標準のオペレーター承認は、所有者が取り消すか、カスタムロジックで効力が変更されるまで有効です。

ERC-1155では受取確認が必要ですか？

はい。スマートコントラクトへの標準セーフ送金では、単一またはバッチに応じた受取コールバックのルールに従う必要があります。

受取コントラクトはERC-1155トークンを拒否できますか？

はい。処理を取り消すか、誤った受入値を返すと送金は失敗します。

ERC-1155はメタデータに対応していますか？

はい。インターフェースID

の任意のメタデータURI拡張機能が含まれています。

すべてのERC-1155トークンに名前とシンボルがありますか？

いいえ。コア規格では、トークンIDごとの個別のオンチェーン名称やシンボル関数は必須ではありません。

ERC-1155ではdecimalsが定義されていますか？

いいえ。必要な場合、単位情報はメタデータまたはプロジェクト固有のロジックから取得する必要があります。

ERC-1155にtotalSupplyは含まれますか？

いいえ。総供給量の取得には、イベントのインデックス化または任意の供給量追跡拡張機能が必要です。

ERC-1155のメタデータは変更できますか？

はい。コントラクトまたは外部ストレージシステムが更新を許可している場合、変更できます。

ERC-1155はロイヤリティを強制しますか？

いいえ。ロイヤリティ情報には別の規格が必要で、コア送金関数によって自動的に強制されることはありません。

ERC-1155のバッチ送金でガス代を節約できますか？

はい。複数のトークン移動を1回のトランザクションにまとめると、重複するトランザクション処理を減らせます。

ERC-1155のコールバックでリエントランシーが発生する可能性はありますか？

はい。受取コールバックは外部コードを実行するため、元のトランザクションが完了する前に別のコントラクト関数を呼び出す場合があります。

ERC-1155への準拠でトークンは安全になりますか？

いいえ。互換性のあるコントラクトでも、安全でないコード、過剰な権限、変更可能なメタデータ、弱い供給量管理、不正な主張を含む可能性があります。

まとめ

ERC-1155は、1つのスマートコントラクトで多数のトークン種類を管理するEthereumの規格です。各トークンIDは、代替可能資産、固有のNFT、準代替性アイテム、またはその他の数量ベースの暗号資産を表せます。この規格では、残高照会、単一・バッチ送金、コレクション全体へのオペレーター承認、受取コールバック、イベント、メタデータルール、インターフェース検出が定義されています。複数資産をまとめて照会または送金する場合、バッチ操作によってトランザクション処理を減らせます。必須の受取コールバックは非対応コントラクトへの誤送金を減らしますが、外部呼び出しやリエントランシーのリスクを伴います。コア規格では、公開ミント、バーン、総供給量、decimals、ロイヤリティ、永続的なメタデータ、個別トークンのAllowanceは定義されていません。これらの特性は、任意の拡張機能や各コントラクトの実装によって異なります。ユーザーはネットワーク、コントラクトアドレス、トークンID、供給量制御、オペレーター承認、メタデータシステム、管理者権限を確認してください。開発者は保守されている実装を使い、必須イベントを出力し、受取コールバックを保護し、バッチの複雑さを制限して、あらゆる認可経路をテストしてください。ERC-1155は柔軟なマルチトークン基盤を提供しますが、技術的な互換性は真正性、希少性、金融的価値、スマートコントラクトの安全性を保証しません。