Il y a une chose qui m’a fait arrêter d’explorer l’écran du bout des doigts.

Je suis allé consulter le document @BabylonLabs_io sur le processus de mise en jeu et j’ai constaté que la mise en jeu n’est activée qu’une fois que la transaction Bitcoin entre dans le mempool—non. Et même pas après une simple confirmation. Babylon ne considère cette mise en jeu comme remplissant les conditions nécessaires au traitement ultérieur qu’après avoir atteint le k-depth configuré dans le protocole, puis seulement elle entre dans le processus d’activation suivant. C’est un paramètre de gouvernance dans le module x/btccheckpoint.

C’est aussi un argument de vente lié à la sécurité de Bitcoin, mais pour la plupart des utilisateurs, un seul bloc serait probablement censé suffire pour être définitif.

C’est une partie qui n’est jamais mise en avant dans les supports de présentation. Le marketing du marché affirme que les horodatages de Bitcoin vous apportent une garantie de sécurité issue du PoW de Bitcoin—techniquement, c’est vrai. Mais cela ne tient qu’à partir du moment où votre mise en jeu est enfouie suffisamment profondément dans la chaîne. En cas de confirmations insuffisantes, une réorganisation à faible profondeur de la chaîne peut toujours provoquer le rollback de la transaction de mise en jeu ; c’est pourquoi Babylon ne la considère pas à l’avance comme remplissant les conditions de traitement ultérieur. Babylon traite la profondeur de confirmation comme un seuil de sécurité majeur pour continuer à traiter cette transaction de mise en jeu, et pas simplement comme une question de « inclusion ». Sur le plan mécaniste, c’est logique—on ne peut pas bâtir une sécurité sur du sable—mais cela vous dit aussi, en silence, que toutes les confirmations ne véhiculent pas le même niveau de confiance.

À mi-tâche, je suis allé chercher une tasse de café, et je me suis demandé : ce délai protège-t-il les utilisateurs, ou ne fait-il que révéler à quel point les premiers blocs sont fragiles ? Peut-être les deux.

#baby $BABY