En traduisant la documentation de Babylon, j’ai vu la section du Covenant Committee. Ma première réaction a été : « encore un comité ». Honnêtement, dès qu’un projet on-chain met en place un comité multisig, j’active automatiquement mes mécanismes de défense : c’est tellement facile à emballer comme de la décentralisation, alors que, en réalité, ça peut servir de porte dérobée. Mais ensuite, j’ai repris tout le processus de mise en gage et de retrait, et j’ai réalisé que je n’avais peut-être pas bien compris à quel endroit ça bloque exactement. @BabylonLabs_io
Au terme normal, le rachat ne nécessite aucun signature du comité : si le time-lock a expiré, vous pouvez simplement partir. Le comité intervient sur deux points : le désengagement anticipé et la confiscation / pénalité en cas de mauvaise conduite. Autrement dit, seuls les parcours anormaux passent par eux. Pour un rachat BTC normal, le comité n’a pas le moindre contact.
Pourquoi ce design existe-t-il ? Parce que les scripts Bitcoin sont trop « bêtes ». Vous verrouillez un montant de BTC : si vous voulez partir plus tôt, le réseau Bitcoin principal ne comprend tout simplement pas la notion d’« anticipé ». Il ne sait que : une fois le temps venu, on peut déverrouiller. En fait, ce que fait le comité est assez basique : avec un multisig, on ajoute une couche de chemins d’autorisation pour permettre la « sortie anticipée ». Ce n’est pas une question de « permissions » ; c’est un exécuteur de conditions. Bien sûr, il y a des risques. Si le mécanisme de signature du comité était compromis, on pourrait en théorie signer une fausse transaction de désengagement. Dans la documentation, c’est un multisig 3/5, avec des membres publics. Mais est-ce que ce seuil est suffisant ? Comment les membres sont remplacés ? À l’heure actuelle, il n’y a pas de données d’exécution pour vérifier.
Donc, le Covenant Committee n’est pas une porte dérobée, mais ne le considérez pas non plus comme un design parfaitement décentralisé. C’est plutôt un compromis d’ingénierie dû au fait que le script Bitcoin est trop bête : ça marche, mais ce n’est pas vraiment élégant.
À mon avis, les trois choses qui méritent vraiment d’être regardées sont : premièrement, est-ce que les limites de contrôle vont s’élargir avec les mises à niveau ; deuxièmement, est-ce que la composition des membres va devenir de plus en plus concentrée ; et troisièmement, après amélioration des capacités de scripting de Bitcoin à l’avenir, est-ce que ce système pourra être remplacé. Tant que ces trois questions n’ont pas de réponses, dire que c’est « complètement décentralisé » et dire que c’est une « porte dérobée centralisée » est trop tôt. #baby $BABY
Au terme normal, le rachat ne nécessite aucun signature du comité : si le time-lock a expiré, vous pouvez simplement partir. Le comité intervient sur deux points : le désengagement anticipé et la confiscation / pénalité en cas de mauvaise conduite. Autrement dit, seuls les parcours anormaux passent par eux. Pour un rachat BTC normal, le comité n’a pas le moindre contact.
Pourquoi ce design existe-t-il ? Parce que les scripts Bitcoin sont trop « bêtes ». Vous verrouillez un montant de BTC : si vous voulez partir plus tôt, le réseau Bitcoin principal ne comprend tout simplement pas la notion d’« anticipé ». Il ne sait que : une fois le temps venu, on peut déverrouiller. En fait, ce que fait le comité est assez basique : avec un multisig, on ajoute une couche de chemins d’autorisation pour permettre la « sortie anticipée ». Ce n’est pas une question de « permissions » ; c’est un exécuteur de conditions. Bien sûr, il y a des risques. Si le mécanisme de signature du comité était compromis, on pourrait en théorie signer une fausse transaction de désengagement. Dans la documentation, c’est un multisig 3/5, avec des membres publics. Mais est-ce que ce seuil est suffisant ? Comment les membres sont remplacés ? À l’heure actuelle, il n’y a pas de données d’exécution pour vérifier.
Donc, le Covenant Committee n’est pas une porte dérobée, mais ne le considérez pas non plus comme un design parfaitement décentralisé. C’est plutôt un compromis d’ingénierie dû au fait que le script Bitcoin est trop bête : ça marche, mais ce n’est pas vraiment élégant.
À mon avis, les trois choses qui méritent vraiment d’être regardées sont : premièrement, est-ce que les limites de contrôle vont s’élargir avec les mises à niveau ; deuxièmement, est-ce que la composition des membres va devenir de plus en plus concentrée ; et troisièmement, après amélioration des capacités de scripting de Bitcoin à l’avenir, est-ce que ce système pourra être remplacé. Tant que ces trois questions n’ont pas de réponses, dire que c’est « complètement décentralisé » et dire que c’est une « porte dérobée centralisée » est trop tôt. #baby $BABY
