ERC-1155マルチトークン規格

ERC-1155マルチトークン規格とは？

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

公式のERC-1155仕様では、残高照会、単一送金、バッチ送金、オペレーター承認、受取側コールバック、イベント、任意のメタデータが標準化されています。

ERC-1155は、Final（最終版）のEthereum Request for Comments規格に分類されています。1つのコントラクト内の各トークンIDが個別の暗号資産を表せることから、一般に「マルチトークン規格」と呼ばれています。各トークンIDは、それぞれ固有の供給量、残高、メタデータ、希少性、用途、経済的特性を持つことができます。ERC-1155は、大規模なブロックチェーン資産群のデプロイや操作にかかるコストと複雑さを軽減する目的で設計されました。

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

従来のトークンモデルでは、異なる代替可能資産やNFTコレクションごとに、通常は別々のコントラクトが必要でした。そのため、数百種類の通貨、リソース、武器、キャラクター、イベントアイテムを含むブロックチェーンゲームでは、多数のコントラクトが必要になる場合がありました。コントラクトを何度もデプロイすると、バイトコード、管理作業、統合作業、トランザクションコストが増加します。ERC-1155は複数のトークン種類を1つのコントラクトにまとめ、共通の送金・承認システムを適用します。また、複数のトークンIDを1回のトランザクションで移動できる、標準化されたバッチ操作にも対応しています。このため、ゲーム、デジタルコレクティブル、会員権システム、トークン化されたインベントリ、金融ポジション、報酬プログラムなど、複数カテゴリの資産を扱う暗号資産アプリケーションに適しています。この規格はゲームに限定されず、複数のトークン種類を効率的に管理する必要があるあらゆるコントラクトで利用できます。

ERC-1155の仕組み

ERC-1155コントラクトは、アカウントアドレスとトークンIDの組み合わせごとに個別の残高を管理します。同一コントラクト内で、あるアドレスがトークンID 1を10単位、トークンID 2を1単位保有し、トークンID 3を保有していない状態にできます。各トークンIDは、代替可能資産、固有のNFT、または供給量に上限のある交換可能な資産として機能できます。トークンを移動すると、コントラクトは対象IDごとに送信者の残高を減らし、受取人の対応する残高を増やします。コントラクトは標準化されたイベントを出力し、ウォレットやインデクサーがトークンの発行、送金、破棄を再構成できるようにします。受取人がスマートコントラクトの場合、ERC-1155コントラクトは受取関数を呼び出し、受取人が資産を受け入れることを確認します。Ethereumノードはこれらのルールを実行し、デプロイされたコントラクトコードに従って残高変更を検証します。

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

トークンIDは、ERC-1155コントラクト内の1種類のトークンを識別する符号なし整数です。同じトークンIDが別のコントラクトに存在しても、同じ資産を表すとは限りません。したがって、ERC-1155資産はブロックチェーンネットワーク、コントラクトアドレス、トークンIDの組み合わせで識別されます。あるコントラクトのトークンID 25はゲーム内の代替可能リソースを表し、別のコントラクトでは固有のコレクティブルを表す可能性があります。この規格では、IDを0から始めること、連番にすること、特定の意味を持たせることは義務付けられていません。開発者はアプリケーションの構成に応じてIDを割り当てられます。アプリケーションは存在するトークンIDを推測せず、信頼できるコントラクトデータを照会する必要があります。

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

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

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

あるトークンIDの供給量を1単位に制限すると、そのIDは非代替性資産を表せます。その1単位を保有するアドレスが、トークンの所有者として機能します。同じコントラクト内の別のトークンIDで、異なる固有アイテムを表すこともできます。たとえば、トークンID 1001が1本の剣を、トークンID 1002が1区画の仮想土地を表すことができます。コア規格は、トークンIDの最大供給量を1に制限していません。IDをNFTとして機能させる場合、一意性はコントラクトのミントロジックで確保する必要があります。

準代替性トークン

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

ERC-1155のコア関数

コアインターフェースには、残高照会、トークン送金、オペレーター承認管理の関数が含まれます。

必須関数は

、、、、、です。

ERC-1155はERC-165によるインターフェース検出にも対応する必要があります。コアインターフェースでは、公開ミント、バーン、総供給量、ロイヤリティ、トークン名、シンボル、decimalsは必須ではありません。これらの機能は、拡張機能やカスタム実装ロジックで追加できます。

balanceOf関数

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

入力値として、アカウントアドレスとトークンIDの両方が必要です。通常1つのコントラクトが1種類のトークンを表し、関数にアカウントアドレスだけを指定するERC-20とは異なります。

また、

がコレクション内でアドレスの保有する固有NFTの数を返すERC-721とも異なります。

ERC-1155の残高は、コントラクトで認められる範囲で0、1、またはそれ以上の整数になります。ゼロアドレスへの残高照会は失敗する必要があります。

balanceOfBatch関数

関数は、複数のアカウントとトークンIDの残高を1回の呼び出しで取得します。

呼び出し元は、アカウントアドレスの配列と、それに対応するトークンIDの配列を渡します。返される各値は、同じ配列位置にあるアカウントとIDに対応します。2つの入力配列の長さは同じでなければなりません。この関数で、1つのアカウントが保有する複数資産、または複数アカウントが保有する1つの資産を照会できます。バッチ残高照会により、ウォレット、ゲーム、分析アプリケーションが必要とする個別呼び出しの数を減らせます。

safeTransferFrom関数

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

呼び出し元はトークン保有者、またはその保有者が承認したオペレーターでなければなりません。送信者は、選択したトークンIDを十分な数量保有している必要があります。受取人にゼロアドレスを指定することはできません。この関数では、アプリケーション固有の情報を格納できるbytesフィールドも指定できます。受取人がスマートコントラクトの場合、必要なERC-1155受取コールバックを通じて送金を受け入れる必要があります。

送金に成功すると、

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

safeBatchTransferFrom関数

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

呼び出し元は、トークンIDと値の対応する配列を渡します。各配列位置のトークンIDが、同じ位置の値に対応する数量だけ送金されます。配列の長さは同じでなければなりません。呼び出し元は保有者または承認済みオペレーターであり、保有者はバッチ内の各アイテムを十分に保有している必要があります。必要な送金のいずれかが失敗すると、通常、トランザクション全体が取り消されます。

バッチ送金に成功すると、トークンIDごとに個別の送金イベントを出力する代わりに、1つの

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

バッチ送金が重要な理由

バッチ送金では、複数種類の資産を1回のブロックチェーントランザクションで移動できます。ゲームユーザーは、通貨、素材、防具、コレクティブルアイテムをまとめて送れます。アプリケーションは、複数種類の報酬を1回の操作で受取人に配布することもできます。複数の個別トランザクションを送る場合と比べ、バッチ処理は重複するトランザクション処理を減らし、合計コストを抑えられる可能性があります。実際の節約額は、ID数、コントラクトの実装、ストレージ変更、ネットワーク状況、受取側のロジックによって異なります。非常に大きなバッチはガスを過剰に消費し、ブロックのガス上限により失敗する可能性があります。アプリケーションは、ユーザーが指定できるバッチサイズに妥当な上限を設定してください。

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

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

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

承認されたオペレーターは、その保有者が当該コントラクト内で保有するすべてのERC-1155トークンIDを管理できます。承認は現在の残高に加え、保有者が後から同じコントラクトで受け取るトークンにも適用されます。コア規格には、1つのトークンIDだけ、または数量を限定して承認する関数はありません。広範な権限によりアプリケーションの使いやすさが向上する一方、重大なセキュリティリスクも生じます。承認する前に、オペレーターのアドレスとコントラクトを確認してください。

isApprovedForAll関数

関数は、あるアドレスが別のアドレスのトークンに対するオペレーター権限を持つかどうかを返します。

戻り値は

またはです。

承認は、記録されたERC-1155コントラクト内でのみ適用されます。ERC-20トークン、ERC-721 NFT、または別のERC-1155コントラクト内の資産を自動的に操作できるようになるわけではありません。ユーザーは有効なオペレーター承認を定期的に確認し、不要になった権限を取り消してください。ウォレットをウェブサイトから切断しても、オンチェーンに記録されたオペレーター承認は削除されません。

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

特定のトークンIDや数量だけを承認したい場合、ERC-1155の広範な承認モデルは適さないことがあります。追加規格やカスタムコントラクトにより、より限定的な権限を実現できます。

ERC-5216 Allowance拡張は、特定のERC-1155トークンIDに対する承認数量を定義します。

このような拡張機能への対応は任意であり、対応を前提にしてはいけません。ウォレットは、限定されたトークンIDへのAllowanceと、コレクション全体への標準承認を明確に区別する必要があります。

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

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

受取インターフェースには、単一送金用の

と、バッチ送金用のが含まれます。

受取インターフェースのERC-165識別子は

です。

受取コントラクトは、オペレーター、以前の保有者、トークンID、数量、付随データを確認します。送金を受け入れるには、期待される受入値を返さなければなりません。そうでない場合、送金は取り消されます。この仕組みにより、ERC-1155資産を処理できないコントラクトへの誤送金を減らせます。

単一送金の受取コールバック

関数は、単一送金に伴い受取人の残高が更新された後に呼び出されます。

期待される受入値は

です。

受取側は、トークンコントラクト、オペレーター、送信者、トークンID、数量、付随データを検証できます。必要な値を返すことで送金を受け入れられます。送金を拒否するには、処理を取り消すか、別の値を返します。受取コントラクトは、呼び出し元のトークンコントラクトを検証せずに、コールバックデータだけを根拠として入金を記録してはいけません。

バッチ送金の受取コールバック

関数は、複数のトークンIDを1回の送金で受け取る場合に処理を行います。

期待される受入値は

です。

IDと数量の配列は、同じ順序で対応付けて解釈する必要があります。受取側は配列の長さを検証し、対応する各トークンIDがアプリケーションのルールに従うことを確認してください。誤った値を返すか処理を取り消すと、バッチ送金全体が失敗します。1回のトランザクションで多様な資産が届く可能性があるため、バッチ受取機能は慎重に設計する必要があります。

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

ERC-1155の受取コールバックは、元の送金トランザクションが完了する前に外部コントラクトのコードを実行します。受取コントラクトは、コールバック中にトークンコントラクトや別のアプリケーションを再度呼び出す可能性があります。これにより、リエントランシーが発生する経路が生じます。ERC-1155仕様では、受取フックの呼び出し前に残高と送金イベントを更新することが求められています。それでも、アプリケーションコントラクトは独自の会計処理と認可ロジックを保護する必要があります。

意図したロジックで可能な場合は、外部呼び出しの前にチェックと重要な状態変更を完了することを、Solidityのセキュリティガイダンスが推奨しています。

開発者は、同一関数および異なる関数への再入を試みる悪意あるコントラクトを使って、両方の受取関数をテストしてください。

ERC-1155イベント

コア規格では、

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

これらのログにより、ウォレット、エクスプローラー、インデクサー、分析システムはトークンの動きを追跡できます。この規格は、送金イベントからトークン残高や供給量の変化を再構成できるよう設計されています。トークンの発行、送金、破棄時には、実装が正しいイベントを出力する必要があります。イベントは必ず、イベントを出力したコントラクトアドレスと併せて解釈してください。

TransferSingleイベント

イベントは、1種類のトークンについて、オペレーター、送信者、受取人、トークンID、数量を記録します。

通常の送金では、送信者と受取人のアドレスはゼロではありません。ミントでは送信者にゼロアドレスを使用します。バーンでは受取人にゼロアドレスを使用します。数量がゼロの送金でも、適切なイベントを出力する必要があります。監視システムはこれらのログを使って、インデックス化した残高記録を更新できます。

TransferBatchイベント

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

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

ApprovalForAllイベント

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

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

ERC-1155のインターフェース検出

ERC-1155は、ERC-165インターフェース検出規格への対応を必須としています。

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

です。

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

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

ERC-165規格は、スマートコントラクトが対応インターフェースを公開・検出する方法を定めています。

インターフェース検出は、アプリケーションが未対応の関数を呼び出さないようにするのに役立ちます。コントラクトが誤った対応を申告したり、関数を正しく実装していなかったりする可能性があるため、肯定的な応答だけで安全性が保証されるわけではありません。

ERC-1155のメタデータ

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

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

関数が追加されます。

インターフェースIDは

です。

返される場所は通常、名称、説明、画像、属性、外部リソースなどを含むJSONドキュメントを指します。

ERC-20やERC-721のメタデータインターフェースとは異なり、ERC-1155のコア設計では、オンチェーンの

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

プロジェクトはカスタム拡張機能を使って、これらの関数を追加できます。

{id}メタデータの置換

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

を含められます。

アプリケーションはこのプレースホルダーを、要求されたトークンIDを小文字の16進数で表した値に置き換えます。

先頭のゼロを含めて64文字にし、

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

この形式により、1つのベースURIで多数のトークンIDのメタデータ保存先を表せます。置換を正しく行わないと、アプリケーションが誤ったメタデータファイルを要求する可能性があります。

URIイベント

イベントは、トークンIDに関連付けられたメタデータURIを通知します。

プログラムによらないURIの変更をメタデータ拡張機能で表現できる場合、実装は変更時にイベントを出力する必要があります。

イベントが出力された場合、

関数は、そのIDについて最新のURIイベントと同じ値を返す必要があります。

有効なURIが存在しても、トークンIDがミント済みであるとは限りません。トークンの存在を判定する際、アプリケーションはメタデータの有無ではなく、残高と送金イベントを利用してください。

メタデータ保存のリスク

ERC-1155のメタデータは、従来型サーバー、コンテンツアドレス型ネットワーク、またはオンチェーンに保存できます。サーバー上のコンテンツは変更されたり、消失したりする可能性があります。コンテンツアドレス型ストレージは、識別子がファイルと一致すれば完全性を高めますが、継続的な可用性には依存します。オンチェーンメタデータは外部ホスティングへの依存を減らせますが、ストレージやデプロイのコストが増加します。変更可能なコントラクトURIを使うと、ユーザーがトークンを取得した後に名称、画像、属性、説明を変更できる場合があります。ユーザーは誰がメタデータを変更できるのか、参照先のコンテンツが継続して利用できる見込みかを確認してください。

ERC-1155トークンのミント

ミントとは、トークン単位を作成してアドレスに割り当てることです。ERC-1155のコアインターフェースには、公開ミント関数が定義されていません。誰がミントできるか、どのIDを作成できるか、供給量の上限を設けるかは、各実装で決まります。

ミント時には、送信者をゼロアドレスとする

またはを出力する必要があります。

スマートコントラクトにミントする場合、通常は適切な受取コールバックが適用されます。NFTのように見えるIDの供給量が恒久的に制限されていると決めつけず、ミント権限を確認してください。

ERC-1155トークンのバーン

バーンとは、コントラクトの実装に従ってトークン単位を残高から恒久的に取り除くことです。コアインターフェースでは、公開バーン関数は必須ではありません。保有者、承認済みオペレーター、管理者、その他のプロトコルロジックに資産のバーンを許可することができます。バーン時には、受取人をゼロアドレスとする適切な送金イベントを出力する必要があります。あるIDの既存単位をすべてバーンしても、同じIDを再びミントできないとは限りません。結果は、コントラクトの供給量とアクセス制御のルールによって異なります。

ERC-1155の総供給量

ERC-1155のコア規格には

関数が定義されていません。

実装が必要なイベントルールに従っている場合、ミントとバーンのイベントから各トークンIDの供給量を計算できます。コントラクトに供給量追跡拡張機能を追加すれば、オンチェーンでの照会が容易になります。

最新のERC-1155実装APIには、トークンIDごとの総供給量を追跡する任意の拡張機能が含まれています。

すべてのERC-1155コントラクトが同じ供給量関数を公開しているとは限らないため、アプリケーションは注意してください。

ERC-1155の列挙

ERC-1155には、すべてのトークンIDや保有者を一覧表示するコア関数が定義されていません。

この規格では、オフチェーンシステムが

、、イベントからトークンの動きを再構成することを想定しています。

通常、インデクサーはコントラクトのデプロイブロックから処理を開始し、最新ブロックまでイベントを処理します。イベントを取りこぼすと、残高や供給量の記録に誤りが生じる場合があります。コントラクトにカスタムの列挙関数を追加することはできますが、広く利用できる機能ではありません。

ERC-1155のロイヤリティ

ERC-1155のコア規格では、クリエイターロイヤリティは定義されていません。

任意のERC-2981ロイヤリティ規格を利用すると、トークン販売におけるロイヤリティ受取人と推奨支払額を提供できます。

ERC-2981はERC-1155と互換性があり、デフォルトまたはトークン固有のロイヤリティ情報を設定できます。この規格は支払い情報を伝えるものであり、すべてのアプリケーションに支払いを強制するものではありません。管理者に権限が与えられている場合、ロイヤリティ設定を変更できることもあります。

ERC-1155の標準エラー

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

Final（最終版）のERC-6093規格は、ERC-1155実装でよく使われるエラーを定義しています。

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

ERC-1155とERC-20の比較

ERC-20では、通常1つのコントラクトが1種類の代替可能トークンを表します。ERC-1155では、1つのコントラクトで多数の代替可能・非代替性トークンIDを表現できます。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コントラクトで通貨、素材、キャラクター、武器、土地、限定アイテムを管理できます。イベントシステムでは、1つのコントラクトから複数カテゴリ・数量のチケットを発行できます。会員権プロジェクトでは、異なるアクセスレベル、有効期限グループ、特典パッケージを別々のトークンIDで管理できます。デジタルコレクティブルのプロジェクトでは、各作品の交換可能な複数の複製からなるエディションを作成できます。金融アプリケーションでは、IDを満期日、リスクグループ、請求権、ポジションカテゴリの表現に利用できます。報酬システムでは、複数のポイント種類や実績アイテムを1回のバッチ処理で配布できます。この規格は、トークンが有効な法的権利や実世界資産を表していることを検証するものではありません。

承認フィッシングのリスク

悪意あるアプリケーションが、確認やウォレット接続を装って

の実行をユーザーに求める場合があります。

承認すると、そのオペレーターは当該ERC-1155コントラクトでユーザーが保有するすべてのトークンIDを送金できます。承認は、ユーザーが後から受け取るトークンにも適用される場合があります。署名する前に、ネットワーク、トークンコントラクト、オペレーターアドレス、権限の種類を確認してください。ウォレットのインターフェースでウェブサイトへのアクセスを取り消しても、オンチェーンの承認は自動的に取り消されません。ERC-1155のオペレーター権限を取り消すために、リカバリーフレーズや秘密鍵が必要になることはありません。

バッチ処理のリスク

バッチ操作では、要素同士の対応関係を正しく保つ必要がある配列を処理します。IDと数量が一致しない場合、トランザクションは失敗する必要があります。インデックスの誤りにより、資産が誤った数量で送金される可能性があります。大きなバッチはトランザクションのガス上限を超えたり、サービス妨害を引き起こしたりする可能性があります。受取側が経済的に一部のIDしか受け入れない場合もあるため、受取コントラクトは受領を確定する前にバッチ全体を検証する必要があります。アプリケーションはバッチサイズを制限し、実装ルールに応じて重複IDや順不同のIDをテストしてください。

受取側とリエントランシーのリスク

セーフ送金では、残高更新後に外部の受取コードが呼び出されます。悪意ある受取側は、ミント、送金、販売、ステーキング、貸付、出金の関数への再入を試みる可能性があります。別の関数で関連状態が公開されている場合、ある関数にリエントランシーガードを設けてもコントラクトが脆弱なままになることがあります。開発者は単一操作とバッチ操作の両方に、一貫した状態遷移ロジックを適用してください。受取コールバックは呼び出し元のトークンコントラクトを検証し、ユーザー提供データを自動的に信頼してはいけません。セキュリティテストには、ネストされた送金、転送を行う受取コントラクト、コールバックの取り消し、コントラクト間のやり取りを含めてください。

供給量と真正性のリスク

現在1単位しか存在しないために、ERC-1155トークンIDが固有に見えることがあります。しかし、認可されたミンターが後から追加の単位を作成できる可能性があります。別のコントラクトで、コレクション名、画像、トークンIDをコピーすることも可能です。コントラクトアドレスとネットワークは、資産の識別に不可欠です。希少性に関する主張を信頼する前に、ミント権限、供給量拡張機能、管理者権限、アップグレード制御を確認してください。ERC-1155への準拠は、真正性、裏付け、希少性、金融的価値を証明するものではありません。

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

ERC-1155コントラクトは、アップグレード可能なプロキシの背後で動作する場合があります。認可された管理者は、ミント、送金、承認、メタデータ、手数料、受取側の動作を変更できる可能性があります。アップグレードで不具合を修正できる一方、悪意あるコードや安全でないコードが導入されることもあります。アップグレードキーが侵害されると、コントラクト内のすべてのトークンIDが危険にさらされる可能性があります。ユーザーはアップグレード権限、タイムロック、マルチシグ要件、緊急時の制御機能を確認してください。正しいインターフェースに対応していても、強力な中央集権的権限を持つコントラクトは存在します。

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

特別な理由なく残高処理を独自に書き直すのではなく、積極的に保守され、レビュー済みの実装を基に開発してください。

最新のERC-1155開発ガイドでは、コアコントラクトとマルチトークン残高・バッチ操作の仕組みが説明されています。

ミント機能と管理機能には、明確なアクセス制御を設けてください。供給量の制限は、プロジェクト文書に記載するだけでなく、コントラクトのロジックで適用する必要があります。必須イベントをすべて出力し、ERC-165のインターフェース値を正しく返してください。テストでは、単一送金、バッチ送金、承認、バーン、ミント、配列の不一致、無効な受取側、悪意あるコールバック、メタデータの変更を検証してください。

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

最初に、ブロックチェーンネットワーク、コントラクトアドレス、トークンIDを確認します。次に、その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つは、トークンIDの最大供給量が1に制限されていると思い込むことです。3つ目は、コントラクト内のすべてのIDが対象になることを理解せずにオペレーターを承認することです。4つ目は、ウォレットを切断すればオンチェーンの承認が削除されると思い込むことです。5つ目は、メタデータが利用可能であることをトークンの存在証明として扱うことです。6つ目は、ERC-1155にすべてのIDの総供給量関数が定義されていると思い込むことです。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として機能させられます。

ERC-1155の準代替性トークンとは何ですか？

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

1つのERC-1155コントラクトに複数の資産種類を含められますか？

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

balanceOfは何を返しますか？

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

balanceOfBatchは何をしますか？

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

safeBatchTransferFromとは何ですか？

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

setApprovalForAllは何をしますか？

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

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

コア承認関数ではできませんが、任意の拡張機能やカスタムコントラクトで、より限定的な権限を実現できます。

ERC-1155のオペレーター承認は期限切れになりますか？

いいえ。承認を取り消すか、カスタムコントラクトのロジックで効力を変更するまで有効です。

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

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

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

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

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

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

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

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

いいえ。コア規格では、オンチェーンの名前やシンボル関数は必須ではありません。

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

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

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

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

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

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

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

いいえ。ロイヤリティ情報には別の規格が必要であり、報告されたロイヤリティがトークンコントラクトによって自動的に強制されるわけではありません。

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

はい。複数のトークンIDを1回のトランザクションで送ると、重複するトランザクション処理を減らせる場合があります。

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

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

ERC-1155への準拠は、トークンの安全性を証明しますか？

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

まとめ

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