Je détiens @BabylonLabs_io SCRIPT que j’ai moi-même publié, et j’ai passé en revue les paramètres du réseau de test TBV. Le plus intéressant, c’est qu’il est écrit d’un côté « la durée de vie des garanties ne doit pas être soumise à autorisation », tandis qu’en même temps il liste clairement un seuil d’urgence de 3/5 pour le Security Council.
Ce n’est pas forcément contradictoire, mais c’est justement la “faille” qui permet de tester la vraie valeur du “trustless”.
SCRIPT exige six points : le respect de la souveraineté de l’utilisateur, des règles de gestion claires, l’interdiction de remettre en nantissement sans consentement, l’isolement de chaque position, l’impossibilité pour un tiers de procéder à une vérification, et la transparence de l’état des garanties. C’est comme une liste de contrôle pour un coffre-fort : à qui appartiennent les clés, dans quelles conditions on peut ouvrir, est-ce qu’on peut utiliser le contenu pour un deuxième nantissement, les coffres sont-ils mélangés, qui peut bloquer l’accès à l’autre, et peut-on vérifier de l’extérieur si l’on peut retrouver les informations.
Pour l’isolement et la transparence, TBV a une approche très claire : chaque utilisateur conserve son BTC dans un Bitcoin Vault indépendant, et une application externe peut vérifier l’état, sans mélanger toutes les pièces dans une réserve de garde unique. Or les paramètres du réseau de test publics indiquent aussi que le Security Council est composé de 5 sièges, et que 3 signatures suffisent pour exécuter une intervention d’urgence du type CouncilNoPayout.
Il faut ici tracer une ligne nette : 3/5 correspond aux paramètres du réseau de test public, et on ne peut pas en déduire directement que le réseau principal fera la même chose. Puisque la réponse du réseau principal ne peut pas être confirmée à partir de cette page de paramètres, il faut surtout considérer la composition du comité et toute évolution des droits comme des éléments à observer sur le long terme, plutôt que comme une conclusion à injecter au projet.
Je reconnais qu’un frein d’urgence a une valeur réelle en période de test. Le nouveau système implique des scripts Bitcoin, de la coordination hors chaîne et des contrats Ethereum. Lorsqu’un grave dysfonctionnement est découvert, il n’y a peut-être absolument aucun bouton d’arrêt. Ce n’est pas forcément moins sûr que s’il n’y avait pas de bouton. Le vrai point, c’est que dès qu’il existe un bouton, il faut continuer à poser les questions : qui sont les membres, dans quelles conditions peut-on appuyer, si l’action est-elle retardée et si elle est publiée de façon transparente, et si l’utilisateur dispose d’un chemin de sortie qui ne dépend pas du comité.
C’est aussi l’endroit que le $BABY gouvernance devrait vraiment surveiller. Pas de se dire que, parce qu’on voit “gouvernance communautaire” écrit quelque part, les permissions sont forcément réparties. Il faut regarder, dans le réseau principal à venir, quels pouvoirs d’urgence seront conservés, qui pourra ajuster le seuil, et si chaque action peut être retracée on-chain. Le #baby qui détient et vote n’investit pas dans une vision abstraite, mais dans des limites de droits concrètes.
Mon avis : le comité d’urgence peut être une barrière de sécurité pendant la phase de construction, mais il ne peut pas reposer indéfiniment sur une phrase du type « c’est pour la sécurité, donc on ne vérifie pas ». Vérifiez d’abord par vous-même. Acceptez-vous un frein 3/5 qui est échangé contre la capacité de répondre aux pannes, ou pensez-vous qu’un système sans autorisation ne devrait pas conserver cette porte principale ? Dites-le en commentaire, et analysons point par point.
Ce n’est pas forcément contradictoire, mais c’est justement la “faille” qui permet de tester la vraie valeur du “trustless”.
SCRIPT exige six points : le respect de la souveraineté de l’utilisateur, des règles de gestion claires, l’interdiction de remettre en nantissement sans consentement, l’isolement de chaque position, l’impossibilité pour un tiers de procéder à une vérification, et la transparence de l’état des garanties. C’est comme une liste de contrôle pour un coffre-fort : à qui appartiennent les clés, dans quelles conditions on peut ouvrir, est-ce qu’on peut utiliser le contenu pour un deuxième nantissement, les coffres sont-ils mélangés, qui peut bloquer l’accès à l’autre, et peut-on vérifier de l’extérieur si l’on peut retrouver les informations.
Pour l’isolement et la transparence, TBV a une approche très claire : chaque utilisateur conserve son BTC dans un Bitcoin Vault indépendant, et une application externe peut vérifier l’état, sans mélanger toutes les pièces dans une réserve de garde unique. Or les paramètres du réseau de test publics indiquent aussi que le Security Council est composé de 5 sièges, et que 3 signatures suffisent pour exécuter une intervention d’urgence du type CouncilNoPayout.
Il faut ici tracer une ligne nette : 3/5 correspond aux paramètres du réseau de test public, et on ne peut pas en déduire directement que le réseau principal fera la même chose. Puisque la réponse du réseau principal ne peut pas être confirmée à partir de cette page de paramètres, il faut surtout considérer la composition du comité et toute évolution des droits comme des éléments à observer sur le long terme, plutôt que comme une conclusion à injecter au projet.
Je reconnais qu’un frein d’urgence a une valeur réelle en période de test. Le nouveau système implique des scripts Bitcoin, de la coordination hors chaîne et des contrats Ethereum. Lorsqu’un grave dysfonctionnement est découvert, il n’y a peut-être absolument aucun bouton d’arrêt. Ce n’est pas forcément moins sûr que s’il n’y avait pas de bouton. Le vrai point, c’est que dès qu’il existe un bouton, il faut continuer à poser les questions : qui sont les membres, dans quelles conditions peut-on appuyer, si l’action est-elle retardée et si elle est publiée de façon transparente, et si l’utilisateur dispose d’un chemin de sortie qui ne dépend pas du comité.
C’est aussi l’endroit que le $BABY gouvernance devrait vraiment surveiller. Pas de se dire que, parce qu’on voit “gouvernance communautaire” écrit quelque part, les permissions sont forcément réparties. Il faut regarder, dans le réseau principal à venir, quels pouvoirs d’urgence seront conservés, qui pourra ajuster le seuil, et si chaque action peut être retracée on-chain. Le #baby qui détient et vote n’investit pas dans une vision abstraite, mais dans des limites de droits concrètes.
Mon avis : le comité d’urgence peut être une barrière de sécurité pendant la phase de construction, mais il ne peut pas reposer indéfiniment sur une phrase du type « c’est pour la sécurité, donc on ne vérifie pas ». Vérifiez d’abord par vous-même. Acceptez-vous un frein 3/5 qui est échangé contre la capacité de répondre aux pannes, ou pensez-vous qu’un système sans autorisation ne devrait pas conserver cette porte principale ? Dites-le en commentaire, et analysons point par point.
