En lisant la spécification technique de @BabylonLabs_io , le script de staking Bitcoin utilise OP_CHECKMULTISIGVERIFY pour imposer l’exigence de quorum des validateurs. Mais voici la subtilité : le script lui-même n’encode pas les conditions de slashing — il vérifie seulement que le nombre requis de validateurs a signé.
Cela signifie que le verrouillage Bitcoin est structurellement simple : soit l’utilisateur retire après le déliement, hmm.. soit l’ensemble des validateurs signe pour pénaliser. La logique réelle du slashing — ce qui constitue un comportement fautif, quelle part est pénalisée, quels validateurs signent — est entièrement hors chaîne, appliquée par la chaîne Babylon Genesis, et non par le script de Bitcoin.
Ainsi, la couche Bitcoin fournit une finalité cryptographique au verrouillage, mais les conditions de ce verrou sont déterminées par l’état de la chaîne Babylon. Si la chaîne Babylon dit "le validateur X a mal agi, pénalisez ses délégateurs", le quorum des validateurs signe la transaction de slashing, et Bitcoin l’exécute. Mais Bitcoin n’a aucun moyen de vérifier de manière indépendante si le slashing était justifié.
Cela inverse le modèle de confiance : Bitcoin garantit que le UTXO ne peut pas être dépensé sans la signature du quorum, hmm.. mais il ne garantit pas que le quorum utilise cette signature de façon honnête. La sécurité migre de la preuve de travail de Bitcoin vers le consensus des validateurs de Babylon. La partie "native" est réelle, mais la partie "sans confiance" repose sur les mêmes hypothèses que n’importe quelle chaîne PoS : que l’ensemble des validateurs est honnête et économiquement aligné.
Comparé à un pont purement basé sur Ethereum, Babylon réduit la surface d’attaque — pas de token enveloppé, pas de risque de minting — mais n’élimine pas la dépendance aux validateurs. Le script de verrouillage n’est qu’un outil ; la chaîne Babylon est le juge.
Si l’ensemble des validateurs est compromis, le script de Bitcoin offre-t-il une défense au-delà d’un verrou dont les attaquants contrôlent déjà la clé ?
#baby $BABY
Cela signifie que le verrouillage Bitcoin est structurellement simple : soit l’utilisateur retire après le déliement, hmm.. soit l’ensemble des validateurs signe pour pénaliser. La logique réelle du slashing — ce qui constitue un comportement fautif, quelle part est pénalisée, quels validateurs signent — est entièrement hors chaîne, appliquée par la chaîne Babylon Genesis, et non par le script de Bitcoin.
Ainsi, la couche Bitcoin fournit une finalité cryptographique au verrouillage, mais les conditions de ce verrou sont déterminées par l’état de la chaîne Babylon. Si la chaîne Babylon dit "le validateur X a mal agi, pénalisez ses délégateurs", le quorum des validateurs signe la transaction de slashing, et Bitcoin l’exécute. Mais Bitcoin n’a aucun moyen de vérifier de manière indépendante si le slashing était justifié.
Cela inverse le modèle de confiance : Bitcoin garantit que le UTXO ne peut pas être dépensé sans la signature du quorum, hmm.. mais il ne garantit pas que le quorum utilise cette signature de façon honnête. La sécurité migre de la preuve de travail de Bitcoin vers le consensus des validateurs de Babylon. La partie "native" est réelle, mais la partie "sans confiance" repose sur les mêmes hypothèses que n’importe quelle chaîne PoS : que l’ensemble des validateurs est honnête et économiquement aligné.
Comparé à un pont purement basé sur Ethereum, Babylon réduit la surface d’attaque — pas de token enveloppé, pas de risque de minting — mais n’élimine pas la dépendance aux validateurs. Le script de verrouillage n’est qu’un outil ; la chaîne Babylon est le juge.
Si l’ensemble des validateurs est compromis, le script de Bitcoin offre-t-il une défense au-delà d’un verrou dont les attaquants contrôlent déjà la clé ?
#baby $BABY