@Walrus 🦭/acc #walrus $WAL
Un soir, j'ai essayé de revoir l'architecture de pas mal de dApp Sui et j'ai remarqué un point très similaire : la logique on-chain est correcte, mais les données vitales se trouvent dans des endroits très fragiles.
Métadonnées, historique des états, fichiers utilisateurs, sortie IA, logs d'application… tout cela est conservé dans le backend ou le stockage centralisé.
Lorsque tout fonctionne bien, personne ne fait attention. Mais quand le backend est en panne, que l'équipe part, ou que le financement s'épuise, la question "les données de cette dApp existent-elles encore ?" devient extrêmement effrayante.
C'est à ce moment-là que je vois que construire un système de sauvegarde de données pour Sui dApp avec Walrus n'est plus optimal, mais une condition pour que la dApp survive longtemps.
Tout d'abord, il faut préciser : la sauvegarde dans Web3 n'est pas comme la sauvegarde dans Web2.
La sauvegarde Web2 est pour restaurer le serveur. La sauvegarde Web3 est pour préserver la vérité.
Avec Sui, l'état on-chain est très bien protégé. Mais la dApp Sui n'a pas seulement un état on-chain.
Beaucoup de choses déterminant l'expérience et la légitimité de l'application sont hors chaîne. Si ces éléments sont perdus, la chaîne continue de fonctionner, mais la dApp est en quelque sorte morte.
Walrus est adapté à ce problème car il ne s'agit pas d'un stockage pour exécuter l'application, mais d'un stockage pour se souvenir de l'application.
Un système de sauvegarde de données pour les Sui dApp utilisant Walrus devrait commencer par la classification des données.
Toutes les données ne nécessitent pas une sauvegarde sur Walrus. Il y a trois groupes clairement définis.
Le premier groupe est constitué de données liées à la légitimité de la dApp.
Par exemple : métadonnées NFT, instantané de l'état du jeu, historique des décisions du DAO, contexte de la proposition, mémoire de l'agent IA, résultats de calcul influençant la logique on-chain.
Ce sont des données que si perdues, les utilisateurs n'ont plus de moyen de vérifier le passé. Ce groupe devrait être sauvegardé sur Walrus presque obligatoirement.
Le deuxième groupe est constitué de données historiques ayant une valeur de référence.
Par exemple : logs de comportement, données brutes d'analytics, données d'entraînement, historique des événements.
Il n'est pas toujours nécessaire d'accéder, mais quand c'est nécessaire, c'est très important. Ce groupe est très adapté à Walrus en raison de sa nature de stockage à long terme, append-only.
Le troisième groupe est constitué de données opérationnelles à court terme telles que cache, session, état temporaire.
Ce groupe ne devrait pas être mis sur Walrus. Il devrait être dans le backend Web2 pour maintenir une expérience utilisateur fluide et des coûts bas.
Une architecture de sauvegarde raisonnable est : le backend continue de fonctionner normalement, mais chaque fois qu'un événement "digne d'être mémorisé" se produit, le backend enregistrera un instantané ou un artefact sur Walrus, puis conservera cette référence (hash, ID d'objet) sur Sui on-chain ou indexeur.
Ainsi, la chaîne sait que "dans ce bloc, ces données existaient", tandis que le contenu réel se trouve sur Walrus.
Par exemple avec Sui NFT dApp : les métadonnées ne devraient pas seulement être sur le serveur ou IPFS pin temporaire.
Lorsqu'un mint ou une mise à jour valide se produit, les métadonnées d'origine doivent être enregistrées sur Walrus.
L'objet Sui n'a besoin que de garder la référence. Si le serveur disparaît, n'importe qui peut récupérer les métadonnées d'origine de Walrus et reconstruire le frontend.
Avec un jeu ou une dApp sociale sur Sui, chaque saison, chaque époque, ou chaque état important peut créer un instantané d'état et le pousser vers Walrus.
Cet instantané n'a pas besoin d'être utilisé pour le gameplay en temps réel, mais est extrêmement important pour l'audit, la répétition, ou la migration vers une nouvelle version.
Un grand avantage de Walrus dans la sauvegarde pour Sui est son indépendance par rapport à l'équipe.
Si l'équipe cesse d'opérer le backend, les données restent.
Une autre équipe, ou une communauté, peut tout à fait reconstruire l'indexeur, un nouveau backend, lire les données depuis Walrus, et continuer la dApp.
C'est quelque chose que le backend de style Web2 ne pourra jamais garantir.
Un autre point est que la sauvegarde n'a pas besoin d'être synchronisée instantanément.
Walrus ne nécessite pas de faible latence. La sauvegarde peut se faire par lots, selon un calendrier, ou selon une logique de déclenchement.
Cela aide à ce que les coûts et l'expérience utilisateur ne soient pas affectés.
La perte de données est la perte de l'histoire, de la réputation, de la capacité de récupération.
Avec l'IA dApp sur Sui, Walrus est presque la pièce parfaite pour la sauvegarde.
Historique des prompts, sortie d'inférence, mémoire de l'agent… si cela ne réside que sur le serveur, alors l'IA on-chain n'est qu'une forme.
Sauvegarder ces artefacts sur Walrus aide l'agent IA à avoir une mémoire immuable, pouvant être auditée et réapprise.
C'est très important si l'agent IA participe à l'économie réelle sur Sui.
Une bonne architecture de sauvegarde doit également prendre en compte la capacité de récupération, pas seulement le stockage.
Cela signifie que les données sur Walrus doivent avoir un format clair, des métadonnées complètes, et une version.
La sauvegarde n'est pas seulement pour "avoir", mais pour pouvoir réutiliser.
Les constructeurs devraient considérer Walrus comme une couche d'archive, pas une couche de vidage.
Il convient également de noter : la sauvegarde avec Walrus ne remplace pas l'indexeur.
L'indexeur est toujours nécessaire pour des requêtes rapides. Walrus ne sert pas des requêtes complexes. Il sert l'existence.
Lorsque l'indexeur tombe en panne, Walrus est l'endroit où vous revenez pour reconstruire l'indexeur depuis le début.
Un avantage indirect mais très important est la confiance des utilisateurs.
Lorsque les utilisateurs savent que leurs données importantes ne dépendent pas du serveur de l'équipe, la dApp devient beaucoup plus fiable.
Cela est particulièrement important pour les dApp financières, les actifs de jeu de grande taille, et le graphe social.
Bien sûr, il y a un coût. Le stockage à long terme n'est pas gratuit. Les constructeurs doivent sélectionner les données.
Mais le coût de la perte de données dans Web3 est toujours plus élevé que le coût de stockage.
Perdre des données, c'est perdre l'histoire, perdre la réputation, perdre la capacité de récupération.
Si je devais résumer le système de sauvegarde de données pour Sui dApp utilisant Walrus en une phrase, ce serait :
👉 Le traitement actuel de Sui, Walrus protège le passé.
La chaîne garantit que l'état ne peut pas être fraudé. Walrus garantit que l'état ne peut pas être oublié.
Dans Web3, de nombreuses dApp meurent non pas à cause d'une logique erronée, mais parce que leur mémoire disparaît.
Walrus permet aux constructeurs Sui de créer des dApp en supposant que l'équipe peut partir, que le backend peut tomber, mais que les données importantes demeurent.
Et quand une dApp est conçue pour survivre à cela, ce n'est plus une démo.
Cela commence à devenir une infrastructure.
