Faire du développement on-chain n'a pas pour principal problème la performance, mais plutôt le blocage au niveau de l'architecture des données.

De nombreux projets avancent très vite au début, mais après six mois, ils commencent à stagner. Il ne s'agit pas forcément d'un manque d'argent, mais plutôt d'une structure de données qui est devenue rigide — dès que la logique métier est déployée, chaque itération nécessite de creuser jusqu'à trois mètres sous terre. Modifier un seul champ peut impliquer de toucher toute la couche applicative, ce qui est une véritable réalité pour de nombreux projets on-chain, passant d'une croissance fulgurante à une stagnation.

La démarche de Walrus est très intéressante. Elle admet une réalité fondamentale : il est impossible de concevoir parfaitement dès le départ. Plutôt que de s'accrocher à ses idées initiales, il vaut mieux maintenir la structure de données vivante.

D'un point de vue technique, son architecture repose sur un modèle de stockage au niveau des objets. Chaque objet de données possède une identité propre, et les mises à jour ne sont pas des patchs, mais une évolution naturelle. D'après les performances sur le réseau de test, le système supporte plusieurs mises à jour pour un même objet, un seul objet peut atteindre plusieurs Mo, et il peut être maintenu par plusieurs nœuds simultanément, garantissant ainsi la disponibilité.

Cela laisse une marge de manœuvre pour les développeurs — vous n'avez pas besoin de prévoir ce qui se passera dans trois ans dès le premier jour. Les besoins changent, et les données peuvent évoluer en conséquence. Bien sûr, quel en est le coût ? Cette flexibilité peut être abusée, il faut que la couche applicative maintienne ses propres contraintes.

Mais pour être honnête, pour un logiciel du monde réel, pouvoir corriger ces choses en soi est déjà précieux. Par rapport à une architecture qui bloque tout dès le départ, avoir la possibilité de corriger ses erreurs est déjà une grande avancée.