Hier, en feuilletant le livre blanc TBV de BabylonLabs, je suis tombé sur la partie concernant la vérification par preuve à divulgation nulle de connaissance pour les retraits, et je me suis arrêté. Ce n’est qu’après avoir redessiné le chemin de vérification que j’ai compris que j’avais auparavant simplifié le problème à l’excès.@BabylonLabs_io
Je me suis toujours demandé : pourquoi ne pas laisser la chaîne principale de Bitcoin comprendre directement les changements d’état des protocoles externes ? La réponse se trouve dans la frontière de vérification. La conception du script de Bitcoin n’est tout simplement pas faite pour traiter des états externes ; la forcer à le faire modifierait au contraire la logique de vérification d’origine. TBV emprunte donc une voie plus mesurée. Les résultats produits par les protocoles externes sont transformés, via un mécanisme de preuve, en conditions de dépense que Bitcoin peut vérifier de manière autonome ; Bitcoin n’a qu’à déterminer si les conditions soumises respectent les règles.
Dans le livre blanc officiel, le terme « Translation » revient sans cesse. Selon ma compréhension, il s’agit de traduire un état externe en conditions de confiance vérifiables par Bitcoin. Le protocole externe produit des résultats de calcul contraints par des preuves, Bitcoin se charge de la vérification, et les deux sont reliés par des preuves cryptographiques ; du début à la fin, ils ne partagent jamais la même source de confiance. C’est aussi la logique de conception la plus centrale de TBV.
Mais minimiser la confiance ne veut pas dire qu’il n’y a pas de risque. Le client léger de Babylon synchronise seulement les en-têtes de blocs et vérifie les preuves de Merkle. Si le réseau Bitcoin subit une réorganisation, les transactions de dépôt dans des blocs isolés peuvent être annulées, alors que les actifs sur la chaîne du contrat ont peut-être déjà été frappés à l’avance. Un cabinet d’audit de sécurité a simulé une situation : après une panne puis un redémarrage de la chaîne Babylon, le client léger reconnaît encore une ancienne hauteur de bloc, et un pool de minage malveillant soumet une chaîne de bifurcation falsifiée qui passe la vérification. C’est une contrainte liée aux propriétés physiques du mode client léger, pas une faille au niveau du code. Pour cela, la gouvernance $BABY a été introduite : les détenteurs de jetons votent pour décider du nombre de blocs de confirmation. En réalité, cela relève d’un choix de préférence en matière de risque, et non d’un codage technique figé.
Au fond, ce qui compte vraiment dans TBV n’est pas le nombre de scénarios connectés, mais la complexité logique financière que BTC peut prendre en charge sans modifier le modèle de sécurité de Bitcoin. L’intérêt de BABY ne tient peut-être pas au nombre d’applications reliées, mais à la question de savoir si, grâce à cet ensemble de règles de vérification et à la manière dont il coopère avec les calculs externes, il peut faire émerger de nouvelles possibilités.#baby
Je me suis toujours demandé : pourquoi ne pas laisser la chaîne principale de Bitcoin comprendre directement les changements d’état des protocoles externes ? La réponse se trouve dans la frontière de vérification. La conception du script de Bitcoin n’est tout simplement pas faite pour traiter des états externes ; la forcer à le faire modifierait au contraire la logique de vérification d’origine. TBV emprunte donc une voie plus mesurée. Les résultats produits par les protocoles externes sont transformés, via un mécanisme de preuve, en conditions de dépense que Bitcoin peut vérifier de manière autonome ; Bitcoin n’a qu’à déterminer si les conditions soumises respectent les règles.
Dans le livre blanc officiel, le terme « Translation » revient sans cesse. Selon ma compréhension, il s’agit de traduire un état externe en conditions de confiance vérifiables par Bitcoin. Le protocole externe produit des résultats de calcul contraints par des preuves, Bitcoin se charge de la vérification, et les deux sont reliés par des preuves cryptographiques ; du début à la fin, ils ne partagent jamais la même source de confiance. C’est aussi la logique de conception la plus centrale de TBV.
Mais minimiser la confiance ne veut pas dire qu’il n’y a pas de risque. Le client léger de Babylon synchronise seulement les en-têtes de blocs et vérifie les preuves de Merkle. Si le réseau Bitcoin subit une réorganisation, les transactions de dépôt dans des blocs isolés peuvent être annulées, alors que les actifs sur la chaîne du contrat ont peut-être déjà été frappés à l’avance. Un cabinet d’audit de sécurité a simulé une situation : après une panne puis un redémarrage de la chaîne Babylon, le client léger reconnaît encore une ancienne hauteur de bloc, et un pool de minage malveillant soumet une chaîne de bifurcation falsifiée qui passe la vérification. C’est une contrainte liée aux propriétés physiques du mode client léger, pas une faille au niveau du code. Pour cela, la gouvernance $BABY a été introduite : les détenteurs de jetons votent pour décider du nombre de blocs de confirmation. En réalité, cela relève d’un choix de préférence en matière de risque, et non d’un codage technique figé.
Au fond, ce qui compte vraiment dans TBV n’est pas le nombre de scénarios connectés, mais la complexité logique financière que BTC peut prendre en charge sans modifier le modèle de sécurité de Bitcoin. L’intérêt de BABY ne tient peut-être pas au nombre d’applications reliées, mais à la question de savoir si, grâce à cet ensemble de règles de vérification et à la manière dont il coopère avec les calculs externes, il peut faire émerger de nouvelles possibilités.#baby