IPFS vs. Arweave: Speicherort für Metadaten und Dokumente eines Tokens

Jeder Token einer ERC-721-Kollektion hat in seinem Contract eine Referenz, dietokenURI, die auf eine JSON-Datei mitMetadatenverweist, die ihrerseits das Bild verlinkt; ein Security Token kann auf dieselbe Weise die Adresse oder denHashdes Emissionsprospekts speichern. Eine mehrere Megabyte große Datei on-chain zu schreiben, würde Gas proportional zu ihrer Größe kosten, deshalb legt der Contract nur die Referenz fest, und die Datei liegt in einem anderen Netzwerk.IPFSund Arweave sind zwei Netzwerke für dezentrale Speicherung, die diesen Teil mit entgegengesetzten Modellen lösen.

Die On-Chain-Referenz hält so lange, wie die Zusage gilt, die Bytes aufzubewahren, auf die sie verweist. IPFS trennt zwei Funktionen: Der Content Identifier (CID) erlaubt die Prüfung, ob eine Datei die angeforderte ist, aber die Datei bleibt nur verfügbar, solange irgendein Node sie gepinnt hält, und die CID selbst hängt davon ab, wie die Datei importiert wurde. Arweave berechnet im Voraus die Speicherung von 20 Replikaten über 200 Jahre zu heutigen Kosten; im Gegenzug lassen sich die Daten nicht entfernen, und jeder Node und jedes Gateway wendet eine eigene Inhaltsrichtlinie an. Die Wahl zwischen beiden bedeutet zu entscheiden, wer für diese Bytes einsteht, wenn das Team, das sie veröffentlicht hat, dies nicht mehr tut, und was passiert, wenn sie korrigiert werden müssen.

Was der Contract speichert und was außerhalb des Netzwerks bleibt

Der Contract garantiert, dass die Referenz nicht ohne seine Regeln geändert wird: Ist die tokenURI unveränderlich, kann sie niemand ersetzen, und gibt es eine Funktion zu ihrer Aktualisierung, ist die Frage, wer sie ausführen darf, eine Berechtigungsentscheidung, die im Code festgelegt ist. Was der Contract nicht kontrolliert, ist die Verfügbarkeit des Ziels. Eine tokenURI, die auf einen Webserver verweist, hängt davon ab, dass dieser Server weiter antwortet und das JSON nicht ändert; eine, die auf eine IPFS-CID verweist, davon, dass irgendein Node diesen Inhalt ausliefert, und eine, die auf eine Arweave-Transaktions-ID verweist, davon, dass das Netzwerk und seine Gateways sie weiterhin ausliefern.

Der Unterschied zwischen den beiden Netzwerken liegt darin, wie diese Verfügbarkeit bezahlt wird und wer sie trägt. In IPFS zahlt sie laufend, wer die Nodes betreibt, die den Inhalt pinnen, ob eigene oder die eines Anbieters. In Arweave zahlt sie, wer die Daten hochlädt, ein einziges Mal, in einen Fonds, der die Miner fortlaufend in dem Maße vergütet, wie sie nachweisen, dass sie die Daten speichern.

IPFS: Die CID identifiziert den Inhalt, der Pin bewahrt ihn

Eine CID wird aus dem Inhalt berechnet, sodass der Empfänger prüfen kann, ob die Daten der angeforderten Referenz entsprechen. DiePersistenz-Dokumentation von IPFSstellt klar, dass das nicht bedeutet, dass jemand sie aufbewahrt: Jeder Node gibt per Garbage Collection Speicherplatz frei und schützt nur, was er gepinnt hat, und der Inhalt geht verloren, wenn der letzte Node, der ihn hielt, damit aufhört. Pinning-Dienste betreiben Nodes und pinnen Daten gegen eine Gebühr, und dieselbe Dokumentation weist darauf hin, dass es keine Garantie gibt, dass sie den Dienst aufrechterhalten.

In Kubo, der Go-Implementierung von IPFS, deren aktuelle Version die0.43.1vom September 2026 ist, wird die automatische Garbage Collection nur aktiviert, wenn der Daemon mit --enable-gc gestartet wird. Dann läuft sie stündlich oder sobald der Speicher 90% seines Limits erreicht, das standardmäßig bei 10 GB liegt, laut seinerKonfigurationsreferenz. Ein Entwicklungs-Node ohne diese Option kann Dateien, die niemand gepinnt hat, unbegrenzt aufbewahren und den Eindruck erwecken, der Inhalt sei gesichert, bis zu dem Tag, an dem der Node neu installiert oder abgeschaltet wird.

Dieselbe Datei mit zwei verschiedenen CIDs

Nehmen wir als hypothetisches Beispiel eine Kollektion von 5.000 NFTs, deren Metadaten mit einem eigenen Kubo-Node in der Standardkonfiguration hochgeladen wurden und deren Contract als Basis der tokenURI die CID dieses Ordners festlegt. Mit diesen Werten erzeugt ipfs add CIDs der Version 0, ohne Raw-Leaves und mit Blöcken von 262.144 Bytes. Ein Jahr später beschließt das Team, das Pinning an einen Anbieter zu übergeben, und fügt dafür dieselben Dateien erneut mit einem Werkzeug hinzu, das mit dem Profil unixfs-v1-2025 konfiguriert ist, das Kubo für neue Projekte empfiehlt: CIDs der Version 1, Raw-Leaves, SHA-256 und Blöcke von 1 MiB.

Die Bytes sind identisch, die resultierende CID ist es nicht. Die CID ist nicht der Hash der Datei, sondern die Wurzel des Graphen, in den sie zerlegt wird, und sie ändert sich mit der Version, der Blockgröße und dem Format der Leaves; die Kubo-Referenz weist zudem darauf hin, dass nur das Chunking mit fester Größe dieselbe CID für dieselben Daten garantiert, und die SpezifikationIPIP-499definiert diese Profile gerade deshalb, damit die Berechnung über Implementierungen hinweg reproduzierbar ist. Der Anbieter pinnt die neue CID, der eigene Node wird abgeschaltet, und die tokenURI des Contracts verweist weiterhin auf die ursprüngliche CID, die niemand mehr im Netzwerk bereitstellt. Die Metadaten existieren, aber nicht unter der Adresse, die der Contract veröffentlicht.

Die korrekte Migration erfolgt CID-basiert, nicht dateibasiert. Mit Kubo lässt sich der vollständige Graph mit ipfs dag export als CAR-Datei exportieren und mit ipfs dag import in einen anderen Node importieren, und diePinning Service APIdefiniert den Pin als Anfrage mit der CID, die rekursiv gepinnt werden soll; die Anfrage durchläuft die Zustände queued, pinning und pinned bzw. failed, wenn sie nicht abgeschlossen wird. Der Abnahmetest hat zwei Teile: die exakte CID, die der Contract speichert, über einen anderen Weg als den eigenen Node abrufen und, wenn das Projekt CIDs in seiner Continuous Integration neu berechnet, das Importprofil schriftlich festlegen, damit das Ergebnis reproduzierbar ist.

Arweave: eine für 200 Jahre berechnete Vorauszahlung

Arweave geht von einem anderen Wirtschaftsmodell aus. Laut seinemLightpaperleistet, wer Daten hochlädt, einen einmaligen Beitrag zu einem Speicherfonds (Storage Endowment), und das Protokoll berechnet dessen Höhe als Barwert der Kosten für die Vorhaltung von 20 Replikaten über 200 Jahre. Die Miner werden aus diesem Fonds in dem Maße bezahlt, wie sie nachweisen, dass sie die Daten speichern. Das Dokument begründet die Permanenz mit einer expliziten Annahme: Es genügt, dass die Kosten für die Speicherung von Daten über einen festen Zeitraum um 0,5 % pro Jahr sinken, damit sich der Fonds unbegrenzt trägt – gegenüber einem durchschnittlichen Rückgang, den das Dokument selbst für die letzten 50 Jahre mit rund 38,5 % pro Jahr angibt. Es räumt zudem ein, dass die Stabilität des Fonds vom Preis des AR-Tokens abhängt.

Aus demselben Dokument ergeben sich zwei praktische Konsequenzen. Der Upload kann über Bundler erfolgen, also Dienste, die Daten mehrerer Nutzer in einer Transaktion bündeln, in AR abrechnen und von Nutzern Zahlungen über andere Zahlungsmittel annehmen können. Und das Netzwerk wendet ein freiwilliges System von Inhaltsrichtlinien an: Jeder Miner entscheidet, welche Daten er speichert und ausliefert, und jedes Gateway, was es indexiert und anzeigt, entsprechend dem jeweils geltenden Recht, sodass für im Netzwerk gespeicherte Daten nicht garantiert ist, dass alle Gateways sie ausliefern. Die Node-Software wird weiter veröffentlicht: Die neueste Version, die2.9.7, stammt vom 21. Oktober 2026.

Korrekturen, Versionen und personenbezogene Daten

Keines der beiden Netzwerke erlaubt es, eine Datei zu bearbeiten, denn ein anderer Inhalt hat eine andere Referenz. Bei IPFS erzeugt das Veröffentlichen einer korrigierten Version eine neue CID, und die vorherige ist nicht mehr verfügbar, sobald niemand sie pinnt; bei Arweave bleibt die vorherige Version gespeichert. Bei einem Dokument mit Rechtswirkung, etwa den Bedingungen einer Emission, muss die Versionierung deshalb im Contract oder in der Anwendung abgebildet werden: welche Referenz gilt, seit wann, welche jeder Anleger akzeptiert hat und wer berechtigt ist, eine neue für gültig zu erklären.

Die Permanenz von Arweave gilt auch für das, was nicht hätte veröffentlicht werden dürfen. Personenbezogene Daten, die ins Netzwerk hochgeladen wurden, kann der Hochladende nicht zurückziehen, und eine Verschlüsselung verlagert das Problem nur auf die Verwahrung des Schlüssels. Bei IPFS garantiert das Entfernen eines Pins nicht das Verschwinden der Datei, wenn ein anderer Node sie aufbewahrt hat. Deshalb bleiben personenbezogene Daten und die Identifikationsunterlagen der Anleger außerhalb beider Netzwerke; veröffentlicht wird die Referenz oder der Hash eines Dokuments, das das Unternehmen mit seinen eigenen Aufbewahrungs- und Löschpflichten verwahrt.

IPFS vs. Arweave: Arweave für das, was das Team überdauern muss, IPFS, wenn jemand den Pin übernimmt

Arweave beantwortet die Frage, wer die Speicherung bezahlt, wenn das Projekt nicht mehr existiert: Die Zahlung erfolgte beim Upload und hängt nicht von einem Abonnement ab. Es passt zu Metadaten und Dokumenten, die sich nicht ändern dürfen und deren Verfügbarkeit das Team überdauern muss, das sie veröffentlicht hat, etwa bei einer geschlossenen Kollektion. Seine Garantie ist ein Wirtschaftsmodell mit expliziten Annahmen, kein Dienstleistungsvertrag, und seine Permanenz ist ein Nachteil für alle Daten, die möglicherweise entfernt werden müssen.

IPFS löst die überprüfbare Identifikation und die Verteilung von Inhalten und passt, wenn eine Organisation ausdrücklich die Verantwortung übernimmt, den Pin aufrechtzuerhalten: auf eigenen Nodes oder bei einem oder mehreren Anbietern, mit einem CID-basierten Migrationsverfahren. Sein Risiko liegt nicht im Protokoll, sondern im Betrieb: Ein Pin, den niemand bezahlt, oder eine mit anderen Parametern neu berechnete CID machen die Referenz ungültig, ohne dass der Contract es bemerkt.

Metlabs entwickelt Kollektionen vonNFTundTokenisierungsplattformen, bei denen festgelegt wird, was on-chain veröffentlicht, was in dezentralen Netzwerken gespeichert und was vom Emittenten verwahrt wird. Wenn Sie diese Aufteilung gerade entwerfen,erzählen Sie uns davonwelche Dokumente und Metadaten das Projekt verwaltet und wer in zehn Jahren dafür einstehen muss.