NFT (Non-Fungible Token)

• Digitale Kunst: Künstler verkaufen Bilder direkt an Fans (Bored Apes, Beeple).
• Gaming: Ein Schwert in einem Spiel gehört dir wirklich. Du kannst es in ein anderes Spiel mitnehmen (Interoperabilität) oder verkaufen.
• Tickets: Eintrittskarten als NFT. Verhindert Schwarzmarkt-Betrug.

1. Metadata Storage

Der NFT selbst (der Token auf der Chain) ist winzig. Er speichert nicht das Bild! (Zu teuer). Er speichert nur einen Link (URI). https:// mein-server.com/affe.jpg. Gefahr: Wenn der Server offline geht, hast du einen "toten Link" für 1 Million Dollar gekauft. Lösung: IPFS (InterPlanetary File System). Ein dezentrales Speichernetzwerk.

2. Standards (ERC-721 vs. ERC-1155)

• ERC-721: Der Klassiker. Ein Token pro Vertrag.
• ERC-1155: Der Multi-Token. Kann fungible (Gold) und nicht-fungible (Schwert) Items in einem einzigen Vertrag mischen. Spart massiv Gas-Gebühren.

1. ERC-721 State Internals & The Approvals Vector

Wie weiß Ethereum, dass dir der Affe gehört? Ein ERC-721 Smart Contract ist intern schlicht eine gigantische Hash-Map in der LevelDB des EVM-States: mapping(uint256 => address) private _owners;. Token-ID 42 mapped auf Adresse 0xABC. Die größte Security-Falle ist das Dapp-Ecosystem. Wenn du dein NFT auf OpenSea "vermitteln" willst, musst du der OpenSea-Exchange-Adresse das Recht geben, den Token physisch per Smart-Contract-Call zu verschieben. Du klickst "Approve". Die Signatur ändert die Hashmap: mapping(uint256 => address) private _tokenApprovals;. Noch schlimmer ist setApprovalForAll, womit du einem externen Wallet die Master-Rechte über deine gesamte Kollektion des Vertrages gibst. Hacker operieren nicht, indem sie deine Private Keys stehlen, sondern indem sie Phishing-Dapps bauen, bei denen du unbemerkt setApprovalForAll(hacker_address, true) signierst. Dein Wallet ist intakt, aber der Hacker kann den State Map beliebig leerräumen (Metamask Warnungen, blind signiert).

2. IPFS Mutability und Frozen Metadata

Ein ERC-721 Contract hält niemals JPEG Bytes (Gas Costs von 1 MB Jpeg wären > 10.000$ im EVM). Er hat nur eine Variable: tokenURI(uint256) -> ipfs://QmHash123.... IPFS (InterPlanetary File System) sichert Daten per Merkle-DAG Content-Addressing. Verändert jemand den Pixel-Farbton des Affen, ändert sich unweigerlich der QmHash..., womit die Verknüpfung reißt. Das Problem: Wenn der Entwickler seinen Smart Contract schlampig baut, bleibt die setTokenURI Funktion für den Creator auf "public/onlyOwner". Solche NFTs ("Rug Pulls") erlauben es dem Projekt-Gründer, nachträglich den URI Link auf einen zentralen AWS-Server umzuboxen und das Bild des gekauften Schwertes in einen Kothaufen ("Poop-Emoji Switch") zu verwandeln! Profi-NFTs implementieren freezeMetadata, ein State-Flag, das nach dem Initial-Minting jegliches Überschreiben der URI-Pointer hart im EVM-Code für immer blockt.

3. ERC-1155 (Multi Token Standard) & Gas Optimization

Bei ERC-721 brauchte es für das Minten von 10 identischen VIP-Tickets 10 dedizierte Write-Transaktionen ins EVM Mainnet. Jede belastete den Base-Fee Tarif massiv (z.B. je 15$ = 150$). Der Erfinder Enjin entwickelte den ERC-1155 Standard, welcher die Blockchain-Ökonomie rettete. ERC-1155 packt alles parallel: mapping(uint256 => mapping(address => uint256)) private _balances;. Das bedeutet, man kann 1 Token "Münze" (Fungible) im gleichen Contract wie "Schwert Level 5" (Non-Fungible, Menge 1) managen. Die Magie ist das Batch-Transfer Array: safeBatchTransferFrom(from, to, [schwert_ID, gold_ID], [1, 500]). Mit exakt einem Gas-Cost Payload ändert die EVM nun 20 State-Werte synchron (O(1) Overhead). Dies ermöglicht komplexe dezentrale Rollenspiele und Web3 Gaming-Skalierung, ohne dass Play-to-Earn Microtransactions durch Transaktionsgebühren auffressen.