@BabylonLabs_io Passé la nuit à examiner la manière dont Babylon gère la disponibilité des données et les responsabilités des opérateurs.
À première vue, les exigences de stockage semblent raisonnables. Mais une fois qu’on tient compte de la redondance et de la nécessité de vérifications indépendantes, la vraie question devient moins celle de la capacité brute et davantage celle de qui peut réellement la maintenir dans le temps.
Un système qui exige une capacité de sauvegarde significative peut améliorer la résilience sur le papier. En pratique, il peut aussi changer qui est en mesure de participer. De petits opérateurs pourraient retarder des mises à niveau, réduire le nombre de contreparties qu’ils prennent en charge, ou commencer à s’appuyer sur une infrastructure partagée qu’ils ne contrôlent pas totalement. Avec le temps, cela peut concentrer silencieusement les responsabilités entre les participants les mieux financés.
Pour un réseau comme $BABY cela compte. La sécurité ne concerne pas seulement la cryptographie : elle dépend aussi du fait que suffisamment d’opérateurs indépendants puissent continuer à préserver le système dans des conditions réelles. Un certain coût de redondance est normal. Considérer une copie unique comme une infrastructure durable ne l’est pas.
La question ouverte pour moi est de savoir si la conception actuelle renforce la tolérance aux pannes sans faire payer l’indépendance au réseau. Que se passe-t-il à mesure que l’ensemble des contreparties continue de croître ? Le modèle favorise-t-il encore une participation large, ou favorise-t-il progressivement l’échelle ?
Je suis curieux de savoir comment les autres perçoivent ce compromis.
#baby $GIGGLE $1000SATS
À première vue, les exigences de stockage semblent raisonnables. Mais une fois qu’on tient compte de la redondance et de la nécessité de vérifications indépendantes, la vraie question devient moins celle de la capacité brute et davantage celle de qui peut réellement la maintenir dans le temps.
Un système qui exige une capacité de sauvegarde significative peut améliorer la résilience sur le papier. En pratique, il peut aussi changer qui est en mesure de participer. De petits opérateurs pourraient retarder des mises à niveau, réduire le nombre de contreparties qu’ils prennent en charge, ou commencer à s’appuyer sur une infrastructure partagée qu’ils ne contrôlent pas totalement. Avec le temps, cela peut concentrer silencieusement les responsabilités entre les participants les mieux financés.
Pour un réseau comme $BABY cela compte. La sécurité ne concerne pas seulement la cryptographie : elle dépend aussi du fait que suffisamment d’opérateurs indépendants puissent continuer à préserver le système dans des conditions réelles. Un certain coût de redondance est normal. Considérer une copie unique comme une infrastructure durable ne l’est pas.
La question ouverte pour moi est de savoir si la conception actuelle renforce la tolérance aux pannes sans faire payer l’indépendance au réseau. Que se passe-t-il à mesure que l’ensemble des contreparties continue de croître ? Le modèle favorise-t-il encore une participation large, ou favorise-t-il progressivement l’échelle ?
Je suis curieux de savoir comment les autres perçoivent ce compromis.
#baby $GIGGLE $1000SATS