Dès le départ, ce qui m’a frappé en premier, c’est à quel point le périmètre de la délégation est étroit.
Plus j’y réfléchissais, plus cela me semblait moins relever d’un choix de conception.
Plus précisément, cela ressemblait davantage à quelque chose que le protocole ne pouvait pas éviter.
Accorder à quelqu’un le pouvoir d’emprunter sur votre BTC s’accompagne généralement d’une extension silencieuse de l’autorité.
À terme, cette personne peut toucher davantage d’actifs que prévu.
C’est pour cela que je revenais sans cesse à une question centrale.
Pourquoi Trustless Bitcoin Vaults (TBV) refuse-t-il de laisser cette autorité s’étendre, une fois que c’est fait ?
En regardant de plus près, il m’a semblé que TBV traite la garde et l’autorisation comme deux éléments distincts dès le départ.
Ce n’est pas quelque chose qui s’impose une fois la délégation déjà en cours.
Cela m’a amené à me demander quel est le véritable tournant décisif.
Peut-être que la vraie innovation ne réside pas du tout dans le mécanisme de délégation.
Plutôt, il s’agit du choix de supprimer, dès le départ, le moment où le périmètre pourrait s’élargir.
Une preuve à connaissance nulle de l’état du contrat assure l’application, bien sûr.
Mais, à bien des égards, cela ressemble presque à un point secondaire.
On comprend mieux dès qu’on identifie ce qui est réellement résolu ici.
Il ne s’agit pas tant d’une délégation sûre que de rendre la question de la confiance sans objet avant même qu’elle puisse se poser.
À l’heure actuelle, ce qui reste totalement non résolu, c’est de savoir si cette même rigidité deviendra une limitation plus tard.
Tout figer au moment de la création pourrait poser des problèmes au moment où les systèmes basés sur le BTC devront évoluer après le déploiement.
Avec le temps, cette tension pourrait en dire plus sur la manière de concevoir sur Bitcoin que sur ce que TBV cherchait réellement à révéler.
$BABY #baby @BabylonLabs_io
Plus j’y réfléchissais, plus cela me semblait moins relever d’un choix de conception.
Plus précisément, cela ressemblait davantage à quelque chose que le protocole ne pouvait pas éviter.
Accorder à quelqu’un le pouvoir d’emprunter sur votre BTC s’accompagne généralement d’une extension silencieuse de l’autorité.
À terme, cette personne peut toucher davantage d’actifs que prévu.
C’est pour cela que je revenais sans cesse à une question centrale.
Pourquoi Trustless Bitcoin Vaults (TBV) refuse-t-il de laisser cette autorité s’étendre, une fois que c’est fait ?
En regardant de plus près, il m’a semblé que TBV traite la garde et l’autorisation comme deux éléments distincts dès le départ.
Ce n’est pas quelque chose qui s’impose une fois la délégation déjà en cours.
Cela m’a amené à me demander quel est le véritable tournant décisif.
Peut-être que la vraie innovation ne réside pas du tout dans le mécanisme de délégation.
Plutôt, il s’agit du choix de supprimer, dès le départ, le moment où le périmètre pourrait s’élargir.
Une preuve à connaissance nulle de l’état du contrat assure l’application, bien sûr.
Mais, à bien des égards, cela ressemble presque à un point secondaire.
On comprend mieux dès qu’on identifie ce qui est réellement résolu ici.
Il ne s’agit pas tant d’une délégation sûre que de rendre la question de la confiance sans objet avant même qu’elle puisse se poser.
À l’heure actuelle, ce qui reste totalement non résolu, c’est de savoir si cette même rigidité deviendra une limitation plus tard.
Tout figer au moment de la création pourrait poser des problèmes au moment où les systèmes basés sur le BTC devront évoluer après le déploiement.
Avec le temps, cette tension pourrait en dire plus sur la manière de concevoir sur Bitcoin que sur ce que TBV cherchait réellement à révéler.
$BABY #baby @BabylonLabs_io
