le jour, et aujourd’hui enfin je me suis assis avec le primitif cryptographique sous le modèle de slashing complet de Babylon, les signatures à usage unique extractibles, parce que j’ai passé trois jours à faire des mentions d’eots sans jamais le déballer.
Commence par le problème qu’il résout. La sécurité Proof of Stake exige de punir l’équivoque : un validateur qui signe deux blocs contradictoires à la même hauteur. Sur une chaîne PoS normale, le protocole se contente de confisquer les tokens mis en caution, ceux qui se trouvent sur cette même chaîne. Mais les stakers de Babylon engagent du BITCOIN, un actif qui vit sur une chaîne qui n’a aucune idée que le réseau PoS existe et qui ne peut pas être sommée de confisquer quoi que ce soit. Comment slasher une collatérale que la chaîne d’exécution ne peut pas atteindre ?
Eots répond avec une propriété qui ressemble à un bug jusqu’à ce que vous compreniez que c’est précisément le point central. Le schéma de signature est à usage unique : on signe exactement un message par utilisation de clé, et tout fonctionne normalement. Signez DEUX messages contradictoires avec la même clé, et les deux signatures ensemble révèlent mathématiquement votre clé privée. Pas à un comité, pas à un tribunal—à toute personne qui observe.
Suivez ce que cela implique. Au moment où un fournisseur de finalité s’équivoque, sa propre clé BTC devient extractible, et la voie de slashing pré-signée dans le script de staking devient exécutable. La punition n’exige absolument pas que le Bitcoin comprenne la chaîne PoS : la mauvaise conduite fabrique elle-même la preuve et, simultanément, l’arme.
L’élégance qui mérite d’être nommée : cela transforme le slashing d’une action de gouvernance en une conséquence mathématique. Pas de débat en comité sur la question de l’équivoque : vos signatures publiées révèlent la clé… ou elles ne la révèlent pas.
Ce qui me laisse encore incertain, c’est la frontière entre l’automatisation d’eots et le rôle des comités de covenant dans le consensus. La documentation décrit les deux, et la répartition des responsabilités entre la partie « math » et la majorité n’est pas pleinement explicite dans les pages que j’ai lues. C’est donc l’assemblage de demain à inspecter.
@BabylonLabs_io #baby $BABY
Commence par le problème qu’il résout. La sécurité Proof of Stake exige de punir l’équivoque : un validateur qui signe deux blocs contradictoires à la même hauteur. Sur une chaîne PoS normale, le protocole se contente de confisquer les tokens mis en caution, ceux qui se trouvent sur cette même chaîne. Mais les stakers de Babylon engagent du BITCOIN, un actif qui vit sur une chaîne qui n’a aucune idée que le réseau PoS existe et qui ne peut pas être sommée de confisquer quoi que ce soit. Comment slasher une collatérale que la chaîne d’exécution ne peut pas atteindre ?
Eots répond avec une propriété qui ressemble à un bug jusqu’à ce que vous compreniez que c’est précisément le point central. Le schéma de signature est à usage unique : on signe exactement un message par utilisation de clé, et tout fonctionne normalement. Signez DEUX messages contradictoires avec la même clé, et les deux signatures ensemble révèlent mathématiquement votre clé privée. Pas à un comité, pas à un tribunal—à toute personne qui observe.
Suivez ce que cela implique. Au moment où un fournisseur de finalité s’équivoque, sa propre clé BTC devient extractible, et la voie de slashing pré-signée dans le script de staking devient exécutable. La punition n’exige absolument pas que le Bitcoin comprenne la chaîne PoS : la mauvaise conduite fabrique elle-même la preuve et, simultanément, l’arme.
L’élégance qui mérite d’être nommée : cela transforme le slashing d’une action de gouvernance en une conséquence mathématique. Pas de débat en comité sur la question de l’équivoque : vos signatures publiées révèlent la clé… ou elles ne la révèlent pas.
Ce qui me laisse encore incertain, c’est la frontière entre l’automatisation d’eots et le rôle des comités de covenant dans le consensus. La documentation décrit les deux, et la répartition des responsabilités entre la partie « math » et la majorité n’est pas pleinement explicite dans les pages que j’ai lues. C’est donc l’assemblage de demain à inspecter.
@BabylonLabs_io #baby $BABY