@BabylonLabs_io
Je lisais la section « whitepaper » de Babylon sur les caractéristiques des coffres, et une petite phrase m’a stoppé net : « pre-set claimer ». Au premier abord, cela ressemblait simplement à une exigence technique : l’ensemble des parties autorisées à réclamer et à retirer le bitcoin doit être défini dès le moment où le coffre est créé. Mais plus j’y pensais, plus j’avais l’impression qu’il s’agissait d’un choix de conception discret qui change tout en ce qui concerne qui peut même tenter de toucher aux fonds.
Ce qui semble intéressant, c’est ce que cela exclut en réalité. Personne en dehors de cet ensemble prédéfini ne peut soumettre une réclamation, pas même avec une preuve ingénieuse ou une faille technique : le coffre ne les reconnaîtra tout simplement pas comme éligibles. Cela me fait penser que cela réduit la surface d’attaque avant même que la cryptographie n’entre en jeu, presque comme retirer des portes supplémentaires d’un bâtiment plutôt que d’ajouter de meilleurs verrous à ceux qui existent déjà.
Cela dit, je n’ai pas totalement la certitude que ce soit dénué de compromis. Verrouiller l’ensemble des « claimer » dès la création signifie qu’il y a peu de place pour la flexibilité plus tard : que se passe-t-il si les circonstances changent, si une relation de prêt évolue, ou si une clé de claimer est compromise au fil du temps ? La rigidité qui rend cela sécurisé le rend-elle aussi, dans une certaine mesure, moins souple que des systèmes qui permettent un autorisation dynamique ?
Vu de l’extérieur, cela donne l’impression que Babylon a choisi la prévisibilité plutôt que l’adaptabilité, en pariant qu’une surface d’attaque plus petite et fixe vaut plus que la flexibilité dont la plupart des utilisateurs n’auront peut-être jamais besoin. La question de savoir si cette hypothèse se vérifie à mesure que des produits DeFi plus complexes s’appuient sur TBV, je ne peux pas encore l’évaluer pleinement. Peut-être que c’est le vrai test à venir... bref, le temps nous dira 👍
$BROCCOLIF3B
$ON
$BABY
#baby
Je lisais la section « whitepaper » de Babylon sur les caractéristiques des coffres, et une petite phrase m’a stoppé net : « pre-set claimer ». Au premier abord, cela ressemblait simplement à une exigence technique : l’ensemble des parties autorisées à réclamer et à retirer le bitcoin doit être défini dès le moment où le coffre est créé. Mais plus j’y pensais, plus j’avais l’impression qu’il s’agissait d’un choix de conception discret qui change tout en ce qui concerne qui peut même tenter de toucher aux fonds.
Ce qui semble intéressant, c’est ce que cela exclut en réalité. Personne en dehors de cet ensemble prédéfini ne peut soumettre une réclamation, pas même avec une preuve ingénieuse ou une faille technique : le coffre ne les reconnaîtra tout simplement pas comme éligibles. Cela me fait penser que cela réduit la surface d’attaque avant même que la cryptographie n’entre en jeu, presque comme retirer des portes supplémentaires d’un bâtiment plutôt que d’ajouter de meilleurs verrous à ceux qui existent déjà.
Cela dit, je n’ai pas totalement la certitude que ce soit dénué de compromis. Verrouiller l’ensemble des « claimer » dès la création signifie qu’il y a peu de place pour la flexibilité plus tard : que se passe-t-il si les circonstances changent, si une relation de prêt évolue, ou si une clé de claimer est compromise au fil du temps ? La rigidité qui rend cela sécurisé le rend-elle aussi, dans une certaine mesure, moins souple que des systèmes qui permettent un autorisation dynamique ?
Vu de l’extérieur, cela donne l’impression que Babylon a choisi la prévisibilité plutôt que l’adaptabilité, en pariant qu’une surface d’attaque plus petite et fixe vaut plus que la flexibilité dont la plupart des utilisateurs n’auront peut-être jamais besoin. La question de savoir si cette hypothèse se vérifie à mesure que des produits DeFi plus complexes s’appuient sur TBV, je ne peux pas encore l’évaluer pleinement. Peut-être que c’est le vrai test à venir... bref, le temps nous dira 👍
$BROCCOLIF3B
$ON
$BABY
#baby