ERC-1155

ERC-1155 ist Ethereums Multi-Token-Standard: Ein Vertrag kann viele fungible, nicht fungible oder gemischte Token-Typen anhand ihrer ID verwalten und mehrere IDs gebündelt übertragen.

Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.

Direkte Antwort

ERC-1155 ist Ethereums Multi-Token-Standard. Ein einziger Vertrag kann viele Token-Typen verwalten, und jede token ID kann ein fungibles Guthaben, einen nicht fungiblen Gegenstand oder eine andere, von der Implementierung bestimmte Angebotsstruktur repräsentieren. Der Asset-Schlüssel lautet daher contract address + token ID und nicht nur Token-ID.

Der Standard definiert einzelne und gebündelte Guthabenabfragen, einzelne und gebündelte sichere Übertragungen, eine vertragweite Operatorfreigabe, Empfänger-Callbacks, Übertragungsereignisse und optionales Verhalten für Metadaten-URIs. Er legt nicht fest, wer prägen darf, ob das Angebot begrenzt ist, ob Metadaten dauerhaft sind, welche rechtlichen Ansprüche ein Token vermittelt oder welchen Wert ein Token hat. Diese Eigenschaften müssen am konkreten Vertrag, seinen Rollen und seinen externen Abhängigkeiten überprüft werden.

Funktionsweise

Guthaben bestimmen. balanceOf(account, id) gibt die Menge zurück, die ein Konto von einer ID hält. balanceOfBatch(accounts, ids) fragt paarweise Konto-ID-Einträge ab. Zwei Verträge können beide die ID 1 für voneinander unabhängige Assets verwenden; die vollständige Identität umfasst daher weiterhin Chain, Vertragsadresse und ID.
Aufrufer autorisieren. Ein Inhaber kann sein eigenes Guthaben übertragen oder setApprovalForAll(operator, true) aufrufen. Diese Freigabe gilt für jede ERC-1155-ID, die der Inhaber in diesem Vertrag besitzt; isApprovedForAll(owner, operator) zeigt den Status an. ERC-1155 enthält keine native Freigabe, die auf eine einzelne ID oder Menge beschränkt ist.
Einzel- oder Batch-Transfer ausführen. safeTransferFrom überträgt eine ID und Menge. safeBatchTransferFrom überträgt die parallelen Arrays ids und values, deren Länge und Reihenfolge übereinstimmen müssen. Batching kann wiederkehrenden Transaktionsaufwand reduzieren, ist aber nicht garantiert bei jeder Implementierung oder Arbeitslast günstiger.
Vertrag als Empfänger prüfen. Nach der Aktualisierung der Guthaben und dem Auslösen des relevanten Ereignisses ruft eine konforme Übertragung an einen Vertrag onERC1155Received oder onERC1155BatchReceived auf. Ein nicht unterstützter Callback, ein falscher Rückgabewert oder eine Ablehnung macht die Übertragung normalerweise rückgängig. Diese Empfängerprüfung verringert versehentliche Sperrungen; sie beweist nicht, dass der empfangende Vertrag vertrauenswürdig ist oder eine Auszahlungsmöglichkeit bietet.
Zustand aus Ereignissen rekonstruieren. Jede Prägung, Übertragung und Verbrennung muss durch TransferSingle oder TransferBatch abgebildet werden. Bei der Prägung wird die Nulladresse als from verwendet, bei der Verbrennung als to. Indexer können aus diesen Protokollen Guthaben und das netto geprägte Angebot je ID ableiten, müssen aber die gesamte Historie, Chain-Reorganisationen und Vertragsmigrationen korrekt verarbeiten.
Metadaten auflösen. Die optionale URI-Erweiterung kann eine gemeinsame Vorlage mit {id} zurückgeben. Ein Client ersetzt sie durch die kleingeschriebene, mit Nullen auf 64 Zeichen aufgefüllte hexadezimale Token-ID ohne Präfix 0x. Metadaten können dennoch veränderlich, nicht verfügbar oder irreführend sein, sofern Implementierung und Speichergarantien nichts anderes vorgeben.

Durchgerechnetes Beispiel

Ein Spielvertrag weist Goldmünzen die ID 1, Zugangspässen die ID 7 und einem einzigartigen Schwert die ID 42 zu. Alice hält balanceOf(Alice, 1) = 500, balanceOf(Alice, 7) = 3 und balanceOf(Alice, 42) = 1.

Alice ruft safeBatchTransferFrom mit ids = [1, 7, 42] und values = [120, 1, 1] auf. Wenn die Validierung erfolgreich ist, lauten ihre neuen Guthaben 500 - 120 = 380, 3 - 1 = 2 und 1 - 1 = 0; der Empfänger erhält die entsprechenden Mengen.
Der Vertrag löst TransferBatch aus. Ist der Empfänger ein Vertrag, muss er den Batch über onERC1155BatchReceived akzeptieren; andernfalls wird die gesamte Transaktion rückgängig gemacht und keine der drei Guthabenänderungen bleibt bestehen.
ID 42 verhält sich nur deshalb nicht fungibel, weil ihre Ausgabe- und Übertragungslogik das Angebot bei 1 hält. ERC-1155 selbst erzwingt diese Regel nicht. Derselbe Vertrag kann später vorbehaltlich seiner eigenen Zugriffskontrolle weitere Einheiten der ID 1 prägen.

Risiken und Kontrollen

Weitreichende Operatorbefugnis. Ein böswilliger oder kompromittierter Operator, der über setApprovalForAll freigegeben wurde, kann jede in diesem Vertrag gehaltene ID übertragen. Prüfen Sie Operatoradresse und Vertrag, verwenden Sie gegebenenfalls eine separate Wallet und widerrufen Sie veraltete Freigaben.
Befugnisse zum Prägen, Pausieren und Upgraden. Dies sind Implementierungsmerkmale, keine Garantien des Standards. Prüfen Sie Rolleninhaber, Proxy-Administratoren, Timelocks, Angebotserweiterungen und ob ein Upgrade Guthaben oder Übertragungsregeln ändern kann.
Abweichung zwischen Metadaten und Asset. Eine URI oder gehostete JSON-Datei kann sich ändern, während die On-Chain-ID gleich bleibt. Prüfen Sie Inhalts-Hashes, Beständigkeit des Speichers, Zusagen des Emittenten und die außerhalb des Token-Vertrags repräsentierten Rechte.
Integrationsfehler. Wallets und Indexer können Batch-Arrays falsch zuordnen, historische Ereignisse übersehen, Reorganisationen falsch behandeln oder dieselbe ID über Verträge und Chains hinweg verwechseln. Gleichen Sie Vertragsaufrufe, Protokolle und endgültige Guthaben ab.
Empfänger- und Reentrancy-Risiko. Empfänger-Callbacks führen während des Übertragungsablaufs externen Code aus. Implementierungen und integrierende Protokolle benötigen eine geeignete Zustandsreihenfolge und Schutzmaßnahmen gegen Reentrancy; Callback-Unterstützung allein ist keine Sicherheitsprüfung.
Kosten- und Liquiditätsrisiko. Batch-Transfers verbrauchen weiterhin Gas und werden atomar rückgängig gemacht, wenn eine erforderliche Bedingung fehlschlägt. Marktliquidität, Preisbildung, Royalties, Bridging, Einlösung und Off-Chain-Durchsetzung liegen außerhalb von ERC-1155.

Häufige Missverständnisse

„Jede ID ist ein NFT.“ Eine ID kann eine beliebige Menge haben; Nicht-Fungibilität hängt vom Angebot und der Semantik der Implementierung ab.
„Ein Vertrag bedeutet eine Sammlung.“ Ein Vertrag kann viele voneinander unabhängige Token-Typen enthalten, und dieselbe numerische ID in einem anderen Vertrag bezeichnet ein anderes Asset.
„Sichere Übertragung bedeutet, dass das Asset sicher ist.“ Der Callback prüft die Kompatibilität des Empfängers, nicht die Qualität des Vertrags, den Preis, die Metadaten oder die Wiedererlangbarkeit.
„Batching spart immer Gas.“ Es vermeidet häufig wiederkehrenden Aufwand, doch das tatsächliche Ergebnis hängt von Implementierung, Anzahl der IDs, Speicheränderungen, Calldata und Gebührenmodell des Netzwerks ab.