Lorsque l'on parle de données on-chain, le premier mot qui vient à l'esprit de beaucoup est « immuable ». Cela semble logique, mais après avoir géré une période, on se heurtera à une réalité embarrassante — parfois, il faut revenir en arrière.

Ce n'est pas pour modifier les données, mais pour clarifier ce qui s'est passé, suivre la racine du problème, ou effectuer un audit de risque. Ce sont des processus métier normaux.

Le problème est ici : si les données ne peuvent que progresser en avant, mais que le système ne parvient pas à comprendre le contexte, alors sa valeur pratique diminue constamment. Une application réelle doit comprendre comment un certain état a évolué étape par étape pour en arriver là, et ne pas se concentrer uniquement sur le résultat final.

La démarche de Walrus est plutôt intéressante, elle n'adopte pas une approche radicale. Elle ne nie pas la valeur de l'immutabilité, mais intègre la « progression d'état » dans le mécanisme de validation. Résultat : l'ID de l'objet reste inchangé, chaque mise à jour peut être tracée, les données ne seront pas simplement écrasées, et les versions historiques ne seront pas noyées.

D'après les informations publiques du réseau de test, cette solution supporte plusieurs mises à jour du même objet, l'adresse de référence reste stable, un seul objet peut atteindre plusieurs Mo, ce qui suffit pour répondre aux besoins de données métier réelles.

Alors, qu'en pense-je ? Dès que l'application commence à se concentrer réellement sur le parcours historique plutôt que sur une simple capture instantanée, les avantages de cette conception deviennent évidents. Mais il y a une condition préalable — le réseau doit être stable. Si le nombre de nœuds participants est insuffisant, une traçabilité multi-étapes peut devenir une surcharge.

Mais en bon sens, cette approche résout effectivement un problème réel.