La majorité des choix technologiques pour l'infrastructure blockchain sont en réalité le résultat de compromis sous pression à court terme. Les indicateurs de performance sont-ils atteints ? La maîtrise des coûts est-elle assurée ? La mise en ligne est-elle respectée ? Ces questions sont posées et reposées. Ce qui est moins fréquent, c’est que quelqu’un réfléchisse sérieusement — dans cinq, dix ans, à quels problèmes ces données historiques seront confrontées.



Mais ceux qui ont une expérience de la maintenance à long terme savent que les données accumulées par une application vivante ne sont pas un fardeau. Ces données font partie intégrante du fonctionnement du système. Si l’on choisit une mauvaise gestion, chaque itération de fonctionnalités ou extension de performance ultérieure devra payer le prix des décisions prises auparavant.

La conception de Walrus est justement l’inverse — elle ne commence pas par "comment écrire le plus rapidement possible", mais par "comment rendre les données disponibles à long terme" en remontant la chaîne jusqu’à l’architecture technique. La différence peut sembler subtile, mais elle détermine en réalité le cycle de vie de tout le système.

Concrètement, dès la création d’un objet de données, celui-ci se voit attribuer une identité stable. Même si la logique métier évolue ou si l’état sur la chaîne est renouvelé, la relation de référence de cet objet reste inchangée. Cela permet à la couche applicative de construire ses logiques métier autour d’une même référence sur le long terme, plutôt que de courir après de nouvelles versions de données.

Quelle est la conséquence la plus immédiate de cette conception ? Une réduction exponentielle de la complexité du système. Lorsque la relation de référence ne fluctue plus fréquemment, la gestion des index, le contrôle d’accès, la stratégie de cache, et d’autres composants deviennent plus simples. Pour les applications nécessitant une stabilité opérationnelle, cela élimine une source potentielle de défaillance dans toute la catégorie.

Du point de vue technique, Walrus supporte le stockage d’objets de données de plusieurs Mo, avec une architecture redondante multi-nœuds garantissant la disponibilité. Sur le réseau de test, la latence de lecture reste stable à quelques secondes, ce qui suffit pour supporter les besoins d’accès en temps réel, et ne se limite pas à l’archivage de données froides. Ce niveau de performance est crucial pour l’utilité des applications Web3.
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.
  • Récompense
  • 9
  • Reposter
  • Partager
Commentaire
0/400
zkNoobvip
· Il y a 23h
Tu as tout à fait raison, la plupart des projets sont effectivement rushés, personne ne pense vraiment à long terme. La réflexion inversée de Walrus est vraiment innovante, en remontant la chaîne de vie des données pour concevoir l'architecture, c’est bien plus fiable que ces équipes qui ne regardent que le délai de mise en ligne. --- Encore une histoire de "long-termisme", mais cette fois, ça semble vraiment différent... Sur la stabilité de l'identité, j'ai l'impression d'avoir résolu un problème qui me préoccupait depuis longtemps. --- Latence de lecture en seconde ? Ça a l'air bien, mais je ne sais pas à quel point le testnet et le mainnet diffèrent, web3 dans cet état... --- En gros, c’est changer la mentalité à court terme en mentalité à long terme, ça paraît noble, mais combien de projets peuvent vraiment faire ça ? --- Je crois à la réduction de la complexité, moins d’index et de gestion des permissions, ça évite pas mal de soucis, mais qu’en est-il du coût de maintenance ? Tu l’as calculé ? --- La disponibilité des données en mégaoctets est bien gérée, si on pouvait supporter le gigaoctet, ce serait vraiment exceptionnel.
Voir l'originalRépondre0
CryptoCross-TalkClubvip
· 01-10 07:09
Mort de rire, enfin quelqu'un qui accepte de revenir sur la tombe de données de dix ans dans le passé, c'est ça la véritable pensée infrastructurelle. Cette fois, un produit qui n'a pas été enchaîné par des KPI à court terme, c'est vraiment rare.
Voir l'originalRépondre0
tx_pending_forevervip
· 01-07 19:55
Les paroles sont belles, mais une fois en ligne, ce n'est pas la réalité qui vous donnera une leçon... J'ai entendu trop souvent cette excuse de « long terme ». --- Donc, Walrus, c'est pour ne pas qu'on regarde nos données dans dix ans en se plaignant ? Ça sonne bien. --- Je dois admettre que le fait de citer inchangé évite vraiment beaucoup de tracas, sinon modifier une logique métier entraîne une multitude de conséquences. --- Latence en seconde ? Le réseau de test et le réseau principal, ce n'est pas la même chose, attendons de voir quand ça sera vraiment lancé. --- Enfin quelqu'un qui pense au problème de maintenance à long terme, la plupart des projets s'en fichent complètement. --- Le court terme et le long terme sont toujours en contradiction, le délai fixé par le VC ne laisse pas le choix.
Voir l'originalRépondre0
LiquidityLarryvip
· 01-07 19:54
Bien dit, ce n’est que maintenant que certains pensent à la pérennité à long terme, alors que ces infrastructures précipitées ont déjà été remboursées. L’idée de maintenir l’identité des données inchangée est vraiment astucieuse, cela évite de devoir tout reconstruire à chaque fois. La démarche de Walrus ressemble un peu à la création d’une infrastructure véritable, pas à une solution temporaire. Une latence de quelques secondes suffit pour les applications en temps réel, c’est bien plus efficace qu’une base de données froide. Choisir la mauvaise architecture peut vraiment coûter cher, on en voit trop d’exemples sanglants. Une fois que la relation d’interdépendance est stabilisée, la majorité des sources de panne du système disparaissent. Cette méthode de conception rétroactive devrait être la norme depuis longtemps, ce n’est pas une différenciation concurrentielle. La gestion des données détermine la survie, cette phrase n’a pas de faux. Le stockage de plusieurs Mo avec redondance, enfin une solution fiable.
Voir l'originalRépondre0
LuckyHashValuevip
· 01-07 19:47
C'est ça que l'infrastructure blockchain devrait être, pas simplement accumuler des indicateurs de performance Utilisation à long terme > vantardise à court terme, l'industrie a vraiment besoin de cette approche La stabilité de la référence, ce détail de conception est pas mal, évite de courir après la version des données tous les jours Le problème, c'est combien de projets pensent vraiment à ce qui se passera dans cinq ans...
Voir l'originalRépondre0
LidoStakeAddictvip
· 01-07 19:43
Honnêtement, la plupart des projets aujourd'hui sont des solutions rapides forcées par les délais et la pression de financement, personne ne se soucie vraiment de ce qui se passera dans cinq ans. L'idée de Walrus est vraiment inversée, en remontant la chaîne de vie des données pour concevoir l'architecture, c'est ainsi qu'on doit construire un produit à long terme. Avoir une identité stable peut sembler simple, mais combien de pièges peut-on éviter à l'avenir grâce à cela ?
Voir l'originalRépondre0
GateUser-ccc36bc5vip
· 01-07 19:41
C'est exactement la démarche que je voulais voir, le long terme ne devrait pas faire autrement
Voir l'originalRépondre0
AirdropFreedomvip
· 01-07 19:40
C'est la véritable pensée infrastructurelle, pas de la simple accumulation d'indicateurs de performance --- Honnêtement, la plupart des projets sont à court terme, ils creusent des pièges pour les générations futures --- Disponibilité à long terme > déploiement rapide, cette logique est trop rare dans le web3 --- Une identité stable, c'est génial, cela évite beaucoup de tracas liés aux index et au contrôle des permissions --- Une latence au niveau de la seconde peut vraiment faire la différence, enfin une solution de stockage un peu sérieuse --- Le design qui ne modifie pas la relation de référence est à prendre en exemple, il est bien plus élégant que d'autres solutions --- Choisir une mauvaise gestion, c'est vraiment payer une facture sans fin, les successeurs devront toujours en porter la responsabilité --- En remontant de la disponibilité à long terme vers l'architecture, cette approche va à l'encontre de l'intuition de la majorité --- Des données de plusieurs Mo avec redondance, la demande d'accès pour les applications en temps réel peut être couverte, c'est fiable
Voir l'originalRépondre0
CountdownToBrokevip
· 01-07 19:37
Cette idée est vraiment brillante, enfin quelqu'un qui pense à considérer les données comme un actif plutôt qu'un fardeau La plupart des projets auraient dû apprendre cette approche depuis longtemps, au lieu de creuser des pièges pour respecter les délais Le design de Walrus, qui repose sur des références stables, consiste en réalité à aider les applications à éviter la dette technique future Une lecture en secondes peut encore supporter des applications en temps réel, ces données ont vraiment une vitalité Après avoir vu tant de projets blockchain, il est rare de voir ceux qui envisagent vraiment ce que sera la situation dans cinq ans
Voir l'originalRépondre0
Afficher plus
  • Épingler

Trader les cryptos partout et à tout moment
qrCode
Scan pour télécharger Gate app
Communauté
Français (Afrique)
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)