Avez-vous déjà vécu ce genre de situation ? Le service de livraison indique que votre colis a été signé, mais vous n’avez vu… rien du tout. En vérifiant les caméras, on constate que le livreur l’a bien déposé devant la porte, mais que quelqu’un l’a ensuite volé. Les informations logistiques sont exactes de A à Z, mais le résultat n’est pas celui que vous vouliez. Sur la blockchain aussi, il existe ces moments étranges où « l’enregistrement est correct, mais les conséquences ne le sont pas » : ils se cachent dans une pièce simplement mentionnée en passant à la section 9 du livre blanc.
@BabylonLabs_io La section 9 explique, dans le cadre du déploiement multi-chaînes, que chaque chaîne qui se connecte à un coffre doit faire tourner un « client léger Bitcoin » afin de vérifier que votre BTC est bien verrouillé, sans tricher, sur la blockchain Bitcoin. La formule du client léger est très économe : il synchronise uniquement les en-têtes de blocs, puis utilise Merkle pour prouver qu’une transaction donnée existe. Sur le papier, ça paraît solide… mais il y a un bug très rarement discuté : la réorganisation de la blockchain.
La chaîne Bitcoin se réorganise parfois : il peut être « éjecté » historiquement jusqu’à plusieurs dizaines de blocs si elle n’en est plus que plus longue. Le client léger ne regarde que les en-têtes, donc il ne voit qu’une « chaîne la plus longue ». Mais si la transaction de votre coffre est justement empaquetée dans un bloc qui finira isolé, au moment où la réorganisation s’achève, le client léger constatera alors — que le dépôt a littéralement disparu. Le problème, c’est quoi ? Pendant les minutes de la réorganisation, le collBTC sur la chaîne du contrat aurait pu déjà être frappé. Les infos de livraison sont figées : colis livré. Vous ouvrez la boîte… et elle est vide. #baby
Le mécanisme de gouvernance du livre blanc de Babylon, chiffré $BABY , a été conçu pour répondre à ce type de cas limite : rare au point de se compter en poussière, mais capable de tout faire exploser s’il survient. Combien de blocs de confirmation faut-il pour valider la réorganisation ? 6 confirmations suffisent-elles, ou vaut-il mieux être prudent et attendre 12 ? Pendant la réorganisation, le coffre fait-il un arrêt d’urgence, ou continue-t-il à fonctionner normalement ? Ces paramètres ne sont pas gravés dans le code du coffre : au fond, ce ne sont pas des problèmes techniques, mais des choix de tolérance au risque. Les personnes qui détiennent des votes BABY tracent, en substance, une graduation pour « la tolérance à l’incertitude » de l’ensemble du système.
La minimisation de la confiance veut surtout éliminer les motivations de malveillance humaines. Mais la réorganisation n’est pas une intention : c’est une loi de la physique. Le code peut empêcher les mauvais de rentrer par la porte. Il ne peut toutefois pas empêcher que des probabilités s’y faufilent en silence. DYOR.
@BabylonLabs_io La section 9 explique, dans le cadre du déploiement multi-chaînes, que chaque chaîne qui se connecte à un coffre doit faire tourner un « client léger Bitcoin » afin de vérifier que votre BTC est bien verrouillé, sans tricher, sur la blockchain Bitcoin. La formule du client léger est très économe : il synchronise uniquement les en-têtes de blocs, puis utilise Merkle pour prouver qu’une transaction donnée existe. Sur le papier, ça paraît solide… mais il y a un bug très rarement discuté : la réorganisation de la blockchain.
La chaîne Bitcoin se réorganise parfois : il peut être « éjecté » historiquement jusqu’à plusieurs dizaines de blocs si elle n’en est plus que plus longue. Le client léger ne regarde que les en-têtes, donc il ne voit qu’une « chaîne la plus longue ». Mais si la transaction de votre coffre est justement empaquetée dans un bloc qui finira isolé, au moment où la réorganisation s’achève, le client léger constatera alors — que le dépôt a littéralement disparu. Le problème, c’est quoi ? Pendant les minutes de la réorganisation, le collBTC sur la chaîne du contrat aurait pu déjà être frappé. Les infos de livraison sont figées : colis livré. Vous ouvrez la boîte… et elle est vide. #baby
Le mécanisme de gouvernance du livre blanc de Babylon, chiffré $BABY , a été conçu pour répondre à ce type de cas limite : rare au point de se compter en poussière, mais capable de tout faire exploser s’il survient. Combien de blocs de confirmation faut-il pour valider la réorganisation ? 6 confirmations suffisent-elles, ou vaut-il mieux être prudent et attendre 12 ? Pendant la réorganisation, le coffre fait-il un arrêt d’urgence, ou continue-t-il à fonctionner normalement ? Ces paramètres ne sont pas gravés dans le code du coffre : au fond, ce ne sont pas des problèmes techniques, mais des choix de tolérance au risque. Les personnes qui détiennent des votes BABY tracent, en substance, une graduation pour « la tolérance à l’incertitude » de l’ensemble du système.
La minimisation de la confiance veut surtout éliminer les motivations de malveillance humaines. Mais la réorganisation n’est pas une intention : c’est une loi de la physique. Le code peut empêcher les mauvais de rentrer par la porte. Il ne peut toutefois pas empêcher que des probabilités s’y faufilent en silence. DYOR.
