#baby J’ai récemment regardé le TBV de @BabylonLabs_io .
Ensuite, j’ai cessé de m’acharner sur le dépôt.
Je me suis plutôt concentré sur ce qui se passe après la disparition du Provider.
La réponse se cache dans la paire de clés WOTS et les artefacts du claimer.
Lors de la création du Vault.
L’utilisateur reçoit une clé de signature à usage unique.
Ainsi qu’un ensemble complet de transactions pré-signées et de données de défi.
En temps normal, ces éléments ressemblent à de simples pièces techniques.
Mais en cas de vrai problème, ils pourraient bien être la seule sortie.
Le Provider du Vault est en ligne.
Il peut aider l’utilisateur à effectuer le Claim, l’Assert et le Payout.
Le Provider ne répond plus.
En théorie, l’utilisateur peut toujours exécuter l’outil en ligne de commande, en suivant le chemin de transactions prédéfini, pour récupérer $BTC vers l’adresse d’origine.
Ça ressemble à quelque chose de très sans confiance.
Mais j’ai tout de suite pensé à un scénario plus réaliste.
Le Provider se déconnecte.
Et l’ancien ordinateur de l’utilisateur tombe aussi en panne.
Les fichiers WOTS n’existent que sur l’appareil d’origine.
Aucune sauvegarde hors ligne des éléments de récupération n’a été faite.
À ce moment-là, le protocole ne retient pas les actifs.
Le script n’empêche pas non plus de sortir.
Pourtant, l’utilisateur peut quand même se trouver juste devant la sortie… sans trouver la clé pour ouvrir la porte.
Donc « sans l’approbation de l’opérateur » n’est que la première étape.
La prochaine, c’est de rendre la récupération autonome réellement accessible aux utilisateurs ordinaires.
Les données que je veux voir sont très simples.
Combien d’utilisateurs ont sauvegardé les éléments.
Quel est le taux de réussite du Self-Claim.
Combien de temps faut-il pour une récupération complète.
À quelle étape l’échec se produit principalement.
Le récit d’infrastructure de $BABY peut être très vaste.
Mais la maturité du TBV ne peut pas se juger uniquement au nombre de dépôts réussis de $BTC .
Le vrai test de résistance, c’est : quand tous les rôles qui aident ne sont plus en ligne, est-ce que l’utilisateur peut emporter les actifs au complet, uniquement grâce aux fichiers qu’il a lui-même conservés.
#baby
Ensuite, j’ai cessé de m’acharner sur le dépôt.
Je me suis plutôt concentré sur ce qui se passe après la disparition du Provider.
La réponse se cache dans la paire de clés WOTS et les artefacts du claimer.
Lors de la création du Vault.
L’utilisateur reçoit une clé de signature à usage unique.
Ainsi qu’un ensemble complet de transactions pré-signées et de données de défi.
En temps normal, ces éléments ressemblent à de simples pièces techniques.
Mais en cas de vrai problème, ils pourraient bien être la seule sortie.
Le Provider du Vault est en ligne.
Il peut aider l’utilisateur à effectuer le Claim, l’Assert et le Payout.
Le Provider ne répond plus.
En théorie, l’utilisateur peut toujours exécuter l’outil en ligne de commande, en suivant le chemin de transactions prédéfini, pour récupérer $BTC vers l’adresse d’origine.
Ça ressemble à quelque chose de très sans confiance.
Mais j’ai tout de suite pensé à un scénario plus réaliste.
Le Provider se déconnecte.
Et l’ancien ordinateur de l’utilisateur tombe aussi en panne.
Les fichiers WOTS n’existent que sur l’appareil d’origine.
Aucune sauvegarde hors ligne des éléments de récupération n’a été faite.
À ce moment-là, le protocole ne retient pas les actifs.
Le script n’empêche pas non plus de sortir.
Pourtant, l’utilisateur peut quand même se trouver juste devant la sortie… sans trouver la clé pour ouvrir la porte.
Donc « sans l’approbation de l’opérateur » n’est que la première étape.
La prochaine, c’est de rendre la récupération autonome réellement accessible aux utilisateurs ordinaires.
Les données que je veux voir sont très simples.
Combien d’utilisateurs ont sauvegardé les éléments.
Quel est le taux de réussite du Self-Claim.
Combien de temps faut-il pour une récupération complète.
À quelle étape l’échec se produit principalement.
Le récit d’infrastructure de $BABY peut être très vaste.
Mais la maturité du TBV ne peut pas se juger uniquement au nombre de dépôts réussis de $BTC .
Le vrai test de résistance, c’est : quand tous les rôles qui aident ne sont plus en ligne, est-ce que l’utilisateur peut emporter les actifs au complet, uniquement grâce aux fichiers qu’il a lui-même conservés.
#baby