J’ai déposé sur le testnet TBV en m’attendant à ce que le vault passe en ligne dès que ma transaction a été confirmée. Ce n’est pas arrivé. Il y a eu une attente que je n’avais pas prévue, et comprendre pourquoi a changé ma façon de penser l’ensemble du flux.
Un peg-in n’est pas « en ligne » après une seule confirmation Bitcoin. TBV a besoin d’un certain nombre de confirmations empilées au-dessus avant que le vault soit considéré comme réglé, car une seule confirmation peut encore être réorganisée hors de la chaîne (reorg). Sur un dépôt EVM, un bloc final est quasiment final. Sur Bitcoin, un bloc est une revendication, pas un règlement — la vraie garantie n’apparaît qu’à quelques blocs plus tard, car l’annuler reviendrait à réécrire une vraie preuve de travail (proof-of-work).
Ça m’a rappelé un virement bancaire qui affiche « en attente » dans votre appli avant d’être réellement réglé. Le montant apparaît immédiatement à l’écran, mais la banque ne vous laisse pas toucher les fonds tant qu’elle n’est pas sûre que le côté de l’émetteur ne peut plus encore les rejeter.
Ce qui m’a surpris, c’est que TBV ne peut pas contourner ça comme le ferait un dépositaire (custodian). Un dépositaire se contente de dire « faites-moi confiance, c’est dedans » et passe à la suite. TBV n’a personne à qui dire ça : il doit attendre que Bitcoin règle effectivement la revendication, parce que tout l’intérêt est de ne pas avoir besoin de la parole de quelqu’un.
Donc l’attente liée aux confirmations n’est pas une aspérité UX qu’on optimise plus tard. C’est le coût de l’abandon d’un dépositaire qui absorberait normalement cette incertitude à votre place et vous dirait que tout va bien.
Ça me fait me demander combien de personnes qui testent s’attendent à ce que la vitesse des dépôts finisse par correspondre à une application DeFi « normale », plutôt que de réaliser que cette attente est en fait la partie sans confiance (trustless) qui fonctionne correctement, et non un bug en attente d’être corrigé.
@BabylonLabs_io $BABY #baby $BLESS $TAKE #Babylon
Un peg-in n’est pas « en ligne » après une seule confirmation Bitcoin. TBV a besoin d’un certain nombre de confirmations empilées au-dessus avant que le vault soit considéré comme réglé, car une seule confirmation peut encore être réorganisée hors de la chaîne (reorg). Sur un dépôt EVM, un bloc final est quasiment final. Sur Bitcoin, un bloc est une revendication, pas un règlement — la vraie garantie n’apparaît qu’à quelques blocs plus tard, car l’annuler reviendrait à réécrire une vraie preuve de travail (proof-of-work).
Ça m’a rappelé un virement bancaire qui affiche « en attente » dans votre appli avant d’être réellement réglé. Le montant apparaît immédiatement à l’écran, mais la banque ne vous laisse pas toucher les fonds tant qu’elle n’est pas sûre que le côté de l’émetteur ne peut plus encore les rejeter.
Ce qui m’a surpris, c’est que TBV ne peut pas contourner ça comme le ferait un dépositaire (custodian). Un dépositaire se contente de dire « faites-moi confiance, c’est dedans » et passe à la suite. TBV n’a personne à qui dire ça : il doit attendre que Bitcoin règle effectivement la revendication, parce que tout l’intérêt est de ne pas avoir besoin de la parole de quelqu’un.
Donc l’attente liée aux confirmations n’est pas une aspérité UX qu’on optimise plus tard. C’est le coût de l’abandon d’un dépositaire qui absorberait normalement cette incertitude à votre place et vous dirait que tout va bien.
Ça me fait me demander combien de personnes qui testent s’attendent à ce que la vitesse des dépôts finisse par correspondre à une application DeFi « normale », plutôt que de réaliser que cette attente est en fait la partie sans confiance (trustless) qui fonctionne correctement, et non un bug en attente d’être corrigé.
@BabylonLabs_io $BABY #baby $BLESS $TAKE #Babylon
