Hier, dans le dépôt GitHub de Babylon, j’ai fouillé la documentation sur la mise en œuvre des signatures EOTS. J’y ai vu une section expliquant les conditions de déclenchement de la « double signature punie », et ça mérite qu’on en parle. Beaucoup de gens ne voient BABY que comme un jeton de gouvernance. Pourtant, dans la couche de sécurité du protocole, son rôle est bien plus fondamental que ce qu’on imagine.
EOTS (Extractable One-Time Signatures) est une primitive de sécurité clé introduite par Babylon depuis le réseau principal Bitcoin. Sa logique est très “dure” : si un Finality Provider signe deux en-têtes de blocs différents à la même hauteur, la clé privée peut être directement déduite. Côté Bitcoin, n’importe quel client léger peut utiliser cette preuve de double signature pour déverrouiller le capital UTXO mis en gage, sans confiance. Mais côté BABY, la logique est plus complexe : elle dépend de la machine à états BSN pour confirmer la finalité.
Le point crucial est le suivant : la punition de BABY est un déclenchement « synchrone » mais une exécution « asynchrone ». Après que le Sentinel (sentinelle) a terminé la dénonciation sur le réseau principal Bitcoin, la partie BABY doit attendre que tous les nœuds terminent la transition d’état avant d’exécuter la destruction des parts de co-mise en gage. Ce décalage temporel varie généralement de quelques minutes à une dizaine de minutes, et peut s’allonger davantage en cas de congestion extrême. Cela signifie que, dès qu’une action malveillante de double signature de la part d’un FP survient, la vitesse de réaction côté BABY dépend de l’efficacité de la finalité côté BSN.
Ce qui mérite encore plus d’attention, c’est le chemin de propagation de la punition. Côté Bitcoin, une fois l’UTXO récupéré, les stakers peuvent récupérer le capital BTC verrouillé, mais les gains sont remis à zéro. En revanche, les parts de co-mise en gage détruites côté BABY sont effacées de manière permanente de la circulation. En pratique, ce design transforme BABY en « garantie de sécurité » du protocole : le coût pour un FP qui agit mal n’est pas seulement une perte de réputation côté Bitcoin, c’est aussi une évaporation permanente du portefeuille BABY.
Donc, pour évaluer si un FP est fiable, il ne suffit pas de regarder uniquement son temps de fonctionnement normal. Il faut aussi vérifier si le montant de BABY qu’il met en jeu (self-stake) est suffisamment élevé pour qu’il puisse, dans la lutte entre « gains de la malveillance » et « coût d’une punition », rester fermement du côté de la sincérité. Plus le self-stake est élevé, plus l’incitation économique à agir mal est théoriquement faible, car il engage de l’argent réel pour attester de sa fiabilité.$BTC
Récemment, le nombre de FP actifs de Babylon a déjà dépassé 150, mais la proportion de BABY self-stake représente plus de 30% pour moins d’un tiers.
#baby @BabylonLabs_io $BABY