Walrus wydaje się być stworzony przez ludzi, którzy zauważyli coś, co większość rozmów o blockchainach cicho ignoruje: dane nigdy nie przestają się gromadzić, a udawanie, że tego nie ma, nie sprawia, że problem znika. Bloki są tworzone, aplikacje zapisują stan, użytkownicy oczekują trwałej pamięci — a z czasem koszt pamiętania staje się ważniejszy niż szybkość produkcji. Walrus nie traktuje tego jako problemu optymalizacji. Traktuje to jako ograniczenie projektowe.
To, co sprawia, że protokół jest interesujący, to nie jego surowa pojemność magazynowania, ale to, jak poważnie traktuje odpowiedzialność. Dane w Walrusie nie są po prostu umieszczane gdzieś i zapomniane; są zabezpieczone w sposób, który można udowodnić, odwołać się do nich i polegać na nich nawet po upływie oryginalnego kontekstu. Ta różnica ma większą wartość, niż się wydaje. Wiele systemów działa dobrze, gdy historia jest powierzchowna. Zaczynają się tracić, gdy historia staje się zależnością. Walrus wydaje się zaprojektowany na moment, gdy aplikacje muszą się odwoływać do przeszłości, nie zapadając pod ciężarem własnej masy.
Widoczna jest również zmiana sposobu, w jaki Walrus definiuje skalowalność. Nie obsessuje nad maksymalną przepustowością ani krótkoterminowymi benchmarkami. Zamiast tego zadaje ciche pytania: co się stanie, gdy aplikacje będą zależały od lat stanu? Jak zapewnić ekonomiczną trwałość długoterminowych danych? Jak zapobiec temu, by przechowywanie stało się niewidzialnym podatkiem, który pojawia się dopiero wtedy, gdy już za późno jest przebudować system? To nie są pytania protokołu szukające uwagi. To pytania protokołu planującego być obecne.
Nacisk na weryfikowalność wzmocnia ten długoterminowy podejście. Walrus zakłada, że zaufanie w końcu nie będzie wystarczające — że systemy będą potrzebowały pewności kryptograficznej co do tego, co istnieje, gdzie istnieje i czy jest nienaruszone. Przechowywanie staje się mniej jak magazyn i bardziej jak księga pamięci, gdzie integralność ma taką samą wagę jak dostępność.
