En fouillant les documents de “Babylon” jusqu’à une heure tardive, je voulais juste vérifier les limites des droits de l’exécutant du règlement. Mais à force de creuser, je suis devenu plus lucide à cause d’un point : dépôt et retrait ne reposent pas du tout sur la même logique de confiance
Au début, je pensais que tout le modèle de confiance du système de coffre-fort était unifié. En avançant, j’ai découvert que du côté du dépôt, il faut obtenir l’accord d’une multitude de personnes, tandis que les logiques de retrait et de règlement sont totalement différentes
Pour le dépôt, il faut “solliciter” les autres. Lors de la création du coffre-fort, tu dois soumettre une requête Peg-In sur Ethereum, accompagnée d’un secret de verrouillage par hachage (hash lock) que seul toi connais. Ensuite, tu diffuses sur le réseau Bitcoin une transaction Pre-PegIn, en verrouillant les BTC dans une adresse Taproot associée au hash lock. Là, les vraies complications commencent : tu dois, en hors-chaîne, construire avec le Vault Provider et l’AVK le schéma de transaction pré-signée, et chaque participant doit signer. Ce n’est qu’après que le déposant révèle le secret du hash lock que le coffre-fort est officiellement activé
Pour le retrait et le règlement, la logique est complètement différente. Le retrait passe par le chemin de pré-signature : lors de la création du coffre-fort, tous les chemins de sortie valides ont déjà été pré-signés ; une fois le coffre généré, personne ne peut fabriquer une nouvelle sortie. Au moment du retrait, le déposant diffuse directement la transaction à partir des clés utilisées lors de la création, sans qu’aucune autre partie ait besoin de coopérer.
Côté règlement, le déclencheur est que le facteur de santé de l’emprunteur passe sous 1.0. Il existe deux chemins : avec permission et sans permission. Mais quel que soit le chemin, les règles sont déjà “codées” au moment de la création du coffre-fort : il n’y a pas besoin que l’exécutant du règlement demande une approbation à quelqu’un.
Une phrase du document m’a fait m’arrêter : « Trust is optional and removable ». Le dépôt nécessite une participation multi-acteurs, parce que le coffre-fort n’est pas encore construit : la relation de confiance est encore en cours de construction — il faut que le Vault Provider pilote la configuration, que l’AVK signe conjointement, et que les Universal Challengers témoignent. Mais une fois le coffre-fort établi et le schéma de transactions pré-signées figé, tu n’as plus besoin de dépendre d’aucun tiers.
J’ai passé une nuit entière à vérifier : je n’ai pas fini d’examiner les droits de l’exécutant du règlement, mais je me suis plutôt laissé “piéger” par la différence de confiance entre dépôt et retrait. Pourtant, une fois que j’ai compris, je trouve ça logique : demander à faire le dépôt est nécessaire parce que la confiance n’est pas encore établie ; pour le retrait et le règlement, ne pas demander, c’est parce que la confiance a déjà été verrouillée dans le code. Tu trouves que cette conception — dépendance aux humains pendant la phase de construction, puis dépendance uniquement au code une fois mature — est ingénieuse ou superflue ? Discutons-en dans les commentaires.
#BABY $BABY @BabylonLabs_io
Au début, je pensais que tout le modèle de confiance du système de coffre-fort était unifié. En avançant, j’ai découvert que du côté du dépôt, il faut obtenir l’accord d’une multitude de personnes, tandis que les logiques de retrait et de règlement sont totalement différentes
Pour le dépôt, il faut “solliciter” les autres. Lors de la création du coffre-fort, tu dois soumettre une requête Peg-In sur Ethereum, accompagnée d’un secret de verrouillage par hachage (hash lock) que seul toi connais. Ensuite, tu diffuses sur le réseau Bitcoin une transaction Pre-PegIn, en verrouillant les BTC dans une adresse Taproot associée au hash lock. Là, les vraies complications commencent : tu dois, en hors-chaîne, construire avec le Vault Provider et l’AVK le schéma de transaction pré-signée, et chaque participant doit signer. Ce n’est qu’après que le déposant révèle le secret du hash lock que le coffre-fort est officiellement activé
Pour le retrait et le règlement, la logique est complètement différente. Le retrait passe par le chemin de pré-signature : lors de la création du coffre-fort, tous les chemins de sortie valides ont déjà été pré-signés ; une fois le coffre généré, personne ne peut fabriquer une nouvelle sortie. Au moment du retrait, le déposant diffuse directement la transaction à partir des clés utilisées lors de la création, sans qu’aucune autre partie ait besoin de coopérer.
Côté règlement, le déclencheur est que le facteur de santé de l’emprunteur passe sous 1.0. Il existe deux chemins : avec permission et sans permission. Mais quel que soit le chemin, les règles sont déjà “codées” au moment de la création du coffre-fort : il n’y a pas besoin que l’exécutant du règlement demande une approbation à quelqu’un.
Une phrase du document m’a fait m’arrêter : « Trust is optional and removable ». Le dépôt nécessite une participation multi-acteurs, parce que le coffre-fort n’est pas encore construit : la relation de confiance est encore en cours de construction — il faut que le Vault Provider pilote la configuration, que l’AVK signe conjointement, et que les Universal Challengers témoignent. Mais une fois le coffre-fort établi et le schéma de transactions pré-signées figé, tu n’as plus besoin de dépendre d’aucun tiers.
J’ai passé une nuit entière à vérifier : je n’ai pas fini d’examiner les droits de l’exécutant du règlement, mais je me suis plutôt laissé “piéger” par la différence de confiance entre dépôt et retrait. Pourtant, une fois que j’ai compris, je trouve ça logique : demander à faire le dépôt est nécessaire parce que la confiance n’est pas encore établie ; pour le retrait et le règlement, ne pas demander, c’est parce que la confiance a déjà été verrouillée dans le code. Tu trouves que cette conception — dépendance aux humains pendant la phase de construction, puis dépendance uniquement au code une fois mature — est ingénieuse ou superflue ? Discutons-en dans les commentaires.
#BABY $BABY @BabylonLabs_io