2026-01-07 19:25:37

Beaucoup de gens découvrent Walrus pour la première fois, et leur première pensée est "Encore une solution de stockage décentralisée".

Mais si vous adoptez une autre perspective, celle d’un développeur ou d’un concepteur de protocoles, vous verrez quelque chose de plus profond : ce que ce protocole cherche à résoudre ne se limite pas au stockage, mais concerne la manière de faire en sorte que les données, tout en restant fiables, puissent évoluer de manière flexible avec le système.

Commençons par un phénomène contre-intuitif.

Il existe un paradoxe dans le monde de la blockchain : les données les plus sécurisées sont souvent les plus difficiles à utiliser. Pourquoi ? Parce qu’une fois que les données sont étiquetées comme "immutable" (immutable), toute modification, ajout ou correction doit être réécrite depuis le début. Cela ne pose pas de problème pour la comptabilité, mais devient un énorme obstacle pour les applications.

Dans la réalité, les données ne sont jamais immuables. Le contenu généré par les utilisateurs doit être éditable, les jeux de données pour l’entraînement des modèles d’IA doivent être continuellement optimisés, l’état des jeux doit être mis à jour en temps réel, et les résultats de calcul hors chaîne doivent être constamment vérifiés. Les bases de données centralisées résolvent élégamment ce problème grâce à un mécanisme de contrôle de version, mais dans un système décentralisé, cette problématique reste longtemps non résolue.

L’innovation de Walrus réside précisément ici. Elle ne nie pas l’immuabilité, mais redéfinit ce qui doit rester inchangé. La méthode consiste à séparer "l’identité de l’objet de données" et "l’état de l’objet de données" — le même objet peut conserver une identité stable tout en permettant à son état d’évoluer plusieurs fois, chaque itération pouvant être vérifiée indépendamment.

Ce changement a pour effet immédiat de modifier la façon dont les développeurs travaillent. Avant, chaque fois que les données changeaient, il fallait repenser le chemin de stockage et ajuster la logique d’accès. Maintenant, ce n’est plus nécessaire.

Voir l'original

Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.

13 J'aime

Récompense
13
8
Reposter
Partager

Commentaire

0/400

MaticHoleFiller

· 01-08 02:13

Oh, cette idée de conception est plutôt intéressante, la séparation de l'identité et de l'état résout effectivement pas mal de problèmes --- La gestion du contrôle de version, c'est vrai, la base de données centralisée est dépassée depuis longtemps, la décentralisation rencontre effectivement des blocages à long terme --- Attends, dans ce cas, comment garantir la cohérence des données ? On dirait qu'il y a toujours un risque --- En résumé, c'est pour que les données sur la chaîne puissent aussi être modifiées comme avec git, l'idée est bonne mais comment la réaliser --- L'amélioration de l'expérience développeur est réelle, mais cela ne va-t-il pas encore devenir une nouvelle excuse pour certains projets de faire du "割韭菜" (coup de massue aux investisseurs) ? --- L'idée de séparer l'identité et l'état, j'en ai vu des similaires, ce n'est pas vraiment nouveau --- Ça ressemble à une solution à un problème réel, mais il faut voir qui l'utilise réellement dans l'écosystème pour savoir si c'est fiable

Voir l'originalRépondre0

DefiSecurityGuard

· 01-07 19:53

ok donc ils présentent cela comme un schéma de conception genius mais... séparation identité vs état ? c'est littéralement juste une gestion de version avec des étapes supplémentaires. j'ai déjà vu ce vecteur d'exploitation—que se passe-t-il lorsqu'une personne prend le contrôle de la couche "identité" ? le rapport d'audit ne dit rien sur le contrôle d'accès ici. DYOR avant de toucher à cela, ce n'est pas un conseil financier.

Voir l'originalRépondre0

BrokenDAO

· 01-07 19:52

Hmm... l'état de stabilité de l'identité peut être itératif, cette logique est en effet plus claire que la plupart des solutions décentralisées. Mais le point clé reste la façon dont le mécanisme d'incitation est conçu — qui va maintenir cette version de la chaîne ? Honnêtement, à chaque fois, c'est toujours le même discours du protocole : "résoudre les frictions", mais en fin de compte, le vrai problème qui bloque tout, c'est l'équilibre de jeu. Ce genre de conception séparée, c'est joli en théorie, mais en pratique, les nœuds vont-ils faire preuve de paresse dans la validation ? Chaque jour, de nouvelles solutions, je veux juste voir comment le modèle économique de Walrus va vraiment empêcher ce genre de problème. Mais c'est vrai que ça touche directement le point sensible de la couche applicative Web3 — l'impossibilité de changer l'information, cette caractéristique est en soi un piège de centralisation déguisé. Ça a l'air intéressant, mais j'attends de voir si un projet l'utilise réellement avant de me faire une idée. Toutes ces campagnes de promotion excessives, au final, ce n'est qu'une fête de distorsion des incitations. Cette fois, la conception est plus mature que ce que j'avais prévu, mais si je devais parier, je dirais qu'elle va s'effondrer face à de vrais problèmes de gouvernance.

Voir l'originalRépondre0

NFTDreamer

· 01-07 19:49

Oh, cette perspective n'était effectivement pas évidente, l'idée de séparer l'identité et l'état est plutôt ingénieuse.

Voir l'originalRépondre0

mev_me_maybe

· 01-07 19:44

État de séparation d'identité, c'est ça l'idée, enfin quelqu'un qui a vraiment expliqué ce problème en profondeur --- Attendez, cela signifie que les applications sur la chaîne n'auront plus besoin de réécrire toute leur logique simplement pour modifier des données ? Comment ont-ils pu supporter ça avant --- Je pense que c'est la bonne façon de stocker, pas simplement accumuler une décentralisation --- Donc, Walrus résout essentiellement le problème de gestion de version des contrats intelligents, personne ne l'avait vraiment bien fait avant --- Cette idée d'une identité stable et d'un état itérable est vraiment géniale, les développeurs de jeux blockchain doivent dire que c'est du métier --- Honnêtement, après avoir compris la véritable nature de l'immuabilité et la différence avec les besoins réels, je trouve que beaucoup de solutions de stockage sont trop superficielles

Voir l'originalRépondre0

HypotheticalLiquidator

· 01-07 19:27

Ça sonne bien, mais le problème est : une fois que cette mécanique de séparation d'identité atteint une certaine échelle, le coût de validation ne va-t-il pas devenir incontrôlable ? --- L'itération des données est devenue plus flexible, mais qu'en est-il du facteur de santé ? Plus il y a de versions, plus il est facile de faire apparaître des vulnérabilités de validation, c'est un risque systémique. --- En résumé, c'est comme déplacer la responsabilité de "l'immutable", mais il est encore difficile de dire si le seuil de contrôle des risques a réellement été réduit. --- On a l'impression d'utiliser un mécanisme plus complexe pour compenser les défauts d'un autre, mais au final, le risque est peut-être encore plus caché. --- L'expérience de développement est agréable, mais la précision du prix de règlement est le vrai enjeu, n'est-ce pas ? --- C'est absurde, encore une "solution innovante", qui n'est qu'une autre pièce du domino. --- Alors, comment le taux de prêt va-t-il évoluer ? Voilà la vraie question.

Voir l'originalRépondre0

AirdropHunter007

· 01-07 19:27

Ah, c'est ça l'idée. La séparation de l'identité et de l'état, j'aime cette approche... Enfin quelqu'un a comblé le vide du contrôle de version.

Voir l'originalRépondre0