Lorsque j’ai vu dans TBV des rôles comme Vault Provider, Application Vault Keeper, Universal Challenger, etc., je me suis aussi posé au début des questions : puisque le système a toujours besoin de tant d’opérateurs, pourquoi peut-on quand même parler de « non-custodial » ?
Après avoir continué mes recherches, j’ai l’impression que l’essentiel n’est pas de savoir s’il y a des humains impliqués dans le système, mais plutôt ce dont ces personnes disposent réellement comme pouvoir.
Vault Provider est chargé de faciliter le dépôt et le rachat, de générer les preuves et de diffuser les transactions Bitcoin ; Application Vault Keeper participe à la configuration côté application et peut aussi, dans l’intégration à Aave, intervenir dans la liquidation et le règlement ; Universal Challenger surveille en continu les preuves de retrait et empêche les retraits invalides.
Ces rôles peuvent influer sur le caractère opportun du processus, mais ils ne peuvent pas créer à la volée une nouvelle voie de dépense en Bitcoin. La façon dont BTC peut être dirigé a déjà été inscrite dans le script et la structure de signature préétablie au moment de la création du Vault. Même si le Provider interrompt ses services, il ne peut pas rediriger les BTC des utilisateurs vers sa propre adresse ; les utilisateurs peuvent aussi s’appuyer sur les éléments conservés pour déclencher eux-mêmes le retrait.
Cela m’a amené à redéfinir ma compréhension de la « décentralisation sans confiance » : ce n’est pas que le système n’a plus besoin d’opérateurs, mais plutôt que les opérateurs ne sont plus des contrôleurs d’actifs, seulement des exécutants de services.
Un bon protocole ne devrait pas supposer que tous les prestataires resteront toujours honnêtes en ligne ; il devrait par défaut considérer qu’une partie d’entre eux va se déconnecter, se tromper ou même agir mal, puis limiter les pires conséquences qu’ils pourraient provoquer.
Ainsi, lorsque j’observe la structure des participants de TBV, je ne me focalise pas seulement sur le nombre de rôles, mais surtout sur ce que chaque rôle peut faire et ne peut pas faire, et sur la possibilité pour l’utilisateur de le remplacer si ce rôle devient défaillant. Tant que le pouvoir a des limites, c’est plus important que de réduire simplement le nombre de nœuds. #baby $BABY @BabylonLabs_io
Après avoir continué mes recherches, j’ai l’impression que l’essentiel n’est pas de savoir s’il y a des humains impliqués dans le système, mais plutôt ce dont ces personnes disposent réellement comme pouvoir.
Vault Provider est chargé de faciliter le dépôt et le rachat, de générer les preuves et de diffuser les transactions Bitcoin ; Application Vault Keeper participe à la configuration côté application et peut aussi, dans l’intégration à Aave, intervenir dans la liquidation et le règlement ; Universal Challenger surveille en continu les preuves de retrait et empêche les retraits invalides.
Ces rôles peuvent influer sur le caractère opportun du processus, mais ils ne peuvent pas créer à la volée une nouvelle voie de dépense en Bitcoin. La façon dont BTC peut être dirigé a déjà été inscrite dans le script et la structure de signature préétablie au moment de la création du Vault. Même si le Provider interrompt ses services, il ne peut pas rediriger les BTC des utilisateurs vers sa propre adresse ; les utilisateurs peuvent aussi s’appuyer sur les éléments conservés pour déclencher eux-mêmes le retrait.
Cela m’a amené à redéfinir ma compréhension de la « décentralisation sans confiance » : ce n’est pas que le système n’a plus besoin d’opérateurs, mais plutôt que les opérateurs ne sont plus des contrôleurs d’actifs, seulement des exécutants de services.
Un bon protocole ne devrait pas supposer que tous les prestataires resteront toujours honnêtes en ligne ; il devrait par défaut considérer qu’une partie d’entre eux va se déconnecter, se tromper ou même agir mal, puis limiter les pires conséquences qu’ils pourraient provoquer.
Ainsi, lorsque j’observe la structure des participants de TBV, je ne me focalise pas seulement sur le nombre de rôles, mais surtout sur ce que chaque rôle peut faire et ne peut pas faire, et sur la possibilité pour l’utilisateur de le remplacer si ce rôle devient défaillant. Tant que le pouvoir a des limites, c’est plus important que de réduire simplement le nombre de nœuds. #baby $BABY @BabylonLabs_io
