@Walrus 🦭/acc Jeśli wpiszesz „Pudełko przechowywania Walrus” do swojego mózgu z pamięcią mięśniową w kształcie S3, instynktownie szukasz momentu, w którym klikniesz „Utwórz pudełko”, wybierzesz strefę i przejdziesz dalej. Walrus nie ma takiego momentu, ponieważ nie jest organizowany wokół pudełek na poziomie protokołu. Jest rozproszonym magazynem obiektów blob, który wykorzystuje Sui jako płaszczyznę sterowania dla metadanych, płatności oraz potwierdzeń dostępności, podczas gdy same dane plików znajdują się na węzłach przechowywania.
Kluczowym obiektem w Walrus jest blob: niezmieniona część danych, którą publikujesz w sieci. Gdy przechowujesz plik, Walrus zwraca dwa identyfikatory, które mają znaczenie w różnych kontekstach. Identyfikator blob jest wyprowadzony z treści, więc ponowne przesłanie tych samych bajtów prowadzi do tego samego identyfikatora blob. Identyfikator obiektu Sui to obiekt na łańcuchu, który reprezentuje przechowywany blob, i to on używasz do zarządzania takimi rzeczami, jak długo dane mają zostać zachowane. Po internalizacji tego podziału wiele nieporozumień znika. Przestajesz pytać „Gdzie jest moje pudełko?” i zaczynasz pytać „Jak moja aplikacja będzie nazywała, grupowała i odnawiała bloby z upływem czasu?”
Jeśli tym, czego naprawdę chcesz, jest doświadczenie związane z koszykiem, tworzysz je o jeden poziom wyżej. To tam wchodzi brama zgodna z S3: udostępnia znane interfejsy API S3, przechowuje metadane koszyka i klucza w czymś konwencjonalnym, a następnie przesyła bajty obiektu do Walrus jako bloby w tle. WalruS3 jest prostym przykładem tego wzoru, opisując siebie jako usługę zgodną z S3, która używa Walrus jako zaplecza do przechowywania i PostgreSQL do zarządzania metadanymi. W tym układzie „tworzenie koszyka” to po prostu tworzenie przestrzeni nazw w magazynie metadanych bramy. Walrus sam w sobie nie przejmuje się nazwą koszyka; brama tak.
Gdy kierunek jest jasny, działania stają się niemal pamięcią mięśniową. W przypadku trasy bramy, zastępujesz punkt końcowy AWS punktem końcowym bramy, a następnie tworzysz koszyk, korzystając z standardowych przepływów S3. Z perspektywy protokołu, po prostu zapisujesz bloby, ale brama utrzymuje schludną iluzję koszyków, prefiksów i spisów. To podejście jest praktyczne, jeśli już masz skrypty, narzędzia do tworzenia kopii zapasowych lub zadania ETL, które zakładają semantykę S3. Zmusza cię to również do myślenia o trwałości metadanych, ponieważ twój „koszyk” jest tylko tak realny, jak baza danych, która go pamięta.
Jeśli chcesz być natywny, najbliższym odpowiednikiem koszyka jest konwencja, którą egzekwujesz konsekwentnie. Wiele zespołów ustala przewidywalny schemat kluczy (nazwa projektu, środowisko, data, może typ treści), a następnie przechowuje tę mapę w swojej własnej bazie danych lub obiekcie na łańcuchu, podczas gdy Walrus przechowuje rzeczywiste bajty. Oficjalna dokumentacja Walrus opiera się na tym pomyśle, koncentrując przepływ pracy na przechowywaniu i pobieraniu blobów za pomocą CLI, a nie zarządzaniu folderami lub pojemnikami.
W natywnej wersji Walrus prawdziwa decyzja zapada, gdy przechowujesz swój pierwszy blob i wybierasz jego czas życia. Walrus mierzy ten czas życia w epokach, a ty możesz go wydłużyć później, zanim się wyczerpie. Problem polega na tym, że „epoka” nie jest taka sama wszędzie: Testnet to jeden dzień, Mainnet to dwa tygodnie. To oznacza, że „przechowuj przez 10 epok” może wydawać się radykalnie różne w zależności od sieci, dlatego planowanie czasu życia nie jest opcjonalne.
CLI czyni to oczywistym. Możesz sprawdzić parametry sieciowe za pomocą walrus info, sprawdzić, czy dany blob jest aktualnie dostępny za pomocą walrus blob-status i wydłużyć czas życia bloba używając identyfikatora obiektu Sui bloba. Możesz również zdecydować, czy bloby są usuwalne, co ma znaczenie, jeśli twój „koszyk” jest naprawdę zestawem roboczym, który spodziewasz się przycinać. Dokumentacja interfejsu API HTTP zauważa, że nowo przechowywane bloby są usuwalne domyślnie, chyba że zaznaczysz inaczej. Ta domyślna opcja zaskakuje ludzi, ponieważ jest przeciwieństwem wibracji „napisz raz, trzymaj na zawsze”, które wielu zakłada, że zdecentralizowane przechowywanie musi mieć.
Dlaczego to wszystko nagle pojawia się w większej liczbie rozmów? Ponieważ wersja przechowywania z „ery AI” nie dotyczy tylko przechowywania plików – chodzi o to, aby dane były programowalne i weryfikowalne. Walrus kładzie nacisk na dowody dostępności na łańcuchu i cykl życia dla blobów, które mogą być rozumiane przez aplikacje, co jest częścią tego, dlaczego jest przedstawiane jako infrastruktura dla rynków danych i przepływów pracy agentów. Jeśli potraktujesz „tworzenie koszyka” jako decyzję projektową – koszyk bramy w porównaniu do nazewnictwa natywnego protokołu – skończysz z czymś, co zachowuje się w przewidywalny sposób, co jest jedną rzeczą, którą przechowywanie zawsze powinno robić.
