Précédemment, concernant la discussion sur Blob, nous nous sommes principalement concentrés sur ce qu'il peut stocker et comment le faire. Mais pour comprendre réellement pourquoi Walrus peut devenir une infrastructure de couche de données durable, la clé ne réside pas dans le stockage lui-même, mais dans le mécanisme de gestion du cycle de vie complet de Blob. Cela implique des contraintes temporelles, une conception des coûts, ainsi que le modèle économique sous-jacent — c'est cela qui détermine si le système peut fonctionner de manière stable à long terme.

En y regardant sous un autre angle, les données dans tout système réel ne sont pas statiques. Elles sont créées, fréquemment consultées, modifiées, remplacées, et finissent par devenir obsolètes ou être nettoyées. Si le système ne résout que le problème de "comment écrire efficacement des données" tout en ignorant l'évolution des données dans la dimension temporelle, la complexité et le coût vont s'accumuler comme une boule de neige, devenant ingérables.

L'approche de Walrus est tout à fait différente. Il ne considère pas Blob comme quelque chose qui, une fois écrit, est conservé indéfiniment, mais le définit clairement comme un objet à long terme qui consomme des ressources réseau. Cela signifie que la présence de Blob consomme en permanence de l'espace de stockage, de la bande passante et la capacité de maintenance des nœuds. Étant donné qu'il y a une consommation, il faut des limites temporelles claires et des contraintes de coûts pour accompagner cela, et ne pas utiliser des méthodes de facturation floues comme certains services cloud centralisés pour masquer les coûts réels. C'est cela qui permet à toute l'infrastructure de couche de données d'être véritablement cohérente et durable.