Récemment, tout le monde dans le secteur discute des mécanismes d’externalisation de troisième partie pour la garde TBV. J’ai effectué deux semaines de tests en conditions réelles des interactions du produit, vérifié ligne par ligne le texte du chapitre VII du livre blanc, et extrait en parallèle des données d’interaction des prestataires de services on-chain. Mes années de pratique de la recherche de données on-chain m’empêchent de tirer des conclusions uniquement sur la base de la communication marketing. À l’heure actuelle, la plupart des projets de coffre-fort Bitcoin transfèrent l’intégralité de la charge de maintenance sur les utilisateurs ordinaires : les seuils liés à des calculs cryptographiques complexes découragent de nombreux détenteurs de BTC. Mes critères d’évaluation reposent toujours sur une mesure objective à trois dimensions : contraintes du code, limites des responsabilités, et chemin de propagation des risques, sans surestimer ni dénigrer un projet en particulier.
@BabylonLabs_io En lisant le chapitre VII, on perçoit clairement que ce système de garde “Keeper” réduit concrètement le coût opérationnel pour permettre aux utilisateurs ordinaires de participer à TBV. En pratique, il suffit de signer localement pour créer un coffre-fort ; l’ensemble des preuves ZK et des scripts de surveillance est exécuté par un prestataire de services tiers. Les frais de règlement sont tous transférés via $BABY . Les droits de rachat des actifs sont figés dans le contrat : le prestataire ne peut pas transférer arbitrairement des BTC. Par rapport à des coffres-forts auto-gérés similaires, cela réduit fortement le niveau de complexité opérationnelle. L’ensemble du cadre technique s’appuie sur le système de preuve BABE développé par Berkeley afin de comprimer les coûts de calcul ; des appareils mobiles ordinaires peuvent ainsi s’intégrer sans difficulté au contrat du coffre-fort.
Cependant, le chapitre VII n’efface pas complètement les risques sous-jacents de l’architecture de base. Le mécanisme est comme une réparation externalisée d’un appareil électroménager : le prestataire ne fait qu’assurer des étapes de calcul, mais il détient les droits de surveillance on-chain sur toute la durée. Le consensus multi-prestataires et multi-signatures ne fait que contraindre les actions de liquidation, sans mettre en place une logique de blocage instantané contre une éventuelle malveillance collective des prestataires. En cas de marché extrême entraînant une forte baisse des BTC, une liquidation par lots peut être déclenchée ; plusieurs prestataires peuvent alors voir leurs nœuds devenir hors ligne et la génération des preuves subir des retards en même temps. Le seuil de collatéral du coffre-fort ne peut pas être synchronisé à temps avec la chaîne, et les BTC des utilisateurs se retrouvent en verrouillage temporaire, incapables d’être rachetés. La chaîne de propagation des risques est claire : les défaillances des nœuds ralentissent progressivement le processus de liquidation, et il n’existe pas de plan de secours rapide. Le livre blanc s’en remet seulement à l’ajustement des critères d’accès des prestataires via la gouvernance des tokens : les votes de gouvernance impliquent un délai, ce qui empêche une prise en charge en temps réel des défaillances imprévues des nœuds.
En me basant sur mon expérience pratique de détention BTC en périodes, les participants ordinaires ne devraient pas se reposer uniquement sur une garde Keeper déléguée à un tiers. Je recommande de combiner avec la création d’un petit coffre-fort BTC simplifié en propre pour couvrir le risque de défaillance des nœuds, de contrôler la proportion d’actifs confiés aux prestataires de service, de vérifier régulièrement les mises à jour du livre blanc et d’archiver en parallèle les preuves de transactions locales, afin de réduire les pertes non maîtrisables dues à de multiples causes. #baby
@BabylonLabs_io En lisant le chapitre VII, on perçoit clairement que ce système de garde “Keeper” réduit concrètement le coût opérationnel pour permettre aux utilisateurs ordinaires de participer à TBV. En pratique, il suffit de signer localement pour créer un coffre-fort ; l’ensemble des preuves ZK et des scripts de surveillance est exécuté par un prestataire de services tiers. Les frais de règlement sont tous transférés via $BABY . Les droits de rachat des actifs sont figés dans le contrat : le prestataire ne peut pas transférer arbitrairement des BTC. Par rapport à des coffres-forts auto-gérés similaires, cela réduit fortement le niveau de complexité opérationnelle. L’ensemble du cadre technique s’appuie sur le système de preuve BABE développé par Berkeley afin de comprimer les coûts de calcul ; des appareils mobiles ordinaires peuvent ainsi s’intégrer sans difficulté au contrat du coffre-fort.
Cependant, le chapitre VII n’efface pas complètement les risques sous-jacents de l’architecture de base. Le mécanisme est comme une réparation externalisée d’un appareil électroménager : le prestataire ne fait qu’assurer des étapes de calcul, mais il détient les droits de surveillance on-chain sur toute la durée. Le consensus multi-prestataires et multi-signatures ne fait que contraindre les actions de liquidation, sans mettre en place une logique de blocage instantané contre une éventuelle malveillance collective des prestataires. En cas de marché extrême entraînant une forte baisse des BTC, une liquidation par lots peut être déclenchée ; plusieurs prestataires peuvent alors voir leurs nœuds devenir hors ligne et la génération des preuves subir des retards en même temps. Le seuil de collatéral du coffre-fort ne peut pas être synchronisé à temps avec la chaîne, et les BTC des utilisateurs se retrouvent en verrouillage temporaire, incapables d’être rachetés. La chaîne de propagation des risques est claire : les défaillances des nœuds ralentissent progressivement le processus de liquidation, et il n’existe pas de plan de secours rapide. Le livre blanc s’en remet seulement à l’ajustement des critères d’accès des prestataires via la gouvernance des tokens : les votes de gouvernance impliquent un délai, ce qui empêche une prise en charge en temps réel des défaillances imprévues des nœuds.
En me basant sur mon expérience pratique de détention BTC en périodes, les participants ordinaires ne devraient pas se reposer uniquement sur une garde Keeper déléguée à un tiers. Je recommande de combiner avec la création d’un petit coffre-fort BTC simplifié en propre pour couvrir le risque de défaillance des nœuds, de contrôler la proportion d’actifs confiés aux prestataires de service, de vérifier régulièrement les mises à jour du livre blanc et d’archiver en parallèle les preuves de transactions locales, afin de réduire les pertes non maîtrisables dues à de multiples causes. #baby
