Lors de l'étude des protocoles de stockage distribué, un phénomène souvent négligé mérite notre attention : la capacité d'écriture est souvent exagérée, tandis que l'importance des performances de lecture est facilement sous-estimée.

Une écriture réussie ne fait que prouver que la capacité d'accueil du système n'est pas un problème, ce qui détermine réellement si une application peut survivre, c'est la vitesse à laquelle les données peuvent être lues. Imaginez un site web qui se charge lentement au point de faire défiler des diapositives, une intelligence artificielle qui doit attendre pour accéder aux données, ou des images dans une application qui restent indéfiniment en chargement — ces défauts d'expérience utilisateur, apparemment "mineurs", peuvent suffire à détruire la technologie de base la plus avancée.

La raison pour laquelle le protocole Walrus mérite une discussion à part est qu'il complexifie le processus de lecture. Lors de l'écriture, les données sont encodées en plusieurs fragments(slivers) et dispersées sur différents nœuds de stockage, seules les métadonnées et les références vérifiables sont enregistrées sur la chaîne ; lors de la lecture, il faut collecter suffisamment de fragments depuis différents nœuds, puis reconstruire les données originales.

Le rôle central dans ce processus est celui de l'agrégateur(. Il ressemble à un coordinateur d'atelier de puzzles — il n'a pas besoin de conserver tous les morceaux en permanence, mais lorsque l'utilisateur souhaite voir l'image complète, il est responsable de collecter les pièces nécessaires de partout et de les assembler. Une fois la reconstruction terminée, le contenu peut encore être accéléré par un CDN ou un cache, permettant une véritable accessibilité rapide.

Cette conception montre que le goulet d'étranglement du stockage distribué ne se trouve pas dans l'écriture, mais dans la lecture. Peu importe la sophistication du système, si la dernière étape de l'expérience utilisateur ne suit pas, tout est vain.