三和社區-老葉

#dusk $DUSK @Dusk
Le moyen le plus fondamental d’empêcher le mauvais usage sur une chaîne publique, c’est le coût du Gas : plus la logique à exécuter est complexe, plus les frais sont élevés. Le principe de ce mécanisme, c’est que le réseau puisse comprendre précisément combien d’opérations une transaction donnée effectue. Mais si la logique du contrat lui-même est confidentielle, ce postulat tient-il encore debout ? Voilà le point technique que je veux remettre en question.

En tant que blockchain de couche 1, Dusk Network prend en charge la norme de contrats intelligents sécurisés et confidentiels (XSC). Lors de l’exécution d’un contrat confidentiel, les détails des transformations d’état sont encapsulés dans des preuves à connaissance nulle. Les vérificateurs externes se contentent alors de vérifier si la preuve est valide, au lieu de contrôler ligne par ligne les calculs effectués par le contrat. Le problème, c’est que la tarification exige généralement de connaître précisément la quantité de calcul : par exemple, combien de fois l’état est lu/écrit, combien de boucles sont exécutées, etc. Dans un contexte confidentiel, le vérificateur ne peut pas forcément déduire ces informations aussi directement que dans un contrat en clair.

La contradiction est la suivante : si le mécanisme de facturation fait un compromis et passe à des frais fixes ou à une estimation grossière, alors un utilisateur malveillant peut concevoir un contrat qui exécute un volume de calcul bien supérieur aux frais, en le faisant à un coût relativement faible, puis saturer les ressources de calcul des vérificateurs — créant ainsi un risque de déni de service dissimulé. À l’inverse, si le mécanisme de facturation veut absolument correspondre avec précision à la quantité d’opérations, cela revient à divulguer indirectement des informations sur la complexité du contrat, ce qui entre en conflit avec l’objectif initial de confidentialité.

Ce n’est pas que la norme XSC ne peut pas être appliquée, mais bien que la précision de la facturation et la force de la confidentialité doivent nécessairement trouver un équilibre. Et la façon de concevoir ce compromis aura un impact direct sur la stabilité des contrats intelligents confidentiels en situation réelle, sous pression du réseau.

$DUSK : est-ce que, sans divulguer les détails des calculs, le mécanisme Gas peut rester efficace pour dissuader l’abus ? Je pense que c’est un point clé pour savoir si la norme XSC peut tenir dans des scénarios de forte concurrence.

#dusk $DUSK @Dusk
Les transactions financières traditionnelles exigent de la « certitude » : une transaction est considérée comme terminée une fois qu’elle est effectuée, sans crainte qu’elle soit annulée quelques minutes plus tard. En revanche, beaucoup de blockchains publiques utilisent une finalité probabiliste. En théorie, les blocs peuvent être réorganisés ; simplement, la probabilité diminue avec le temps. Cet écart est précisément l’endroit le plus facile où les actifs institutionnels se retrouvent bloqués lorsqu’ils cherchent à être mis en chaîne—et c’est le sujet que je veux aborder cette fois.

Dusk Network, en tant que blockchain de couche 1, adopte un mécanisme de consensus appelé Succinct Attestation, une variante de la preuve d’enjeu. Contrairement aux conceptions qui nécessitent d’attendre la confirmation de plusieurs blocs, en s’appuyant sur la confiance accumulée par la probabilité, l’objectif de Succinct Attestation est d’atteindre une finalité définitive de façon certaine en très peu de temps. Une fois qu’un bloc est confirmé par un vote des validateurs, il ne sera plus remis en cause.

Décomposé, ce mécanisme repose sur un vote hiérarchisé des validateurs : une première partie des validateurs forme un consensus initial, puis une seconde couche de validateurs effectue la confirmation finale. L’ensemble du processus s’exécute en quelques secondes seulement. Il n’est pas nécessaire d’attendre une dizaine de minutes, comme c’est le cas avec certaines blockchains, avant d’oser dire que cette transaction est vraiment entérinée.

Cette conception s’accorde en réalité avec les contrats intelligents confidentiels. Si le contenu des transactions est lui-même confidentiel, pour les institutions financières qui doivent faire la compensation ou le règlement, il est encore moins acceptable d’accepter une incertitude du type « cette transaction pourrait être annulée ». Une finalité rapide et certaine revient donc à fournir l’infrastructure de base pour la norme XSC ; et ensemble, elles correspondent bien davantage aux exigences du secteur financier pour la notion de « transaction = achèvement ».

Le design de consensus de $DUSK ne cherche pas seulement la vitesse : il intègre directement la certitude dont les scénarios financiers ont besoin dans les couches fondamentales du protocole. Et je pense que cette approche est plus proche des besoins d’application réels que de se contenter de brandir un objectif de très haut TPS.

#dusk $DUSK @Dusk
Beaucoup de gens, lorsqu’ils parlent de la « blockchain de confidentialité », pensent instinctivement que cela signifie « toutes les transactions sont masquées ». Mais la conception de Dusk n’est en réalité pas aussi univoque. Dans le livre blanc, le modèle de transactions est décomposé en deux parcours. Ce design à double voie, c’est justement l’aspect qui mérite d’être examiné séparément.

D’abord, du point de vue pédagogique. Dusk Network, en tant que blockchain de couche 1, prend en charge deux modes de transaction : l’un est celui des transactions confidentielles, où le montant et les participants sont dissimulés. La validité est vérifiée grâce aux preuves à divulgation nulle de connaissance (zero-knowledge proofs). Cette voie s’accompagne de la norme de contrats de sécurité confidentiels (XSC) et vise les scénarios financiers qui exigent la confidentialité ; l’autre concerne les transactions publiques et transparentes, dont l’état est directement visible sur la chaîne et consultable par n’importe qui, fonctionnant selon le modèle traditionnel de comptes. Autrement dit, Dusk ne force pas tout le monde à utiliser le mode confidentialité : il permet simplement que les états confidentiels et publics coexistent sur la même blockchain.

C’est là que surgit le point délicat. Le design à double voie semble très flexible, mais pour que les deux états soient interopérables, c’est en soi un défi d’ingénierie : si des actifs provenant d’un compte public doivent être transférés vers un contrat intelligent confidentiel, ou si les résultats d’un contrat confidentiel doivent être reflétés dans l’état public, il faut une couche de mécanisme de conversion au milieu. Celle-ci doit garantir que la confidentialité n’est pas divulguée tout en préservant la vérifiabilité de l’état public. Par rapport au fait de choisir un seul mode et de s’y tenir, la complexité double directement.

Un autre problème concret concerne l’expérience utilisateur. En pratique, comment un utilisateur standard peut-il déterminer quel scénario doit recourir aux transactions confidentielles et quel scénario aux transactions publiques ? Si le seuil de bascule entre les deux voies est trop élevé, la plupart des gens risquent de n’utiliser que le mode public. Dans ce cas, les cas d’utilisation des contrats intelligents confidentiels resteraient-ils finalement cantonnés à quelques institutions, au lieu de se diffuser à l’ensemble de l’écosystème ?

$DUSK : selon moi, la question clé à observer est de savoir si la flexibilité du design à double voie peut être transformée en une expérience produit vraiment facile à utiliser, plutôt que de laisser la complexité se traduire par un seuil d’adoption.

#dusk $DUSK @Dusk
Le risque le plus facile à négliger dans les systèmes de preuves à connaissance nulle (ZK) n’est pas la performance, mais le circuit lui-même. Tout contrat confidentiel reposant sur des technologies de type ZK-SNARK s’appuie en coulisses sur un ensemble de logique de circuits ; une fois déployé et mis en production, modifier revient à beaucoup plus compliqué. C’est l’aspect technique que je me suis le plus pris en compte en consultant les données de Dusk.

Dusk Network vise à être une blockchain de confidentialité pour les applications financières. En tant que blockchain de couche 1 (Layer-1), elle prend nativement en charge la norme de contrats de sécurité confidentiels (XSC). La justesse des contrats intelligents confidentiels dépend de la question de savoir si la conception des circuits sous-jacents est totalement exempte de failles. Dans les contrats intelligents classiques, s’il y a une erreur de logique, au moins les auditeurs externes peuvent lire le code source et retracer le déroulement de l’exécution pour repérer le problème ; mais, dans les contrats confidentiels, l’état lui-même est chiffré. Une fois la conception du circuit imparfaite, il devient difficile pour des observateurs externes de déceler l’anomalie uniquement à partir d’informations publiques.

Techniquement, je doute surtout de ceci : si, à l’avenir, la norme XSC doit être mise à niveau, par exemple pour ajouter des fonctionnalités ou corriger une faille, comment s’assurer que ces changements au niveau du circuit ne viendront pas compromettre les contrats confidentiels déjà déployés ? En général, la mise à jour d’un contrat intelligent consiste surtout à remplacer la logique et à redéployer ; mais dans les systèmes impliquant des circuits de preuve à connaissance nulle, il faut souvent refaire le « trusted setup », ce qui rend le processus plus complexe. Et si l’on s’y prend un peu mal, on risque même d’introduire de nouvelles hypothèses de sécurité.

Un autre problème concret concerne le seuil d’audit. Les auditeurs capables de comprendre les circuits ZK tout en maîtrisant la logique des contrats financiers sont déjà rares. En superposant ces deux domaines, les contrats intelligents confidentiels ne peuvent que réduire encore le nombre d’équipes disposées et capables de mener des audits approfondis. Si l’écosystème d’audit ne suit pas, les institutions qui voudraient confier de gros actifs à des contrats conformes à la norme XSC seront probablement toujours dans l’attente.

$DUSK À prouver n’est pas seulement qu’il est possible de créer des contrats confidentiels, mais que cette architecture de circuits peut rester stable et digne de confiance sur le long terme, malgré l’itération et la pression d’audit.

#dusk $DUSK @Dusk
Un site d’analyse de données on-chain peut vous dire tout ce que vous voulez sur n’importe quelle blockchain publique : la TVL, le nombre d’adresses actives, et les flux de fonds. C’est une manière essentielle de construire la confiance dans l’industrie de la cryptographie — les utilisateurs n’ont pas à croire ce que disent les autres ; ils peuvent simplement vérifier eux-mêmes la chaîne. Mais si une blockchain cache le contenu des transactions dès le niveau du protocole, cette méthode de vérification tient-elle toujours ? C’est la question qui m’est venue en relisant la documentation de Dusk.

Dusk Network se positionne comme une blockchain de confidentialité pour les applications financières. En tant que blockchain de niveau 1, elle supporte nativement le standard de contrats sécurisés confidentiels (XSC). Lors de l’exécution de contrats intelligents confidentiels, les montants, les positions et les parties impliquées ne sont pas exposés directement aux navigateurs d’exploration de la chaîne. C’est une condition nécessaire pour les utilisateurs institutionnels, mais pour la visibilité externe de l’ensemble de l’écosystème, c’est un mouvement en sens inverse.

Le nœud du paradoxe se trouve ici : pendant longtemps, l’industrie crypto a construit la confiance grâce à la « vérifiabilité publique ». Les utilisateurs sont généralement prêts à déposer leurs actifs dans le protocole parce qu’ils peuvent vérifier eux-mêmes, en consultant la chaîne, que les flux de fonds sont corrects. La trajectoire de Dusk va précisément dans la direction opposée : elle ne demande pas aux utilisateurs de faire confiance à ce qui « se voit », mais à ce qui « se prouve » — les preuves à divulgation nulle remplacent le registre public. Le vérificateur peut confirmer que la transaction est légale, mais les observateurs externes ne peuvent pas voir les détails. Cette transformation du modèle de confiance, pour des utilisateurs déjà habitués aux données on-chain publiques, pose une barre d’entrée assez élevée.

À mon avis, le problème le plus concret est le suivant : si les acteurs externes ne peuvent pas calculer directement l’activité on-chain, comment la croissance de l’écosystème peut-elle être quantifiée de manière objective ? Si même les indicateurs de base doivent passer par des preuves enveloppées dans des contrats intelligents confidentiels pour être déduits indirectement, est-ce que le seuil d’analyse ne ralentira pas au final le rythme d’adoption de Dusk ?

$DUSK ne doit pas seulement prouver qu’il est possible techniquement de préserver la confidentialité ; il s’agit aussi, après la redéfinition du mécanisme de confiance, de savoir si l’écosystème peut continuer à attirer des utilisateurs qui veulent « prouver la confiance plutôt que faire confiance aux chiffres ».

#dusk $DUSK @Dusk
L’endroit le plus fascinant de la DeFi, c’est la composabilité : la sortie d’un protocole peut être directement injectée dans le suivant, et les fonds s’assemblent librement comme des briques LEGO. Mais cet avantage repose sur une condition — tous les états sont publics et transparents, et n’importe quel contrat peut lire le solde et les positions de n’importe qui. C’est précisément là que je suis resté bloqué en relisant le livre blanc de Dusk.

Dusk Network se positionne comme une blockchain de couche 1 dédiée à la confidentialité des applications financières. Elle prend nativement en charge la norme de contrats sécurisés en confidentialité (XSC), permettant l’exécution de contrats intelligents confidentiels en état de protection. Le problème, c’est que lorsque l’état du contrat est dissimulé, les autres protocoles peuvent-ils encore interagir avec lui de manière sûre ? La composabilité dépend de la « lisibilité », tandis que la confidentialité dépend de « l’impossibilité de lire ». Au niveau de l’architecture, ce sont deux exigences fondamentalement incompatibles.

La norme XSC tente de résoudre cette tension : à l’aide de preuves à divulgation nulle de connaissance (zero-knowledge), des contrats externes n’ont pas besoin de voir l’état complet pour vérifier si une condition est remplie. Par exemple, vérifier si le collatéral est suffisant ou si l’éligibilité est conforme. Autrement dit, la composabilité passe de « données partagées » à « preuves partagées » : il ne s’agit pas seulement d’ajouter une couche de chiffrement, mais d’un changement conceptuel.

Mais je me demande quand même si ce modèle de composabilité fondé sur des preuves, lors de la concaténation entre protocoles, n’entraînera pas une latence et des coûts de gas nettement plus élevés que dans le modèle traditionnel d’état public. Si à chaque interaction il faut produire et vérifier une couche de preuve, l’utilisabilité des contrats intelligents confidentiels dans des scénarios financiers complexes dépend, dans une large mesure, de la capacité à maintenir ces coûts à un niveau acceptable.

$DUSK , le véritable test n’est pas de savoir s’il est possible d’atteindre la confidentialité, mais plutôt, une fois la confidentialité obtenue, de savoir si l’écosystème peut encore s’assembler librement comme auparavant.

#dusk $DUSK @Dusk
Les institutions financières traditionnelles veulent faire migrer leurs actifs sur la blockchain : quel est le principal blocage ? Ce n’est pas la barrière technique, mais le fait que « une fois la mise en chaîne effectuée, toutes les contreparties, tous les montants et toutes les positions se retrouvent exposés au grand jour » — pour les institutions, c’est tout simplement inacceptable. C’est aussi pour cela que, en relisant la white paper de Dusk, je me suis particulièrement intéressé à la norme XSC (Confidential Security Contracts).

Dusk Network se positionne comme une blockchain de confidentialité pour les applications financières. En tant que blockchain de couche 1, elle ne traite pas la confidentialité comme un simple module ajouté en option : elle prend en charge directement les contrats intelligents confidentiels au niveau du protocole. Cela signifie que la logique du contrat lui-même peut gérer des informations sensibles ; les montants des transactions et l’identité des participants peuvent rester confidentiels, tout en permettant encore, sur la chaîne, de vérifier la légalité des transactions.

Mais alors : si le contenu des transactions n’est pas visible, comment les autorités de régulation peuvent-elles procéder à une vérification de conformité ? Voilà le véritable problème structurel auquel doivent faire face toutes les blockchains de confidentialité destinées aux institutions. L’approche de la norme XSC consiste à utiliser des preuves à divulgation nulle (zero-knowledge proofs) pour séparer « la vérification » de « la divulgation » : l’état du contrat peut rester confidentiel, mais l’exécution du contrat respecte toujours des règles qui peuvent être prouvées, sans qu’il soit nécessaire de publier les détails à tout le monde.

Je pense que la valeur de ce design est qu’il permet de ne plus avoir à choisir entre « conformité » et « confidentialité », mais de les traiter comme deux niveaux distincts. Toutefois, dans la réalité, les exigences relatives aux obligations de divulgation varient selon les juridictions. La norme XSC peut-elle s’adapter avec souplesse aux cadres réglementaires de chaque région ? C’est probablement la clé qui détermine si les institutions seront réellement prêtes à l’adopter.

L’opportunité de $DUSK ne consiste pas à brandir un slogan sur la confidentialité, mais à savoir s’il est possible de transformer cette norme de contrats intelligents confidentiels en une infrastructure que les institutions financières oseront utiliser et que les autorités de régulation accepteront.

#dusk
Je viens de lire le livre blanc @Dusk et je suis tombé sur la partie concernant la norme XSC (Confidential Security Contracts). J’ai fait une pause et j’y ai longuement réfléchi.

Dusk Network se présente comme une blockchain de confidentialité pour les applications financières. En tant que chaîne Layer-1, elle transforme directement les contrats intelligents confidentiels en standard natif, plutôt que d’ajouter une couche de confidentialité en tant que module par-dessus une chaîne EVM existante. Ce point d’entrée est différent de la plupart des projets.

La contradiction réside justement là : dans le secteur financier, il faut de la confidentialité, mais on a aussi besoin de la capacité d’audit. Ces deux exigences semblent naturellement incompatibles. Les chaînes publiques traditionnelles exposent toutes les informations de transaction sur la chaîne : n’importe qui peut les consulter, ce qui est tout simplement impossible pour l’émission d’actifs détenus à l’échelle institutionnelle. En revanche, si l’on cache entièrement le contenu des transactions, comment les autorités de régulation peuvent-elles vérifier la conformité ? La norme XSC cherche précisément à résoudre ce dilemme : grâce aux preuves à divulgation nulle de connaissance (zero-knowledge proofs), l’état du contrat reste confidentiel tout en conservant une vérifiabilité. Ainsi, les tiers en dehors des deux parties à la transaction ne peuvent pas observer les détails, tout en pouvant prouver que la transaction est légale.

Pour ma part, la question principale en étudiant cette section est la suivante : une fois les contrats intelligents confidentiels déployés à grande échelle, le coût de calcul nécessaire pour que les nœuds valident les transactions ne risque-t-il pas de ralentir le débit global de la chaîne ? Après tout, la génération et la vérification des preuves à divulgation nulle ne sont pas gratuites. Si de véritables institutions financières transfèrent l’émission d’actifs de grande taille sur Dusk, le système peut-il tenir en conditions de forte concurrence ? C’est, à mon avis, le point clé : savoir si la norme XSC peut réellement s’ancrer dans des cas d’usage financiers.

$DUSK ne cherche pas à répondre à « faut-il de la confidentialité », mais plutôt à « la confidentialité et la conformité peuvent-elles coexister ». Cette orientation me paraît plus concrète que de se contenter de réclamer la décentralisation.

Bon courage, patron.

#baby
Un protocole qui se présente comme trustless et en self-custody : comment se fait-il que, dans l’écosystème de liquidation, on ait besoin de prestataires dotés de « MEV capability » ? Quand j’ai vu cette phrase dans le document de roadmap de Babylon, je suis resté perplexe.

En cherchant, j’ai découvert que, dans la planification de l’écosystème TBV, l’équipe officielle indiquait que, pour que le protocole se diffuse réellement, il fallait l’arrivée d’une série d’infrastructures et de prestataires de services spécialisés, notamment des custodians, des banques numériques, des fournisseurs API, des Bitcoin LSTs, ainsi que des « liquidators with MEV capability ». Autrement dit, pour la partie liquidation, l’équipe officielle s’attend à ce que l’exécution efficace repose sur des acteurs professionnels disposant de capacités liées au MEV.

Le conflit est là : dans le vocabulaire traditionnel de la DeFi, le MEV entre souvent en contradiction avec les récits de « fairness » et de « trustlessness » ; il est généralement associé au front-running et à d’autres comportements de course en tête qui désavantagent les utilisateurs ordinaires. D’un côté, TBV met en avant la self-custody du BTC, l’absence d’intermédiaires et une vérification on-chain publique et transparente ; de l’autre, dans la conception de son écosystème de liquidation, il s’appuie en pratique sur des acteurs professionnels capables de MEV pour gagner en réactivité. Cela signifie que l’efficacité de l’exécution des liquidations reste, dans une certaine mesure, entre les mains d’une minorité de participants disposant d’un avantage technique.

À mon sens, le trustless résout la question de la confiance au niveau de la garde des actifs et de la vérification des retraits, mais cela ne signifie pas que toute la couche d’exécution de l’écosystème soit, elle aussi, parfaitement équitable. @BabylonLabs_io L’introduction d’acteurs MEV dans la liquidation revient, dans une certaine mesure, à reconnaître cette réalité. $BABY À mesure que l’écosystème mûrit, la conception de l’équité sur le marché des liquidations sera un point qu’il vaudra la peine de suivre de près.

#baby
Si je veux prêter la même quantité de BTC à deux protocoles DeFi différents en même temps, via un seul vault, est-ce que c’est possible ? Au départ, je pensais que oui, car le livre blanc dit toujours que le TBV est une « programmable Bitcoin collateral ».

Mais en cherchant des informations, j’ai découvert que la réponse est en réalité : non. L’équipe l’a expliqué clairement lors du Founders Call récent : un vault ne peut pas router en même temps vers plusieurs protocoles DeFi. Lors de sa création, chaque vault est lié à un unique protocole de contrat intelligent externe. La raison est très claire : ils ne veulent pas qu’un même vault soit exposé simultanément à plusieurs applications. En effet, les règles de liquidation et les hypothèses de confiance varient d’un protocole à l’autre ; les mélanger rendrait l’évaluation du risque et sa segmentation beaucoup plus difficiles.

D’un côté, on crie « programmable », ce qui laisse entendre que le BTC peut être assemblé librement comme des blocs pour s’insérer dans divers scénarios DeFi ; de l’autre, dans la conception, ils limitent volontairement chaque vault à un seul protocole. Cela revient à dire que si l’utilisateur veut à la fois participer à des opérations de prêt et à la frappe de stablecoins, il faut découper le BTC en plusieurs parts et verrouiller chacune dans un vault différent. Le capital est alors davantage fragmenté.

Cependant, vu sous un autre angle, ce n’est pas un bug : c’est un arbitrage sécurité choisi activement par l’équipe. Plutôt que sacrifier une partie de la flexibilité, ils évitent que le risque ne se propage entre différents protocoles. Je pense que c’est justement la bonne façon de comprendre l’écosystème $BABY : « programmable » ne veut pas dire « assemblage illimité », mais plutôt « choix à l’intérieur de limites de sécurité ». Cette décision @BabylonLabs_io limitera peut-être la flexibilité à court terme, mais à long terme, elle rendra le TBV plus résistant au risque.

#baby
Pareillement, s’agissant de produits propres à Babylon, pourquoi le BTC staking et le TBV semblent-ils avoir une conception de la confiance assez différente ? C’est une question qui m’est venue après avoir comparé ces deux documents.

Dans le protocole original de BTC staking de Babylon, comme le langage de script de Bitcoin ne dispose pas de fonctionnalité de covenant native, la conception devait s’appuyer sur un ensemble de "covenant emulation committee" (seuil multi-signature 6 sur 9) pour co-signer les transactions d’unbonding et de slashing, afin de garantir que les fonds soient traités conformément aux règles du protocole ; le staker ne peut pas contourner complètement ce comité et agir seul. Ce mécanisme fonctionne déjà depuis un certain temps, et il s’agit aussi d’un compromis que Babylon reconnaît lui-même, dicté par les limites du scripting Bitcoin.

Le paradoxe, c’est que le livre blanc de TBV insiste au contraire sur le fait que le remboursement du vault ne nécessite aucun comité ni qu’un operator signe à la place : il utiliserait directement les preuves de fraude de BitVM3, avec une vérification ZK, pour remplacer ce type de rôle. Dans le même groupe, face à la même contrainte technique — "le script Bitcoin ne dispose pas de covenant" — l’un choisit de résoudre le problème via un comité multi-signature, tandis que l’autre utilise un chemin cryptographique entièrement différent pour contourner le comité : qu’est-ce que cela signifie ? Est-ce que le contexte même du staking est plus complexe (car il implique des règles de slashing) et qu’il ne reste donc pas possible de s’en passer, ou bien est-ce que le plan BitVM3 de TBV s’applique aussi au staking, mais n’a pas encore été migré ?

Je pense que cet écart reflète précisément la vraie valeur du TBV : il ne s’agirait peut-être pas seulement de son propre schéma de remboursement, mais aussi de la feuille de route technique que Babylon souhaite suivre pour se passer, à l’avenir, de la dépendance au comité côté staking. @BabylonLabs_io Si l’on peut vraiment appliquer l’approche de BitVM3 au protocole de staking, $BABY le modèle de confiance de l’écosystème serait alors bien plus cohérent.

#baby
Si un coffre-fort doit être racheté, et qu’il faut que l’autre partie coopère activement pour signer, que se passe-t-il si l’autre partie disparaît ou ne répond pas ? Est-ce que ce BTC restera alors coincé à jamais à l’intérieur ? C’est la première question qui m’est venue après avoir lu le passage de la proposition sur les transactions à signature préventive.

Le livre blanc explique le parcours de rachat avec l’exemple de Bob et Larry : les deux parties signent à l’avance un ensemble de transactions conditionnelles. Ensuite, lorsqu’une condition spécifique (par exemple un seuil de prix) est déclenchée, la partie concernée peut exécuter le rachat. Cette conception évite effectivement le risque de modification unilatérale des conditions, car tous les résultats possibles sont définis dès la création du coffre et signés.

Mais il y a une contradiction : le livre blanc insiste sur le fait que TBV est du « trustless self-custody » et que l’on n’a pas besoin de dépendre d’un tiers pour protéger la sécurité des actifs. Or, avec ce mécanisme de pré-signature, en réalité, il faut toujours que « l’autre partie soit présente et coopère » pour que le processus aille jusqu’au bout. Si, par exemple, l’une des parties jouant le rôle d’adversaire, comme Larry, choisit volontairement de retarder ou de disparaître, alors le BTC de Bob resterait théoriquement bloqué avant le déclenchement de la condition, à moins que le livre blanc n’ait explicitement prévu un chemin de secours comme un timeout ou un refund, pour que les fonds ne soient pas bloqués indéfiniment.

À mon avis, c’est précisément la distinction qu’il faut faire pour évaluer la sécurité de TBV : le self-custody résout le problème de « ne pas se faire voler par un tiers », mais ne signifie pas forcément « pouvoir récupérer l’argent même si l’adversaire disparaît ». Ce sont deux niveaux de protection différents. Pour que @BabylonLabs_io puisse vraiment mettre les utilisateurs en confiance, les détails de la conception du mécanisme de sortie via timeout sont la clé qui détermine si ce système peut être déployé concrètement. $BABY , pour que l’écosystème puisse durer dans le temps, cette pièce du puzzle ne peut pas manquer.

#baby
Le livre blanc présente le TBV comme une « garantie bitcoin programmable » (programmable Bitcoin collateral), en soulignant sa capacité à s’intégrer de manière flexible à divers scénarios DeFi, comme l’octroi de prêts et l’émission de stablecoins. Sur le papier, cela semble très souple. Mais quand je tombe sur la section consacrée au mécanisme de rachat, je remarque une conception qui colle assez mal avec cette image de « flexibilité ».

Le rachat du TBV se fait actuellement selon un mode « whole vault » : on verrouille une certaine quantité de BTC à l’entrée, et lorsqu’on libère les fonds, on rachète l’intégralité du coffre en une seule fois. Le système ne permet pas de débloquer seulement une partie. Autrement dit, si je veux simplement récupérer une petite fraction de mes BTC pour répondre à un besoin de liquidité à court terme, je ne peux pas couper une portion directement à l’intérieur du vault. Je dois racheter l’intégralité du vault, solder toutes les positions de prêt, puis verrouiller à nouveau un nouveau vault pour continuer à utiliser les BTC restants.

Le paradoxe est là : le livre blanc insiste sur le terme « programmable », donnant à penser que le BTC peut être assemblé comme des briques LEGO, de façon flexible, pour s’adapter à différents contextes DeFi. Pourtant, le côté rachat est le plus rigide possible, en mode intégral. Toute modification locale implique de reconstruire l’ensemble du vault, donc un coût de reconstruction. Cela ne correspond finalement pas tout à fait au récit axé sur l’efficacité du capital et l’usage flexible.

Je pense que c’est précisément le problème d’expérience que le TBV doit résoudre avant de pouvoir se populariser : @BabylonLabs_io a fait un travail très solide sur la sécurité, mais pour que $BABY puisse attirer davantage d’utilisateurs réellement actifs, le mécanisme de rachat doit-il pouvoir permettre des retraits partiels ? Cela déterminera directement s’il est vraiment « programmable ».

#baby
Je vais expliquer rapidement : pour qu’un pont inter-chaînes du type BitVM permette aux utilisateurs de retirer des fonds, il faut généralement compter sur un groupe d’operators. Ces derniers avancent d’abord des BTC à l’utilisateur, puis récupèrent ensuite l’argent en le “rachatant” depuis le pont. Le problème, c’est que, quand Bob veut retirer, il faut qu’au moins un operator accepte de lui avancer des fonds ; en revanche, quand Bob veut déposer, il faut que tous les operators coopèrent. Autrement dit, la confiance se retrouve répartie entre tout un groupe de tiers.

Le livre blanc décrit la percée la plus directe de TBV : supprimer entièrement ce rôle d’operator. Dans sa conception, Bob et Larry (c’est-à-dire les deux parties déjà convenues à l’avance) sont eux-mêmes les seuls à pouvoir racheter les BTC. Il n’est pas nécessaire de passer par des intermédiaires pour avancer des fonds ou exécuter le rachat : le retrait est directement maîtrisé par les deux parties elles-mêmes. Cela résout effectivement le problème de confiance lié à cette couche d’operators.

Mais en lisant la section sur la liquidation, je remarque un détail : le livre blanc lui-même admet que l’exécution de la liquidation nécessite une preuve signée par un oracle de prix, et que cette partie “en pratique” implique encore de la confiance envers cet oracle. Donc, même si le point de confiance des operators est supprimé, celui lié à l’oracle de liquidation demeure. Le livre blanc n’évite pas cette question : il la met lui-même en évidence.

Je pense que cela rend TBV finalement plus honnête : la “désintermédiation” n’est pas un processus d’un seul coup, mais plutôt une déconstruction progressive, rôle par rôle, des hypothèses de confiance. @BabylonLabs_io règle d’abord cette partie des operators ; $BABY , l’étape suivante pour l’écosystème, consiste à voir comment traiter la dernière pièce du puzzle : l’oracle de liquidation.

#baby
Le langage de programmation de Bitcoin, le Bitcoin Script, est en réalité assez rudimentaire : il ne peut pas exécuter directement des vérifications cryptographiques complexes. C’est d’ailleurs la raison pour laquelle beaucoup de personnes pensent depuis longtemps que le BTC ne peut pas vraiment participer à la DeFi. Aujourd’hui, je vais expliquer comment TBV contourne cette limite.

L’outil central utilisé dans le livre blanc s’appelle le garbled circuit (circuit d’obfuscation). C’est une technique très ancienne en cryptographie : l’idée consiste à transformer un schéma de calcul en une série de portes de circuit chiffrées, de sorte que deux parties puissent calculer conjointement un résultat sans divulguer chacune leurs propres données d’entrée. Le résultat ne révèle alors que la valeur de ce seul bit—vrai ou faux—et le processus intermédiaire reste totalement invisible. TBV applique cette technologie à la blockchain Bitcoin : elle permet de réaliser le calcul « prouver l’état d’un contrat externe » que Bitcoin Script ne parvient pas à exécuter, en remplaçant ce qui ne pouvait pas être fait directement par Script par une exécution via garbled circuit. Ainsi, une grande partie des calculs est effectuée hors chaîne, et la blockchain n’a plus qu’à vérifier le résultat final, c’est-à-dire le « vrai/faux ».

Le point fort de cette conception, c’est qu’elle n’a pas besoin de modifier les règles de consensus du Bitcoin lui-même, ni de recourir à un soft fork. Elle permet simplement au BTC d’acquérir indirectement la capacité de vérifier une logique complexe. C’est aussi pourquoi TBV peut offrir une autogarde (self-custody), sans avoir à, comme les ponts inter-chaînes traditionnels, confier le BTC à une entité centralisée qui le conserve.

À mon avis, c’est précisément là que l’écosystème du $BABY mérite d’être redécouvert : ce n’est pas juste un autre projet qui « habille » une monnaie, mais une solution concrète au problème des limites du langage de scripts de base de Bitcoin. Et le @BabylonLabs_io remet la technique de garbled circuit, restée longtemps en sommeil en cryptographie, à la bonne place.

#baby
Le livre blanc présente l’amélioration de l’efficacité de TBV de manière particulièrement séduisante : le processus de dépôt peg-in ne prend qu’environ 3 heures (6 confirmations des blocs Bitcoin) et peut être achevé, avec des frais également réduits d’environ trois fois par rapport à la solution BitVM2 précédente. En voyant ces deux chiffres, je pensais que TBV avait effectivement résolu tous les problèmes d’efficacité liés au flux complet des fonds, dans les deux sens.

Mais en lisant attentivement, je me suis rendu compte que la partie concernant le retrait (peg-out) est beaucoup moins simple. Si le dépôt peut être aussi rapide, c’est parce qu’il suffit de confirmer une transaction native sur la blockchain Bitcoin ; en revanche, le retrait doit passer par le mécanisme de preuve de fraude de BitVM3, ce qui oblige la blockchain à conserver une période de contestation. Cela donne aux observateurs le temps de vérifier et de remettre en question l’état du contrat correspondant à ce retrait, et les fonds ne seront donc pas immédiatement disponibles. Autrement dit, l’« amélioration d’efficacité » mise en avant par le livre blanc se produit principalement côté dépôt ; côté retrait, la vitesse reste finalement contrainte par les mécanismes de sécurité, et il est impossible de tout comprimer à l’infini.

Le paradoxe, c’est ceci : d’un côté, TBV utilise l’argument « plus rapide, plus économique » pour attirer les utilisateurs, et de l’autre, il doit rallonger le processus de retrait grâce à la période de contestation afin de garantir la sécurité. Ces deux objectifs sont, en essence, en tension ; ce n’est pas un seul et même mécanisme qui peut permettre d’obtenir simultanément le meilleur des deux.

Je pense que le combat que l’écosystème $BABY devra mener à l’avenir, c’est de réduire davantage ce temps d’attente côté retrait, sans assouplir les hypothèses de sécurité. @BabylonLabs_io a déjà une conception très réussie pour l’expérience de dépôt, mais l’équilibre entre l’efficacité et la sécurité côté retrait sera le facteur clé pour que TBV puisse réellement se généraliser.

#baby $BABY
Avant de continuer, faisons un petit rappel : aujourd’hui, de nombreux schémas de prêt et d’emprunt adossés à des BTC reposent, au niveau de la logique sous-jacente, sur les DLC (Discreet Log Contracts). En termes simples, cela permet de répartir automatiquement l’appropriation d’un actif Bitcoin selon les résultats d’événements externes, en le faisant aller à la bonne partie. Cela ressemble à quelque chose de très décentralisé, mais lorsqu’on passe à la mise en œuvre, la plupart des protocoles de prêt basés sur des DLC ont encore besoin d’un « comité » : celui-ci représente le prêteur pour superviser les conditions, signer et exécuter les transactions de règlement à sa place, afin que, lorsque les conditions de déclenchement sont remplies, les fonds soient correctement redistribués.

Le paradoxe est là : la conception des DLC visait précisément à permettre aux BTC de participer à des contrats conditionnels sans dépendre d’aucun intermédiaire. Or, dans la pratique, on ne parvient pas à contourner « l’intérêt d’une partie représentant le comité ». Le problème de confiance revient alors au point de départ, simplement rebaptisé en comité.

La façon dont TBV traite cette question est différente. Il ne fait pas appel à un comité pour décider à la place de qui que ce soit. Au contraire, il verrouille les BTC dans un vault, puis s’appuie sur le mécanisme de preuve de fraude de BitVM3 et sur des preuves ZK pour vérifier l’état de l’exécution du contrat externe au moment où il se produit. Les conditions de retrait sont directement codées de manière immuable dans le script on-chain : aucune tierce partie n’a besoin de signer pour autoriser en représentant les intérêts de quelqu’un.

Je pense que c’est précisément le problème historique que TBV cherche à résoudre : faire avancer, encore davantage, la « contractualisation conditionnelle en Bitcoin » en la faisant passer d’un modèle dépendant de représentants de comités vers une véritable décentralisation fondée sur la confiance. @BabylonLabs_io , dans l’écosystème de $BABY , fait en réalité ce que le modèle de prêt en DLC n’a jamais résolu proprement : combler l’écart de confiance qui persistait.

#baby
Le livre blanc donne un exemple : Bob et Larry ont signé à l’avance un ensemble de transactions en bitcoins. Les conditions sont figées : si le prix du BTC passe sous 50 000 dollars, Larry peut procéder à la liquidation forcée. En lisant ceci, je ne peux m’empêcher de me poser une question : ce prix de 50 000 dollars, qui le prouve, et par quel moyen le prouve-t-on à la blockchain Bitcoin ?

Le cœur de la conception de TBV est que le vault n’accepte que des preuves ZK de l’état des contrats intelligents externes, et n’accepte aucune valeur déclarée unilatéralement par une quelconque partie. En théorie, cela résout le problème de confiance lié à “qui a le dernier mot”, car avant tout retrait, il faut d’abord vérifier que la preuve ZK correspond bien à l’état actuel du contrat sur la chaîne externe. Mais il existe une faille technique facilement négligée : une preuve ZK peut garantir que “le contrat externe se trouve bien dans un certain état”, mais elle ne peut pas garantir que “les données d’entrée de cet état sont correctes”. Autrement dit, si les données de prix de la chaîne externe sont elles-mêmes des résultats d’oracle manipulés, la vérification ZK de TBV laissera quand même passer le retrait, parce qu’elle vérifie la validité logique, pas l’authenticité des données.

Autrement dit, TBV comble ce manque de confiance lié à “faire confiance au pont”, mais n’a ni l’intention de résoudre le risque propre à l’oracle du contrat externe. Ce sont en fait deux problèmes différents.

Je pense que c’est précisément ce qu’il faut distinguer pour évaluer la sécurité de TBV : <c-1/>@BabylonLabs_io résout les problèmes d’autogarde et de vérification côté Bitcoin, mais <c-2/>$BABY , les protocoles DeFi que l’écosystème doit intégrer, doivent chacun surveiller de leur côté la sécurité de leur propre oracle. Les deux ne doivent pas être confondus.

#baby $BABY
Aujourd’hui, j’aimerais aborder quelque chose de plus “bas niveau” : sur quelles hypothèses la sécurité de la TBV repose-t-elle.

En parcourant le livre blanc, j’ai vu que la vérification des retraits dans la TBV s’appuie sur le mécanisme de preuve de fraude de BitVM3. L’hypothèse centrale est celle de “1-of-N honnêtes”. En termes simples : parmi un ensemble de validateurs/surveillants, il suffit qu’au moins un d’entre eux soit honnête et prêt à soulever des contestations pendant la période de challenge pour que le système puisse détecter un retrait frauduleux. Ce modèle ressemble à un optimistic rollup : l’avantage, c’est que la charge de calcul on-chain est faible. On utilise des garbled circuits pour déplacer la majorité des vérifications hors de la chaîne, et sur la blockchain Bitcoin il n’est nécessaire de vérifier que la preuve finale, compressée.

Mais il y a ici une lacune technique facile à négliger : cette hypothèse de sécurité repose, au final, sur le fait que “quelqu’un observe”. Pendant la période de contestation, s’il n’y a aucune partie qui prenne l’initiative de surveiller et de soumettre une preuve de fraude, un retrait malveillant peut, en théorie, passer. Autrement dit, la TBV déplace le problème de la confiance : au lieu de “faire confiance au pont/relayer”, il faut “faire confiance au fait qu’au moins un watchtower reste en ligne et fonctionne”. Cela n’élimine pas totalement la confiance : cela la redistribue à un rôle dont les incitations économiques sont, elles, plus transparentes.

À mon avis, c’est précisément ce que l’écosystème $BABY doit encore prouver : peut-on mettre en place un mécanisme qui donne aux watchtowers des incitations suffisantes pour rester en ligne à long terme ? La robustesse de la prétention de la TBV à être “trustless” dépend directement de cela. @BabylonLabs_io a fait un choix intelligent, mais ce sont les détails du design du mécanisme qui déterminent réellement la sécurité.