........
Publier
MICHAEL MOORE
·
--
J’ai enfin consulté la page 101 de la propre BTCVault trustless de Babylon, au lieu de me contenter des résumés d’actualité, et un seul détail a changé la façon dont j’ai lu l’ensemble du design.
D’après la documentation officielle de Babylon Labs, chaque vault dispose d’un claimer préconfiguré. Les parties autorisées à réclamer ou à retirer le bitcoin verrouillé doivent être définies au moment même où le vault est créé. Personne en dehors de cet ensemble ne pourra jamais le réclamer, quoi qu’il arrive ensuite.
Le produit DeFi visé est lui aussi préconfiguré. Une fois qu’un vault est construit pour un contrat spécifique de prêt ou d’emprunt, il ne peut pas être redirigé vers un autre par la suite.
C’est un vrai compromis, pas une simple note en bas de page.
La rigidité est ce qui réduit la surface d’attaque, mais cela signifie aussi moins de flexibilité qu’une piscine DeFi classique, où les fonds circulent entre différentes stratégies chaque fois qu’un utilisateur le souhaite.
Voici une chronologie que je me suis construite moi-même, qui n’est mentionnée nulle part comme un seul chiffre. Le livre blanc de Babylon est sorti début août, et le testnet public était encore visé pour la dernière semaine de mai de l’année suivante, selon l’appel des fondateurs de la société.
Cela fait environ neuf mois entre le document et un environnement de test en conditions réelles, un rythme volontairement lent pour quelque chose qui réécrit la manière dont Bitcoin touche la DeFi.
La partie qui me tracasse encore se situe plus profondément dans la cryptographie. Dans BitVM3, ce qui est réellement masqué et vérifié via le circuit brouillé, ce n’est pas toute la logique du contrat de prêt qui se trouve sur l’autre chaîne : c’est le vérificateur SNARK lui-même.
Cela signifie que l’étiquette trustless dépend aussi, en partie, du fait que ce contrat intelligent externe soit écrit correctement. C’est une distinction que je n’ai pas vue Babylon expliquer clairement en dehors des cercles techniques.
J’aime que le design choisisse la permanence plutôt que la commodité, car la permanence est ce qui rend une réclamation applicable sans intermédiaire.
Je me demande encore comment Babylon prévoit d’expliquer cette frontière entre le vérificateur SNARK et le reste aux détenteurs de BTC au quotidien, une fois que TBV sera réellement en ligne.
@BabylonLabs_io #baby $BABY
D’après la documentation officielle de Babylon Labs, chaque vault dispose d’un claimer préconfiguré. Les parties autorisées à réclamer ou à retirer le bitcoin verrouillé doivent être définies au moment même où le vault est créé. Personne en dehors de cet ensemble ne pourra jamais le réclamer, quoi qu’il arrive ensuite.
Le produit DeFi visé est lui aussi préconfiguré. Une fois qu’un vault est construit pour un contrat spécifique de prêt ou d’emprunt, il ne peut pas être redirigé vers un autre par la suite.
C’est un vrai compromis, pas une simple note en bas de page.
La rigidité est ce qui réduit la surface d’attaque, mais cela signifie aussi moins de flexibilité qu’une piscine DeFi classique, où les fonds circulent entre différentes stratégies chaque fois qu’un utilisateur le souhaite.
Voici une chronologie que je me suis construite moi-même, qui n’est mentionnée nulle part comme un seul chiffre. Le livre blanc de Babylon est sorti début août, et le testnet public était encore visé pour la dernière semaine de mai de l’année suivante, selon l’appel des fondateurs de la société.
Cela fait environ neuf mois entre le document et un environnement de test en conditions réelles, un rythme volontairement lent pour quelque chose qui réécrit la manière dont Bitcoin touche la DeFi.
La partie qui me tracasse encore se situe plus profondément dans la cryptographie. Dans BitVM3, ce qui est réellement masqué et vérifié via le circuit brouillé, ce n’est pas toute la logique du contrat de prêt qui se trouve sur l’autre chaîne : c’est le vérificateur SNARK lui-même.
Cela signifie que l’étiquette trustless dépend aussi, en partie, du fait que ce contrat intelligent externe soit écrit correctement. C’est une distinction que je n’ai pas vue Babylon expliquer clairement en dehors des cercles techniques.
J’aime que le design choisisse la permanence plutôt que la commodité, car la permanence est ce qui rend une réclamation applicable sans intermédiaire.
Je me demande encore comment Babylon prévoit d’expliquer cette frontière entre le vérificateur SNARK et le reste aux détenteurs de BTC au quotidien, une fois que TBV sera réellement en ligne.
@BabylonLabs_io #baby $BABY
Avertissement : ce contenu inclut des opinions de tiers. Il ne constitue pas un conseil. Binance Ai peut être utilisée, sans garantie de résultat. Consultez les CG.