2026-01-08 19:25:36

Beaucoup de gens regardent les protocoles de stockage en se concentrant uniquement sur le débit et la latence. Mais je pense que la véritable essence, que tout le monde a mal compris, ne réside pas dans les données de performance, mais dans la possibilité de changer encore par la suite.

Les projets précoces fonctionnent tous ainsi : on met en ligne d’abord, peu importe, tant que ça fonctionne, puis on optimise lentement, les problèmes historiques étant traités plus tard. Cela semble raisonnable, mais dès que votre groupe d’utilisateurs, la taille de vos actifs ou le volume de contenu commencent à grossir comme une boule de neige, vous vous retrouverez dans une impasse.

Pourquoi ? Parce que vous ne pouvez pas vraiment agir. Vous voulez modifier la structure des données ? Impossible, cela briserait toute la chaîne de confiance. Refaire la logique centrale ? Encore moins, le risque est trop grand. Nettoyer certaines données redondantes historiques ? C’est un cauchemar — cela peut tout faire basculer.

C’est ici qu’apparaît une différence clé de conception. La méthode traditionnelle consiste à écraser l’objet — le nouvel état remplace l’ancien. Mais certains protocoles ont une approche différente : faire évoluer l’objet — le nouvel état est construit sur le précédent, formant une chaîne de versions continue.

Cela peut sembler un détail technique, mais en réalité, cela change directement la façon dont vous gérez le cycle de vie de votre projet. Une application avec 5 mises à jour d’état par jour, sur un an, cela représente 1800 évolutions de versions. La plupart des frameworks commencent à devenir rigides et à voir leur performance diminuer après environ 200 modifications. Mais si le système est conçu dès le départ pour une évolution à haute fréquence, le résultat est complètement différent.

Donc, ma vision actuelle est la suivante : ces solutions de stockage ne sont pas du tout destinées aux nouveaux projets, mais plutôt à ceux qui veulent adopter une stratégie à long terme, en conservant leur flexibilité dans un contexte de croissance continue des utilisateurs et des actifs.

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.

21 J'aime

Récompense
21
10
Reposter
Partager

Commentaire

0/400

VitalikFanboy42

· 01-11 18:31

Après tout, il s'agit simplement du problème de la dette d'architecture, si j'avais su, je ne me serais pas précipité.

Voir l'originalRépondre0

GasWhisperer

· 01-10 08:52

yo c'est vraiment le vrai truc là... tout le monde obsédé par les chiffres de tps mais complètement à côté de la plaque sur le point d'inflexion où ton système se bloque juste... je l'ai vu se produire cent fois dans les patterns du mempool honnêtement

Voir l'originalRépondre0

blockBoy

· 01-10 05:12

Après tout ce temps, c'est toujours cette problématique du "impossible à modifier en phase finale", Web3 a vraiment connu des échecs dans ce domaine --- La chaîne de versions est intéressante, on dirait qu'elle laisse une porte de sortie pour les projets --- Ce n'est pas faux, ceux qui ont tout misé dès le début regrettent maintenant leurs performances --- Tout est lié... n'est-ce pas la situation actuelle de la majorité des chaînes ? --- Donc, en fin de compte, c'est toujours le choix initial d'architecture qui détermine la vie ou la mort, il n'y a pas de secret --- En suivant cette logique, en fait, beaucoup de chaînes publiques ont fait le mauvais choix dès le départ --- La comparaison entre l'évolution rapide et la rigidité structurelle est vraiment pertinente --- Feuille de route à long terme vs itérations rapides, c'est comme choisir entre le poisson et l'ours --- En gros, ne regardez surtout pas cette solution pour un nouveau projet --- Je pense que c'est vraiment le problème que l'infrastructure Web3 devrait résoudre, pas le TPS

Voir l'originalRépondre0

FOMOrektGuy

· 01-08 19:53

C'est tellement vrai, beaucoup de projets ont été enterrés par leur fardeau historique, il est trop tard pour regretter --- 200 modifications et ça devient rigide ? Sérieusement, beaucoup de L1 auraient dû disparaître depuis longtemps --- L'essentiel est de se demander si l'on peut supporter le changement, la plupart ne le peuvent pas --- La différence entre chaîne d'évolution et couverture est vraiment immense, je n'y avais jamais pensé --- Seul le long terme permet de juger de la qualité d'une conception, ce n'est pas évident à court terme --- Pas étonnant que certains projets deviennent de plus en plus lents, c'était déjà prévu dès la phase de conception --- C'est pour ça qu'il faut choisir la bonne architecture dès le début, la modifier plus tard devient un cauchemar

Voir l'originalRépondre0

metaverse_hermit

· 01-08 19:52

Putain, c'est ça le vrai point important, les indicateurs de performance ne sont que de la poudre aux yeux --- Pas étonnant que tant de projets soient bloqués en phase finale, ils ont dès le départ creusé leur propre tombe --- L'idée de la chaîne de versions est vraiment géniale, ce n'est pas une simple optimisation de performance --- Donc, il faut bien réfléchir dès la phase de conception à l'espace d'expansion futur --- 200 modifications, et c'est figé ? Ces chiffres font mal, combien de projets sont déjà morts --- Seuls les projets à long terme peuvent vraiment profiter de cette solution --- En se basant sur l'évolution des bases de données traditionnelles, le web3 commence enfin à y voir clair --- Les itérations rapides en début de projet sont agréables, mais à la fin, on ne peut plus rien changer, et maintenant, tant de chaînes en souffrent

Voir l'originalRépondre0

SandwichTrader

· 01-08 19:48

Au début, on veut itérer rapidement, mais on réalise ensuite que se bloquer soi-même est la pire chose.

Voir l'originalRépondre0

rugged_again

· 01-08 19:46

Tu as tout à fait raison, beaucoup d'équipes se sont simplement enterrées dans ce piège 200 modifications et elles commencent à s'immobiliser ? J'ai vu pire, elles meurent directement sur place C'est ça le vrai long terme, pas juste en parler en surface Le choix de l'architecture décide vraiment de la vie ou de la mort, les données de performance ne sont que des artifices superficiels L'idée de la chaîne de versions, cela aurait dû être pensé depuis longtemps 1800 évolutions par an et on peut encore sauter partout, c'est ça la vraie conception La mentalité initiale de « ça suffit de faire fonctionner », c'est maintenant tout des dettes

Voir l'originalRépondre0

WenAirdrop

· 01-08 19:30

Maintenant, je comprends, ils ont creusé la fosse dès le début et finissent par y tomber eux-mêmes.

Voir l'originalRépondre0

MemeCurator