@Walrus 🦭/acc Seit Jahren ist „es auf die Kette setzen“ ein nervöser Witz in Web3-Kreisen. Jeder kennt die Pointe: Man kann nicht, zumindest nicht für die meisten Daten, die eine Anwendung echt erscheinen lassen. In dem Moment, in dem Ihr Projekt Bilder, Audio, Video, Modell-Dateien oder sogar eine umfangreiche Menge an Protokollen benötigt, wird eine Basis-Chain der falsche Ort, um diese Bytes zu parken. Die Gebühren steigen, die Blöcke quellen über, und man behandelt die Blockchain wie eine Festplatte, für die sie nie gedacht war. Diese Diskrepanz ist der Grund, warum „Blobs“ immer wieder in ernsthaften Gesprächen auftauchen, nicht als Meme, sondern als praktische Grenzlinie zwischen dem, was Chains gut machen und was sie nicht gezwungen werden sollten zu tun.
Ein Blob ist einfach ein binäres großes Objekt: ein Chunk von Bytes, der als Einheit gespeichert und bewegt wird. In Web3 heute zeigt sich diese einfache Idee auf zwei sehr unterschiedliche Arten. Ethereums EIP-4844 führte Blob-tragende Transaktionen ein, damit Rollups Daten günstiger veröffentlichen können als permanente calldata, aber mit einem bewussten Kompromiss: Blob-Daten sind temporär. Das Spezifikations- und Erklärungssystem ist sich in dem Kernpunkt einig – Blobs werden nach etwa 4.096 Epochen, zusammengefasst etwa 18 Tage, gekürzt – weil das Netzwerk es sich nicht leisten kann, dass jeder Skalierungsschritt zu permanentem historischen Ballast wird.
Dieses Design leistet echte Arbeit. Nachdem EIP-4844 live ging (März 2024), wurden Blobs schnell zur normalen Spur für die Veröffentlichung von Rollup-Daten, und Sie können den Wandel daran erkennen, wie die Menschen über die Kosten der Datenverfügbarkeit und den Durchsatz als operationale Realität sprechen, nicht als Forschungskonzept. Ich habe auch den Ton in Gesprächen mit Erbauern bemerkt. Die Frage ist nicht mehr „können wir skalieren?“, sondern „um welche Art von Daten sprechen wir, und wie lange brauchen wir sie tatsächlich, um zu bleiben?“
Denn in dem Moment, in dem Sie „18 Tage“ sagen, taucht eine andere Kategorie von Bedürfnissen auf. Viele Anwendungen wollen Daten, die bestehen bleiben: NFT-Medien, die nicht verschwinden sollten, Spiel-Assets, die nächsten Monat geladen werden müssen, Datensätze, auf die ein KI-Workflow möglicherweise wiederholt verweist, oder eine Audit-Trail, die Sie lange nach dem Abklingen der Launch-Aufregung erneut überprüfen möchten. Das alte Muster – irgendwo zentralisiert hochladen, einen Hash on-chain pinnen, hoffen, dass der Link funktioniert – kann gut sein, bis es nicht mehr funktioniert. Die Chain kann bezeugen, dass eine Datei einmal existiert hat, aber sie kann niemanden zwingen, sie weiterhin bereitzustellen, und sie kann das Speichern nicht wie einen erstklassigen Teil Ihrer App-Logik erscheinen lassen.
Hier verdient Walrus den Titel „Blob-Speicher“ auf eine Weise, die wörtlicher ist, als es klingt. Walrus wurde von Mysten Labs als Protokoll für dezentralen Speicher und Datenverfügbarkeit eingeführt, das speziell entwickelt wurde, um unstrukturierte Datenblobs zu behandeln, indem sie in kleinere Stücke („Slivers“) codiert und auf Speichernodes verteilt werden. Das Schlüsselversprechen ist pragmatische Resilienz: Der ursprüngliche Blob kann aus einer Teilmenge dieser Slivers rekonstruiert werden, selbst wenn ein großer Teil fehlt.
Das ist nicht nur ein nettes Detail. Es ist der gesamte Punkt, Blobs als einen nativen Objekttyp zu behandeln, anstatt als eine unbeholfene Anfügung an einen Smart Contract. Walrus stützt sich auf Erasure-Coding, sodass es nicht überall naive vollständige Replikation benötigt, und das technische Papier rahmt dies als Antwort auf die Kosten- und Wiederherstellungseffizienzen, die auftreten, wenn Nodes churnen oder partielle Ausfälle die Norm sind, nicht die Ausnahme. Wenn Sie jemals versucht haben, eine dezentrale App für Benutzer „normal“ erscheinen zu lassen – schnell, vorhersehbar und nicht mysterisch kaputt – dann ist dies die Art von Ingenieurswahl, die wichtiger ist als Branding.
Was Walrus jedoch besonders relevant für Web3 macht, ist, wie es Speicherplatz mit dem On-Chain-Zustand verbindet, ohne vorzugeben, dass der Speicher der Chain ist. In der Walrus-Dokumentation wird der Speicherplatz als Ressource auf Sui dargestellt, und gespeicherte Blobs werden ebenfalls als Objekte auf Sui dargestellt. Das bedeutet, dass Smart Contracts überprüfen können, ob ein Blob verfügbar ist und wie lange, seine Lebensdauer verlängern oder optional löschen, während die schweren Bytes im Speichernetzwerk leben. Der Walrus-Blog beschreibt Sui als eine Steuerungsebene für Metadaten und für die Veröffentlichung eines On-Chain-Nachweises über die Verfügbarkeit, der bestätigt, dass der Blob tatsächlich gespeichert ist.
Diese Lebenszyklusdetails sind der Punkt, an dem Walrus aufhört, eine abstrakte Idee von „dezentralem Speicher“ zu sein und sich in etwas verwandelt, um das eine Anwendung herum entwerfen kann. Blobs werden für eine ausgewählte Anzahl von Epochen gespeichert, die beim Schreiben festgelegt werden, und die Dokumentation weist ausdrücklich darauf hin, dass das Mainnet eine Epochen-Dauer von zwei Wochen verwendet. Mit anderen Worten, Speicherung ist kein vages Versprechen; es ist ein Mietvertrag mit expliziten zeitlichen Grenzen, über die Ihr Code nachdenken kann. Und wenn Sie möchten, dass der Blob länger bleibt, unterstützen die Client-Tools die Verlängerung der Blob-Lebensdauer, solange der Blob nicht abgelaufen ist, mit klaren Eigentumsregeln, wer was verlängern kann.
Selbst die „langweiligen“ Einschränkungen sind erfrischend explizit. Die Dokumentation gibt eine aktuelle maximale Blob-Größe von 13,3 GB an, mit der einfachen Anweisung, größere Daten bei Bedarf zu chunkieren. Diese Art von Spezifität ist oft das, was ein Protokoll trennt, auf dem Sie tatsächlich aufbauen können, von einem Konzept, über das Sie nur in Panels sprechen.
Warum ist das jetzt im Trend, jenseits des üblichen Zyklus neuer Protokollstarts? Weil die Branche gezwungen ist, ihr mentales Modell von Daten zu reifen. Ethereum-Blobs haben es sozial akzeptabel gemacht, laut zu sagen, dass einige Daten nur vorübergehend für Verifizierungsfenster verfügbar sein müssen – und dass die Optimierung für dieses Fenster ein Merkmal, kein Kompromiss ist. Gleichzeitig werden die Anwendungen, die die Leute zu nutzen versuchen, schwerer: Wallets, die Galerien darstellen, Spiele, die Assets streamen, und KI-nahe Workflows, die Modellartefakte und Herkunftsaufzeichnungen wie normal bewegen.
Walrus passt in diesen Moment, indem es sich auf die andere Seite der Blob-Geschichte konzentriert: nicht den temporären „post it for settlement“-Blob, sondern den langlebigen „speichere es, beweis, dass es da ist, und lasse meine App seine Lebensdauer verwalten“-Blob. Ich sage nicht, dass es die schwierigen Fragen entfernt – Speichernetzwerke leben und sterben von Anreizen, Latenz und was passiert, wenn die Zuverlässigkeit im Laufe der Zeit driftet. Aber es tut etwas Wichtiges: Es behandelt Blob-Speicher als Teil der Kernarchitektur, anstatt eine Nebenquest zu sein, die jedes Team neu erfinden muss. Deshalb fühlt sich Walrus stark relevant für den Titel an – und warum sich „Blobs“ endlich so anfühlen, als würden sie zur Hauptgeschichte gehören, nicht zu den Fußnoten.