Inżynieryjna realizacja przechowywania Blob przez Walrusa: kodowanie korekcyjne, współczynnik replikacji i kompromisy w dostępności danych
Jeśli pozostaniemy tylko na poziomie „Blob to nowa abstrakcja danych”, wartość Walrusa nadal będzie niekompletna. Prawdziwe znaczenie, czy Blob może stać się jednostką danych na poziomie infrastruktury, zależy od sposobu jego inżynieryjnej realizacji w rzeczywistych warunkach sieciowych. Każdy protokół warstwy danych, gdy tylko wyjdzie poza dyskusję na temat wykonalności inżynieryjnej, może pozostać jedynie na etapie koncepcji. Projekt Walrusa w zakresie przechowywania Blob nie dąży do jakiegoś teoretycznego najlepszego rozwiązania, lecz dokonuje szeregu określonych wyborów między kosztami, dostępnością, odpornością na błędy a stabilnością długoterminową.
Najpierw trzeba jasno określić, że Walrus, projektując przechowywanie Blob, nie poszedł za tradycyjnym myśleniem „wysoki współczynnik replikacji oznacza bezpieczeństwo”. W wielu wczesnych zdecentralizowanych sieciach przechowywania bezpieczeństwo danych opierało się głównie na prostych, brutalnych strategiach kopiowania: jedna kopia danych była kopiowana na możliwie wiele węzłów, aby uzyskać psychologiczne poczucie bezpieczeństwa „dopóki jest choć jeden węzeł, dane się nie zgubią”. Tego rodzaju podejście jest akceptowalne w małych, rzadko używanych scenariuszach, ale gdy staje się to przedmiotem zbiorów danych AI, zasobów gier na łańcuchu lub dużych treści medialnych, jego koszty szybko mogą wymknąć się spod kontroli.