Récemment, j'ai étudié la conception de l'architecture du protocole Walrus et j'ai identifié un problème crucial — comment le système peut-il résister en cas de défaillance massive de nœuds ou de partition réseau ?
Cela revient aux questions de récupération après sinistre et de résilience du réseau. Au niveau du protocole, il faut prévoir des plans de réponse à l'avance, et non improviser en cas de problème. Plus important encore, il faut effectuer régulièrement des tests de résilience, simuler diverses situations extrêmes pour voir si les données peuvent réellement être restaurées.
Il y a deux indicateurs clés pour mesurer la résilience du système — l'objectif de temps de récupération(RTO) et l'objectif de point de récupération des données(RPO). Ces deux indicateurs doivent être conçus de manière claire, et les résultats des tests doivent être publics et transparents. C'est la seule façon de vraiment vérifier si un protocole peut résister à l'épreuve du temps.
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
HashBandit
· Il y a 15h
Les métriques RTO/RPO de ngl semblent bonnes sur le papier, mais à l'époque de mes activités minières, nous avons appris à la dure que la résilience théorique et le chaos réel du réseau sont deux bêtes très différentes... Walrus ferait mieux d'avoir une récupération testée en conditions réelles, à vrai dire.
Voir l'originalRépondre0
MetaEggplant
· Il y a 23h
En résumé, il s'agit de savoir si l'on peut résister à une explosion soudaine, et la transparence est essentielle pour RTO et RPO.
Voir l'originalRépondre0
GasFeeVictim
· 01-13 10:22
Vraiment, la résistance de la solution Walrus face aux attaques ne se limite pas à des discours en l'air, il faut se baser sur les données RTO et RPO pour en juger, sinon ce ne sont que des discours théoriques.
Voir l'originalRépondre0
AirdropAnxiety
· 01-12 10:38
Honnêtement, la plupart des projets n'osent même pas rendre publics les résultats de test des indicateurs RTO et RPO, n'est-ce pas ?
Voir l'originalRépondre0
WagmiOrRekt
· 01-11 16:54
Honnêtement, la plupart des projets sont flous sur les indicateurs RTO et RPO, et peu osent vraiment publier les résultats des tests.
Voir l'originalRépondre0
ruggedSoBadLMAO
· 01-11 16:53
Ce gars-là ose vraiment demander, si le nœud plante, le système peut-il encore fonctionner ? On dirait que Walrus doit protéger son atout maître suffisamment solidement.
Voir l'originalRépondre0
LiquidityHunter
· 01-11 16:53
Les chiffres RTO et RPO ont-ils été rendus publics ? Sans données, c'est du vent. Actuellement, beaucoup de protocoles vantent leur résilience, mais peu osent vraiment les tester.
Voir l'originalRépondre0
SoliditySurvivor
· 01-11 16:41
Putain, les indicateurs RTO et RPO sont vraiment trop négligés, la plupart des projets n'osent même pas rendre leurs résultats de test publics...
Voir l'originalRépondre0
StableNomad
· 01-11 16:37
En réalité... les métriques RTO/RPO ne sont qu'une mise en scène de sécurité si personne ne les teste régulièrement. Cela me rappelle l'UST en mai — tout le monde *affirmait* que le mécanisme était à toute épreuve jusqu'à ce que ce ne soit plus le cas. Walrus ferait mieux d'avoir des histoires de guerre pour étayer cela, et pas seulement des affirmations de stabilité théoriques
Voir l'originalRépondre0
Liquidated_Larry
· 01-11 16:28
Honnêtement, les indicateurs RTO et RPO sont pour la plupart des chiffres sur papier, très peu de projets ont réellement subi des tests de résistance extrêmes.
Récemment, j'ai étudié la conception de l'architecture du protocole Walrus et j'ai identifié un problème crucial — comment le système peut-il résister en cas de défaillance massive de nœuds ou de partition réseau ?
Cela revient aux questions de récupération après sinistre et de résilience du réseau. Au niveau du protocole, il faut prévoir des plans de réponse à l'avance, et non improviser en cas de problème. Plus important encore, il faut effectuer régulièrement des tests de résilience, simuler diverses situations extrêmes pour voir si les données peuvent réellement être restaurées.
Il y a deux indicateurs clés pour mesurer la résilience du système — l'objectif de temps de récupération(RTO) et l'objectif de point de récupération des données(RPO). Ces deux indicateurs doivent être conçus de manière claire, et les résultats des tests doivent être publics et transparents. C'est la seule façon de vraiment vérifier si un protocole peut résister à l'épreuve du temps.