J’ai passé ma soirée à parcourir le centre d’apprentissage officiel de Babylon Labs au lieu de me contenter d’un résumé quelque part, et un seul chiffre m’a arrêté net au milieu de ma lecture. @babylonlabs_io
En y entrant, je partais du principe que si vous déléguez votre BTC à un fournisseur de finalité (Finality Provider) et qu’il se comporte mal, vous perdriez toute votre position mise en jeu (staked). C’est ainsi que fonctionne généralement le slashing dans la plupart des systèmes PoS que j’ai examinés.
Ce n’est pas comme cela que Babylon l’aborde.
Seule une petite fraction de la mise, 0,1 %, est slas(hée) si un Finality Provider se comporte mal. Le reste de votre BTC vous est restitué. C’est une pénalité partielle, pas une issue tout-ou-rien.
Le détail plus subtil que je n’avais pas relevé : même pendant la période de désengagement (unbonding), une fois que vous avez déjà demandé à quitter, votre BTC peut encore être slas(hé) partiellement jusqu’à ce que la fenêtre de 301 blocs (environ 50 heures) se ferme complètement. Demander à partir ne supprime donc pas instantanément le risque.
Avec ça en tête, on a l’impression qu’il s’agit d’un calibrage délibéré plutôt que d’une simple contrainte technique laissée en suspens. Le slashing total pourrait décourager plus efficacement les comportements fautifs, mais il rend aussi les délégateurs excessivement prudents au sujet de la personne à qui ils délèguent. Une pénalité plus petite et limitée semble conçue pour garder le système utilisable sans que chaque décision de délégation ne ressemble à un enjeu à haut risque.
Parfois, le choix de design le plus intéressant n’est pas le plus strict : c’est celui qui équilibre la responsabilité et la praticité.
Comment pesez-vous le slashing partiel par rapport au slashing total lorsque vous choisissez à qui déléguer ?
@BabylonLabs_io #baby $BABY
En y entrant, je partais du principe que si vous déléguez votre BTC à un fournisseur de finalité (Finality Provider) et qu’il se comporte mal, vous perdriez toute votre position mise en jeu (staked). C’est ainsi que fonctionne généralement le slashing dans la plupart des systèmes PoS que j’ai examinés.
Ce n’est pas comme cela que Babylon l’aborde.
Seule une petite fraction de la mise, 0,1 %, est slas(hée) si un Finality Provider se comporte mal. Le reste de votre BTC vous est restitué. C’est une pénalité partielle, pas une issue tout-ou-rien.
Le détail plus subtil que je n’avais pas relevé : même pendant la période de désengagement (unbonding), une fois que vous avez déjà demandé à quitter, votre BTC peut encore être slas(hé) partiellement jusqu’à ce que la fenêtre de 301 blocs (environ 50 heures) se ferme complètement. Demander à partir ne supprime donc pas instantanément le risque.
Avec ça en tête, on a l’impression qu’il s’agit d’un calibrage délibéré plutôt que d’une simple contrainte technique laissée en suspens. Le slashing total pourrait décourager plus efficacement les comportements fautifs, mais il rend aussi les délégateurs excessivement prudents au sujet de la personne à qui ils délèguent. Une pénalité plus petite et limitée semble conçue pour garder le système utilisable sans que chaque décision de délégation ne ressemble à un enjeu à haut risque.
Parfois, le choix de design le plus intéressant n’est pas le plus strict : c’est celui qui équilibre la responsabilité et la praticité.
Comment pesez-vous le slashing partiel par rapport au slashing total lorsque vous choisissez à qui déléguer ?
@BabylonLabs_io #baby $BABY