@BabylonLabs_io Je reviens sans cesse à la façon dont la condition de slashing de Babylon est formulée. Signez deux blocs contradictoires à la même hauteur avec votre clé EOTS, et les mathématiques elles-mêmes révèlent votre clé privée. Pas de comité pour l’examiner, pas de vote pour décider : la cryptographie déclenche simplement.

Ce qui se cache dessous est plus intéressant que le mécanisme lui-même. Un marché de gestionnaires de clés tiers existe désormais précisément pour empêcher que cela ne se déclenche, car le protocole ne sait pas distinguer un opérateur qui a triché de celui dont le logiciel client a simplement buggué. Le discours « sans confiance, sans comité » est réel au niveau du protocole, mais la sécurité dans le monde réel dépend maintenant en partie de la question de savoir si un fournisseur de finalité donné a pris la peine d’adopter l’un de ces prestataires. C’est une décision commerciale privée, pas quelque chose d’inscrit dans la chaîne.

Pour quiconque alloue du BTC via un fournisseur de finalité, c’est une variable que vous ne pouvez pas vérifier actuellement. L’adoption des fournisseurs n’est pas divulguée, n’est pas standardisée et ne fait partie d’aucune checklist de due diligence que j’ai vue circuler.

La pureté cryptographique était censée éliminer le besoin de faire confiance au jugement de qui que ce soit. Elle a plutôt déplacé ce jugement d’un cran, dans la sélection de fournisseurs que personne ne publie.

Une condition de slashing « sans comité » en a quand même un : c’est simplement le marché des vendeurs qui décide qui est couvert.

La lacune honnête ici est que je n’ai pas non plus de chiffres d’adoption, donc c’est une observation structurelle, pas un risque mesuré.
#baby $BABY $BLESS $HOME
Votre fournisseur de finalité exécute-t-il une protection des clés EOTS ?