Un de mes amis a essayé de m’expliquer l’« escrow » avec une analogie de casier : on met ses affaires dedans, quelqu’un d’autre garde la clé, et on lui fait confiance pour vous la rendre quand il dit qu’il le fera. Je lui ai répondu que c’est aussi comme ça que je visualisais chaque configuration de crypto « custodial » : un casier, avec la main de quelqu’un d’autre sur la clé. Cette comparaison s’est effondrée pour moi quand j’ai suivi, en détail, la façon dont les chemins de dépense sont créés à l’intérieur d’un vault Babylon, car il s’avère qu’il n’y a en fait aucune clé « tenue » de la manière que j’avais imaginée. Le déposant co-signe le script Bitcoin en amont, au moment de la création du vault, et chacune des façons légitimes par lesquelles le BTC peut un jour sortir est déjà inscrite, à ce moment précis, dans l’existence, conjointement par le déposant et les participants au protocole. Je l’ai compris en parcourant un fil de discussion de @BabylonLabs_io qui expliquait la construction du vault étape par étape.

Il n’y a pas de « porte dérobée » laissée pour plus tard. Une fois le vault créé, personne — pas le protocole, pas un ensemble de validateurs, pas un vote de gouvernance futur — ne peut inventer une nouvelle condition de dépense, car l’ensemble des signatures valides a été figé dès le départ et rien après coup ne peut l’élargir. La partie facile à manquer, c’est que ce n’est pas que le protocole promet de ne pas détourner des fonds : c’est que le protocole n’a aucun moyen mécanique de construire une transaction en dehors de ce qui a été pré-signé. C’est un modèle de sécurité différent de celui de la plupart des configurations custodial ou des ponts multisig, où la flexibilité est souvent conservée volontairement pour pouvoir ajuster les clés ou les seuils après le déploiement, ce qui facilite les mises à niveau ; mais c’est aussi, souvent, le point exact qui finit par être exploité.

Ce que je n’arrive toujours pas à visualiser, c’est comment cette rigidité tient dans des situations plus embrouillées : des conditions de « slashing » qui se déclenchent, des timelocks qui expirent, des ensembles de participants qui tournent au cours de la vie d’un vault. L’absence de nouveaux chemins, tout en sachant que le système doit quand même s’adapter, me paraît être en tension. Donc le principe de conception lui-même semble solide, plus conservateur que ce que j’attendais, mais le comportement en cas limite, @BabylonLabs_io ne me l’a pas encore montré en pratique.

#BABY $BABY @BabylonLabs_io #IntelRises9%AfterHours $COTI $ON #USStorageStocksExtendLosses
La sécurité du vault dépend principalement de ?