De nombreux projets ne montrent pas de réactions évidentes dans les premiers mois ; les véritables problèmes ont souvent tendance à se révéler entre 6 et 12 mois plus tard.

La raison est en fait très simple. Les données comportementales des utilisateurs, les enregistrements d’état, les journaux, ces éléments ne semblent augmenter que de quelques dizaines de Ko par jour, mais sur une année, cela représente une quantité de 10 à 30 Go. Le stockage décentralisé traditionnel commence à montrer ses limites à ce stade — chaque mise à jour doit être réécrite, les versions historiques s’accumulent sans cesse, et les relations de référence deviennent de plus en plus confuses.

Et si on changeait de perspective ? Considérer la "cumulativité à long terme" comme une condition préalable dès le départ. L’identité et les références des objets restent fixes, mais leur état peut continuer à évoluer, plutôt que de créer un nouveau lot d’objets chaque année. Quels sont les avantages d’une telle conception ?

D’après les données publiques, la performance de protocoles comme Walrus dans ce domaine : un seul objet peut supporter une taille de données de plusieurs Mo, le même objet peut être mis à jour plusieurs fois sans modifier ses références, et les données sont stockées en redondance entre plusieurs nœuds, avec une disponibilité stable supérieure à 99 %.

Faisons une évaluation réaliste : lorsque la taille des données entre dans une phase de "croissance pilotée par le temps", la valeur de cette architecture pourrait être plus cruciale que la simple recherche de coûts faibles. Mais cela suppose que le nombre de nœuds du réseau puisse s’étendre en conséquence, sinon l’accumulation de données historiques pourrait devenir une source de pression pour le système.