Entwickelt für große Daten: Die Infrastrukturkompromisse von Walrus für große Blobs
Letzte Woche hatte ich Probleme beim Hochladen eines ~50GB-Datensatzes in eine dezentrale Speicherschicht. Es hat schließlich geklappt, aber es dauerte Stunden, mit Wiederholungen, die durch Knoten verursacht wurden, die ein- und ausschalteten. Nichts brach, aber es machte die Grenzen leichterer Speicherdesigns sehr offensichtlich.
Das Walrus-Protokoll fühlt sich näher an der Frachtlogistik als an der Verbraucherzustellung an. Es ist gebaut wie ein Massengutfrachter – dazu gedacht, große Lasten zuverlässig zu bewegen, nicht für kleine, latenzempfindliche Pakete zu optimieren.
Große Blobs werden in fehlercodierte Chunks aufgeteilt und über viele Knoten verteilt, so dass Daten abrufbar bleiben, selbst wenn Teile des Netzwerks offline gehen. Der Kompromiss ist klar: Haltbarkeit und Verfügbarkeit haben Vorrang, nicht sofortige Lesungen für kleine Dateien.
Um dieses Gleichgewicht zu halten, begrenzt das Protokoll individuelle Blob-Uploads auf 1GB, wodurch große Datensätze absichtlich in Chunks aufgeteilt werden müssen, anstatt das Netzwerk mit unbegrenzten Payloads zu überfluten. Diese Einschränkung hilft, Staus zu vermeiden, während die Nutzung skaliert.
$WAL wird verwendet, um für Speicher-Epochen zu bezahlen, in Aggregatoren oder Speicherrollen zu staken und an Governance-Entscheidungen zu Parametern und Upgrades teilzunehmen.
Die kürzliche Migration von Team Liquid mit 250TB, dem größten Datensatz bisher, drängte die insgesamt gespeicherten Daten über frühere Grenzen hinaus und zeigte, dass das System unter realer Last standhält. Ich bin immer noch vorsichtig, wie es sich während der Spitzenanforderungen für KI-Training verhält, aber als Infrastruktur ist die Absicht klar – Haltbarkeit über Geschwindigkeit zu bevorzugen und es den Entwicklern zu ermöglichen, Latenz gegen Skalierung abzuwägen, wenn es darauf ankommt.
