Techno BNB
16.4k Publications
Techno BNB
Compte Square Vérifié+Content Creator | Researcher | Strategy Architect 🌟
Détenteur pour XPL
Trade régulièrement
4.6 an(s)
1.5K+ Suivis
52.9K+ Abonnés
34.9K+ J’aime
Publications
Tous
Citations
Direct
PINNED
Vérifié
@Dusk ne fait pas de règlement probabiliste.
La plupart des chaînes que j’ai utilisées traitent la finalité comme un intervalle de confiance. Plus vous attendez, plus vous vous sentez en sécurité. Six confirmations sur Bitcoin… Douze sur Ethereum. Le bloc est probablement final. « Probablement » n’est pas un mot que les marchés financiers utilisent bien.
Dusk a construit quelque chose de différent.
Un règlement déterministe signifie qu’une transaction est finale dès que le protocole indique qu’elle l’est. Pas probablement final. Pas économiquement final. Final. Cela vient de l’Attestation succincte, où un comité sélectionné aléatoirement valide des blocs via une sélection pondérée par le capital mis en jeu. Une fois validé, le règlement est irréversible sans attaquer l’ensemble de la couche de staking.
Pour la DeFi standard, la finalité probabiliste est gérable. Une réorganisation coûte de l’argent. Quelqu’un peut perdre des fonds. Le système absorbe le risque. Pour les valeurs mobilières réglementées, les obligations ou les fonds monétaires (MMF) qui circulent onchain via Dusk Trade, ce risque est inacceptable. Un règlement de transaction ne peut pas être « dé-réglé » parce qu’une chaîne plus longue est apparue. Un transfert d’obligation ne peut pas être inversé parce qu’un validateur a changé d’avis.
Moonlight gère les comptes publics. Phoenix gère les transactions privées. DuskVM exécute la logique. Mais c’est le règlement déterministe qui rend les trois utilisables pour la finance. La confidentialité sans finalité de règlement n’est qu’une incertitude dissimulée. La transparence sans irréversibilité n’est qu’une base de données plus lente.
Le point « qu’on tait » est que le règlement déterministe est plus difficile à construire qu’un consensus rapide. Il faut des comités, de l’aléa, du staking et un protocole qui refuse de se contredire. Dusk a choisi la voie la plus difficile parce que les marchés réglementés ne peuvent pas fonctionner avec de la probabilité.
Ce choix d’ingénierie pourrait compter davantage que les fonctionnalités de confidentialité dont tout le monde parle en premier.
#dusk $DUSK @Dusk
La plupart des chaînes que j’ai utilisées traitent la finalité comme un intervalle de confiance. Plus vous attendez, plus vous vous sentez en sécurité. Six confirmations sur Bitcoin… Douze sur Ethereum. Le bloc est probablement final. « Probablement » n’est pas un mot que les marchés financiers utilisent bien.
Dusk a construit quelque chose de différent.
Un règlement déterministe signifie qu’une transaction est finale dès que le protocole indique qu’elle l’est. Pas probablement final. Pas économiquement final. Final. Cela vient de l’Attestation succincte, où un comité sélectionné aléatoirement valide des blocs via une sélection pondérée par le capital mis en jeu. Une fois validé, le règlement est irréversible sans attaquer l’ensemble de la couche de staking.
Pour la DeFi standard, la finalité probabiliste est gérable. Une réorganisation coûte de l’argent. Quelqu’un peut perdre des fonds. Le système absorbe le risque. Pour les valeurs mobilières réglementées, les obligations ou les fonds monétaires (MMF) qui circulent onchain via Dusk Trade, ce risque est inacceptable. Un règlement de transaction ne peut pas être « dé-réglé » parce qu’une chaîne plus longue est apparue. Un transfert d’obligation ne peut pas être inversé parce qu’un validateur a changé d’avis.
Moonlight gère les comptes publics. Phoenix gère les transactions privées. DuskVM exécute la logique. Mais c’est le règlement déterministe qui rend les trois utilisables pour la finance. La confidentialité sans finalité de règlement n’est qu’une incertitude dissimulée. La transparence sans irréversibilité n’est qu’une base de données plus lente.
Le point « qu’on tait » est que le règlement déterministe est plus difficile à construire qu’un consensus rapide. Il faut des comités, de l’aléa, du staking et un protocole qui refuse de se contredire. Dusk a choisi la voie la plus difficile parce que les marchés réglementés ne peuvent pas fonctionner avec de la probabilité.
Ce choix d’ingénierie pourrait compter davantage que les fonctionnalités de confidentialité dont tout le monde parle en premier.
#dusk $DUSK @Dusk
PINNED
Vérifié
#dusk $DUSK @Dusk
J’ai supposé que le partenariat NPEX était un communiqué de presse.
Un autre échange. Une autre intégration d’écosystème. Un autre titre pour combler l’écart entre les annonces. J’en ai vu assez pour les considérer comme une dynamique marketing plutôt qu’un changement structurel.
Il s’est avéré que c’était tout autre chose.
NPEX n’est pas une plateforme d’échange crypto qui expérimente la tokenisation. C’est une plateforme d’échange réglementée par la AFM, agréée comme plateforme de négociation multilatérale, courtier et ECSP. Elle fonctionne déjà sous le droit financier de l’UE. Le partenariat prévoit d’amener plus de 300 millions d’EUR d’actifs onchain via Dusk. Pas de tokens enveloppés. Pas de pilotes expérimentaux. Des instruments réglementés existants qui passent sur une blockchain de couche 1 conçue pour cette transition.
Cela change ma façon de penser l’adoption des actifs du monde réel. Je pensais auparavant que la tokenisation commencerait par des entreprises natives de la crypto convainquant TradFi d’expérimenter. Ici, c’est l’inverse : une institution réglementée, qui opère déjà, choisit Dusk comme infrastructure. La direction s’est inversée. L’institution n’entre pas dans la crypto. C’est l’infrastructure qui entre dans l’institution.
Mais la tension est bien réelle. Les bourses réglementées avancent lentement. Les revues de conformité prennent des mois. L’onboarding des actifs nécessite des cadres juridiques que des smart contracts ne peuvent pas imposer à eux seuls. Dusk doit prouver que son infrastructure peut atteindre les standards opérationnels d’un lieu réglementé par l’AFM, sans compromettre le règlement déterministe et la confidentialité programmable qui la définissent.
Je suis encore en train d’évaluer si une bourse réglementée qui prévoit de déplacer 300 millions d’EUR onchain valide la technologie ou teste ses limites. Le chiffre est précis. L’engagement est public. Reste à voir l’exécution.
Une blockchain conçue pour la confidentialité peut-elle gérer les exigences de transparence d’un MTF réglementé ?
J’ai supposé que le partenariat NPEX était un communiqué de presse.
Un autre échange. Une autre intégration d’écosystème. Un autre titre pour combler l’écart entre les annonces. J’en ai vu assez pour les considérer comme une dynamique marketing plutôt qu’un changement structurel.
Il s’est avéré que c’était tout autre chose.
NPEX n’est pas une plateforme d’échange crypto qui expérimente la tokenisation. C’est une plateforme d’échange réglementée par la AFM, agréée comme plateforme de négociation multilatérale, courtier et ECSP. Elle fonctionne déjà sous le droit financier de l’UE. Le partenariat prévoit d’amener plus de 300 millions d’EUR d’actifs onchain via Dusk. Pas de tokens enveloppés. Pas de pilotes expérimentaux. Des instruments réglementés existants qui passent sur une blockchain de couche 1 conçue pour cette transition.
Cela change ma façon de penser l’adoption des actifs du monde réel. Je pensais auparavant que la tokenisation commencerait par des entreprises natives de la crypto convainquant TradFi d’expérimenter. Ici, c’est l’inverse : une institution réglementée, qui opère déjà, choisit Dusk comme infrastructure. La direction s’est inversée. L’institution n’entre pas dans la crypto. C’est l’infrastructure qui entre dans l’institution.
Mais la tension est bien réelle. Les bourses réglementées avancent lentement. Les revues de conformité prennent des mois. L’onboarding des actifs nécessite des cadres juridiques que des smart contracts ne peuvent pas imposer à eux seuls. Dusk doit prouver que son infrastructure peut atteindre les standards opérationnels d’un lieu réglementé par l’AFM, sans compromettre le règlement déterministe et la confidentialité programmable qui la définissent.
Je suis encore en train d’évaluer si une bourse réglementée qui prévoit de déplacer 300 millions d’EUR onchain valide la technologie ou teste ses limites. Le chiffre est précis. L’engagement est public. Reste à voir l’exécution.
Une blockchain conçue pour la confidentialité peut-elle gérer les exigences de transparence d’un MTF réglementé ?
Vérifié
Je m’attendais à ce que le trade @Dusk fonctionne comme une plateforme de trading DeFi.
Des pools de liquidité. Des market makers automatisés. Un listing permissionless où n’importe qui peut créer une paire de trading. Le manuel DeFi standard que j’ai vu sur chaque chaîne EVM. J’ai supposé que l’angle RWA signifiait qu’on allait envelopper des actifs traditionnels et les intégrer dans la même infrastructure.
En réalité, il s’est avéré que c’était tout autre chose...
Dusk Trade est un néocourtier (neobroker). Il est conçu pour fonctionner comme une plateforme d’investissement et un Multilateral Trading Facility (MTF) régulé, dans le cadre des réglementations européennes applicables. Il ne liste pas des tokens aléatoires pour du trading spéculatif. Il apporte à Dusk des fonds du marché monétaire, des ETF, des obligations et des actifs du monde réel, avec une structure qui met l’accent sur la propriété réelle, le règlement instantané et une composabilité de niveau DeFi, le tout dans un cadre de conformité.
Cela change ma façon de penser l’intersection entre la finance traditionnelle et la blockchain. Je pensais auparavant que l’objectif était de reproduire des produits TradFi sur des rails DeFi. Dusk Trade semble faire l’inverse. Il prend des mécanismes DeFi comme le règlement instantané et la composabilité, et les applique à des instruments régulés qui existent déjà. La partie permissionless ne concerne pas la question de qui peut lister. Elle concerne celle de qui peut vérifier la propriété et régler instantanément.
Mais la tension est bien réelle. Les MTF régulés ont des gardiens. Des exigences KYC. Des participants autorisés. La culture DeFi traite cela comme des obstacles. Dusk Trade les considère comme des fonctionnalités, parce que les actifs qu’il gère nécessitent des structures de propriété légale que des pools anonymes ne peuvent pas prendre en charge.
Je suis encore en train de déterminer si les institutions verront Dusk Trade comme de la DeFi avec garde-fous, ou comme de la TradFi avec un règlement meilleur. La technologie est la même. C’est le cadrage qui détermine qui se présente.
La composabilité régulée reste-t-elle de la composabilité si vous avez besoin d’une autorisation pour participer ?
#dusk
$DUSK
@Dusk
Des pools de liquidité. Des market makers automatisés. Un listing permissionless où n’importe qui peut créer une paire de trading. Le manuel DeFi standard que j’ai vu sur chaque chaîne EVM. J’ai supposé que l’angle RWA signifiait qu’on allait envelopper des actifs traditionnels et les intégrer dans la même infrastructure.
En réalité, il s’est avéré que c’était tout autre chose...
Dusk Trade est un néocourtier (neobroker). Il est conçu pour fonctionner comme une plateforme d’investissement et un Multilateral Trading Facility (MTF) régulé, dans le cadre des réglementations européennes applicables. Il ne liste pas des tokens aléatoires pour du trading spéculatif. Il apporte à Dusk des fonds du marché monétaire, des ETF, des obligations et des actifs du monde réel, avec une structure qui met l’accent sur la propriété réelle, le règlement instantané et une composabilité de niveau DeFi, le tout dans un cadre de conformité.
Cela change ma façon de penser l’intersection entre la finance traditionnelle et la blockchain. Je pensais auparavant que l’objectif était de reproduire des produits TradFi sur des rails DeFi. Dusk Trade semble faire l’inverse. Il prend des mécanismes DeFi comme le règlement instantané et la composabilité, et les applique à des instruments régulés qui existent déjà. La partie permissionless ne concerne pas la question de qui peut lister. Elle concerne celle de qui peut vérifier la propriété et régler instantanément.
Mais la tension est bien réelle. Les MTF régulés ont des gardiens. Des exigences KYC. Des participants autorisés. La culture DeFi traite cela comme des obstacles. Dusk Trade les considère comme des fonctionnalités, parce que les actifs qu’il gère nécessitent des structures de propriété légale que des pools anonymes ne peuvent pas prendre en charge.
Je suis encore en train de déterminer si les institutions verront Dusk Trade comme de la DeFi avec garde-fous, ou comme de la TradFi avec un règlement meilleur. La technologie est la même. C’est le cadrage qui détermine qui se présente.
La composabilité régulée reste-t-elle de la composabilité si vous avez besoin d’une autorisation pour participer ?
#dusk
$DUSK
@Dusk
Je pensais que DuskEVM n’était qu’une autre blockchain compatible EVM.
Des contrats Solidity. Des outils familiers. La compatibilité avec MetaMask. Le discours standard que chaque nouvel acteur de couche 1 utilise pour attirer les développeurs. Je pensais que l’angle « confidentialité » serait une fonctionnalité annexe, peut-être une norme de jetons protégés ou un mixeur optionnel. Quelque chose qu’on active seulement quand on en a besoin.
En réalité, c’était l’architecture elle-même.
Hedger n’est pas un plugin. C’est le module de confidentialité de DuskEVM. Il utilise le chiffrement homomorphique pour effectuer des calculs sur des données chiffrées sans les déchiffrer au préalable. Des preuves à divulgation nulle de connaissance vérifient que le calcul était correct sans révéler les entrées. Le résultat est un flux de travail EVM confidentiel où les montants des transactions et l’identité des participants restent invisibles au regard du public, tout en restant consultables pour des parties autorisées comme les régulateurs ou les auditeurs.
Cela change ce que je pensais de la façon de construire sur Dusk. Je pensais que les développeurs écriraient du Solidity « normal » puis ajouteraient la confidentialité plus tard. Je commence à penser qu’ils écriront du Solidity confidentiel dès le départ, parce que la confidentialité n’est pas un ajout. C’est l’environnement par défaut. La compatibilité EVM est le pont qui les y amène. La confidentialité, c’est ce qui les fait rester.
Mais l’échange, c’est la complexité. Le chiffrement homomorphique est coûteux en calcul. La génération de preuves à divulgation nulle ajoute de la latence. Un transfert ERC-20 standard se confirme en quelques secondes. Un transfert confidentiel se confirme lorsque la preuve est vérifiée. L’expérience développeur est familière en termes de syntaxe, mais inconnue en termes de performances.
Je suis encore en train de déterminer si les institutions accepteront une exécution confidentielle plus lente en échange d’une conformité réglementaire intégrée à la chaîne, ou si elles préféreront une exécution publique rapide, avec la conformité gérée hors chaîne.
La confidentialité en vaut-elle le coût en performance, puisque le régulateur regarde déjà ?
#dusk $DUSK @Dusk
Des contrats Solidity. Des outils familiers. La compatibilité avec MetaMask. Le discours standard que chaque nouvel acteur de couche 1 utilise pour attirer les développeurs. Je pensais que l’angle « confidentialité » serait une fonctionnalité annexe, peut-être une norme de jetons protégés ou un mixeur optionnel. Quelque chose qu’on active seulement quand on en a besoin.
En réalité, c’était l’architecture elle-même.
Hedger n’est pas un plugin. C’est le module de confidentialité de DuskEVM. Il utilise le chiffrement homomorphique pour effectuer des calculs sur des données chiffrées sans les déchiffrer au préalable. Des preuves à divulgation nulle de connaissance vérifient que le calcul était correct sans révéler les entrées. Le résultat est un flux de travail EVM confidentiel où les montants des transactions et l’identité des participants restent invisibles au regard du public, tout en restant consultables pour des parties autorisées comme les régulateurs ou les auditeurs.
Cela change ce que je pensais de la façon de construire sur Dusk. Je pensais que les développeurs écriraient du Solidity « normal » puis ajouteraient la confidentialité plus tard. Je commence à penser qu’ils écriront du Solidity confidentiel dès le départ, parce que la confidentialité n’est pas un ajout. C’est l’environnement par défaut. La compatibilité EVM est le pont qui les y amène. La confidentialité, c’est ce qui les fait rester.
Mais l’échange, c’est la complexité. Le chiffrement homomorphique est coûteux en calcul. La génération de preuves à divulgation nulle ajoute de la latence. Un transfert ERC-20 standard se confirme en quelques secondes. Un transfert confidentiel se confirme lorsque la preuve est vérifiée. L’expérience développeur est familière en termes de syntaxe, mais inconnue en termes de performances.
Je suis encore en train de déterminer si les institutions accepteront une exécution confidentielle plus lente en échange d’une conformité réglementaire intégrée à la chaîne, ou si elles préféreront une exécution publique rapide, avec la conformité gérée hors chaîne.
La confidentialité en vaut-elle le coût en performance, puisque le régulateur regarde déjà ?
#dusk $DUSK @Dusk
$XRP observe une hausse de l’activité des dérivés alors que le open interest (intérêt ouvert) de Binance grimpe à 435,1 millions de XRP, au-dessus de sa moyenne sur 30 jours de 403,6 millions. Cette progression signale un positionnement plus lourd et un recours accru à l’effet de levier, même si elle ne confirme pas encore si les traders parient sur une hausse ou une baisse.
Dans le même temps, le XRP est resté bloqué autour de la fourchette de 1,00 à 1,02 $, montrant que l’augmentation de l’activité sur les contrats à terme ne s’est pas encore traduite par une cassure décisive au comptant. Si l’intérêt ouvert continue d’augmenter tandis que le prix faiblit, le risque de liquidation pourrait s’accroître. À l’inverse, une tendance durable à la hausse accompagnée d’un intérêt ouvert élevé renforcerait la configuration haussière.
L’activité des baleines apporte un autre signal intéressant. Les données de Santiment indiquent que le nombre de portefeuilles du XRP Ledger détenant plus d’1 million de XRP a augmenté de 32, même si la capitalisation de XRP a diminué. Cela suggère que les détenteurs les plus importants pourraient accumuler malgré la faiblesse actuelle.
Le volume des transactions sur XRP a atteint environ 905 millions de dollars sur les dernières 24 heures, tandis que le jeton a reculé de 1,76 % et de plus de 6 % sur la semaine...
Avec la montée du positionnement sur les dérivés et l’accumulation par de gros détenteurs, le XRP pourrait s’approcher d’une expansion de la volatilité. La question clé à présent est de savoir si les acheteurs peuvent transformer cette accumulation grandissante en un mouvement durable au-dessus de la zone des 1,02 $.
$XRP #xrp
Dans le même temps, le XRP est resté bloqué autour de la fourchette de 1,00 à 1,02 $, montrant que l’augmentation de l’activité sur les contrats à terme ne s’est pas encore traduite par une cassure décisive au comptant. Si l’intérêt ouvert continue d’augmenter tandis que le prix faiblit, le risque de liquidation pourrait s’accroître. À l’inverse, une tendance durable à la hausse accompagnée d’un intérêt ouvert élevé renforcerait la configuration haussière.
L’activité des baleines apporte un autre signal intéressant. Les données de Santiment indiquent que le nombre de portefeuilles du XRP Ledger détenant plus d’1 million de XRP a augmenté de 32, même si la capitalisation de XRP a diminué. Cela suggère que les détenteurs les plus importants pourraient accumuler malgré la faiblesse actuelle.
Le volume des transactions sur XRP a atteint environ 905 millions de dollars sur les dernières 24 heures, tandis que le jeton a reculé de 1,76 % et de plus de 6 % sur la semaine...
Avec la montée du positionnement sur les dérivés et l’accumulation par de gros détenteurs, le XRP pourrait s’approcher d’une expansion de la volatilité. La question clé à présent est de savoir si les acheteurs peuvent transformer cette accumulation grandissante en un mouvement durable au-dessus de la zone des 1,02 $.
$XRP #xrp
@BabylonLabs_io J’ai observé des coffres Bitcoin sans confiance (TBV) depuis l’angle du dépôt, d’abord.
Verrouillez le BTC natif. Empruntez contre lui. Le coffre détient le Bitcoin. Le prêt se fait ailleurs. Cela paraît sécurisé, mais c’est la métrique facile.
Le problème le plus difficile se trouve à la sortie.
Chaque marché de prêt a une condition de liquidation. Si la valeur de la garantie descend sous un seuil, la position doit se fermer. Sur une chaîne normale, le contrat intelligent saisit et vend automatiquement la garantie. Le code s’exécute en quelques secondes. Le prêteur est protégé immédiatement.
Avec TBV, la garantie est sur Bitcoin. Le contrat de prêt est sur une autre chaîne. Le coffre ne peut pas forcer une transaction Bitcoin instantanément. Bitcoin produit un bloc toutes les dix minutes. Le signal de liquidation doit traverser la frontière de chaîne. Le client léger vérifie l’état. La preuve de travail confirme. L’intervalle entre la baisse du prix et la saisie de la garantie n’est pas mesuré en secondes. Il est mesuré en blocs.
Un certain délai est normal. La coordination inter-chaînes ne peut pas dépasser la physique.
Mais le vrai test, c’est le cas limite. Si le prix de Bitcoin baisse fortement, le temps de bloc de dix minutes devient un passif. L’emprunteur sait que la garantie est en danger avant que le coffre puisse agir. L’écart crée une fenêtre. Un pont déplacerait la garantie instantanément et accepterait le risque de contrepartie. TBV conserve la garantie native et accepte le risque de timing. Aucun des deux modèles n’élimine le problème. Ils ne font que le transformer en une autre forme.
Je pense que TBV peut rendre la garantie sécurisée. Je suis moins sûr qu’il puisse rendre la garantie réactive sans créer un autre mécanisme qui, lui-même, introduit de la confiance.
Une garantie que l’on ne peut pas liquider immédiatement reste-t-elle une garantie ?
@BabylonLabs_io
$BABY
#baby
Verrouillez le BTC natif. Empruntez contre lui. Le coffre détient le Bitcoin. Le prêt se fait ailleurs. Cela paraît sécurisé, mais c’est la métrique facile.
Le problème le plus difficile se trouve à la sortie.
Chaque marché de prêt a une condition de liquidation. Si la valeur de la garantie descend sous un seuil, la position doit se fermer. Sur une chaîne normale, le contrat intelligent saisit et vend automatiquement la garantie. Le code s’exécute en quelques secondes. Le prêteur est protégé immédiatement.
Avec TBV, la garantie est sur Bitcoin. Le contrat de prêt est sur une autre chaîne. Le coffre ne peut pas forcer une transaction Bitcoin instantanément. Bitcoin produit un bloc toutes les dix minutes. Le signal de liquidation doit traverser la frontière de chaîne. Le client léger vérifie l’état. La preuve de travail confirme. L’intervalle entre la baisse du prix et la saisie de la garantie n’est pas mesuré en secondes. Il est mesuré en blocs.
Un certain délai est normal. La coordination inter-chaînes ne peut pas dépasser la physique.
Mais le vrai test, c’est le cas limite. Si le prix de Bitcoin baisse fortement, le temps de bloc de dix minutes devient un passif. L’emprunteur sait que la garantie est en danger avant que le coffre puisse agir. L’écart crée une fenêtre. Un pont déplacerait la garantie instantanément et accepterait le risque de contrepartie. TBV conserve la garantie native et accepte le risque de timing. Aucun des deux modèles n’élimine le problème. Ils ne font que le transformer en une autre forme.
Je pense que TBV peut rendre la garantie sécurisée. Je suis moins sûr qu’il puisse rendre la garantie réactive sans créer un autre mécanisme qui, lui-même, introduit de la confiance.
Une garantie que l’on ne peut pas liquider immédiatement reste-t-elle une garantie ?
@BabylonLabs_io
$BABY
#baby
Vérifié
J’ai supposé que le langage de script de Bitcoin était une faiblesse.
De toutes les autres chaînes que j’utilise, elles ont des smart contracts. Une logique complexe. Des environnements Turing-complets où les développeurs construisent directement sur la chaîne des ponts, des coffres et des marchés de prêt. Bitcoin n’a pas cela. Son langage de script est volontairement limité. Quelques opcodes. Pas de boucles. Pas d’état. Je l’ai toujours vu comme une fonctionnalité manquante.
Puis j’ai lu pourquoi Babylon a construit des Trustless Bitcoin Vaults (TBV).
Babylon ne pouvait pas construire un pont même s’il l’avait voulu. Les ponts ont besoin de smart contracts des deux côtés. Verrouiller des garanties sur une chaîne. Émettre des représentations sur une autre. Vérifier les signatures et les transitions d’état de manière programmée. Le script de Bitcoin ne peut pas héberger cette logique. Il ne peut pas valider une preuve provenant d’une autre chaîne. Il ne peut pas conserver des fonds conditionnellement en fonction d’événements externes. La limitation est architecturale, pas temporaire.
Alors Babylon a cessé d’essayer de faire exécuter Bitcoin. Il a fait en sorte que Bitcoin vérifie plutôt.
TBV n’exécute pas de code sur Bitcoin. Il le lit. Le client léger BTC suit les en-têtes de Bitcoin. Les vigilants portent les données. Les coffres utilisent les contraintes de script natives de Bitcoin pour verrouiller les garanties, et la logique complexe est gérée de l’autre côté par Babylon Genesis. Bitcoin reste simple. Babylon fait le gros du travail.
Cela change ma façon de voir le rôle de Bitcoin dans la DeFi. Je pensais auparavant que Bitcoin devait devenir plus programmable pour être compétitif. Babylon traite sa simplicité comme une fonctionnalité de sécurité. Un script simple est difficile à exploiter. Une machine à états simple est facile à vérifier. Une chaîne qui ne peut pas évoluer est une chaîne que vous pouvez de confiance.
Mais le compromis est réel. Chaque interaction avec TBV avance lentement parce que Bitcoin avance lentement. Des blocs de dix minutes. Babylon ne peut pas rendre Bitcoin plus rapide ou plus intelligent. Il ne peut que construire autour des contraintes.
Je suis encore en train de déterminer si le refus de Bitcoin d’évoluer est de l’entêtement ou de la sagesse. Toutes les autres chaînes poursuivent des fonctionnalités. Bitcoin les a retirées. Babylon a construit une couche d’infrastructure entière à cause de ce que Bitcoin ne fera pas.
La limitation est-elle la sécurité ultime ?
@BabylonLabs_io $BABY
#baby
De toutes les autres chaînes que j’utilise, elles ont des smart contracts. Une logique complexe. Des environnements Turing-complets où les développeurs construisent directement sur la chaîne des ponts, des coffres et des marchés de prêt. Bitcoin n’a pas cela. Son langage de script est volontairement limité. Quelques opcodes. Pas de boucles. Pas d’état. Je l’ai toujours vu comme une fonctionnalité manquante.
Puis j’ai lu pourquoi Babylon a construit des Trustless Bitcoin Vaults (TBV).
Babylon ne pouvait pas construire un pont même s’il l’avait voulu. Les ponts ont besoin de smart contracts des deux côtés. Verrouiller des garanties sur une chaîne. Émettre des représentations sur une autre. Vérifier les signatures et les transitions d’état de manière programmée. Le script de Bitcoin ne peut pas héberger cette logique. Il ne peut pas valider une preuve provenant d’une autre chaîne. Il ne peut pas conserver des fonds conditionnellement en fonction d’événements externes. La limitation est architecturale, pas temporaire.
Alors Babylon a cessé d’essayer de faire exécuter Bitcoin. Il a fait en sorte que Bitcoin vérifie plutôt.
TBV n’exécute pas de code sur Bitcoin. Il le lit. Le client léger BTC suit les en-têtes de Bitcoin. Les vigilants portent les données. Les coffres utilisent les contraintes de script natives de Bitcoin pour verrouiller les garanties, et la logique complexe est gérée de l’autre côté par Babylon Genesis. Bitcoin reste simple. Babylon fait le gros du travail.
Cela change ma façon de voir le rôle de Bitcoin dans la DeFi. Je pensais auparavant que Bitcoin devait devenir plus programmable pour être compétitif. Babylon traite sa simplicité comme une fonctionnalité de sécurité. Un script simple est difficile à exploiter. Une machine à états simple est facile à vérifier. Une chaîne qui ne peut pas évoluer est une chaîne que vous pouvez de confiance.
Mais le compromis est réel. Chaque interaction avec TBV avance lentement parce que Bitcoin avance lentement. Des blocs de dix minutes. Babylon ne peut pas rendre Bitcoin plus rapide ou plus intelligent. Il ne peut que construire autour des contraintes.
Je suis encore en train de déterminer si le refus de Bitcoin d’évoluer est de l’entêtement ou de la sagesse. Toutes les autres chaînes poursuivent des fonctionnalités. Bitcoin les a retirées. Babylon a construit une couche d’infrastructure entière à cause de ce que Bitcoin ne fera pas.
La limitation est-elle la sécurité ultime ?
@BabylonLabs_io $BABY
#baby
Vérifié
J’ai supposé que @BabylonLabs_io regardais Bitcoin directement.
Il s’est avéré qu’il fallait des observateurs pour les observateurs.
Le client léger BTC à l’intérieur des coffres Bitcoin sans confiance (TBV) lit les en-têtes de blocs de Bitcoin. Il vérifie la preuve de travail. Il suit la chaîne la plus longue. Mais le client léger ne se connecte pas directement à Bitcoin. Il réside sur Babylon Genesis, séparé du réseau Bitcoin. Quelqu’un doit transporter les en-têtes.
Cette personne, c’est le réseau Vigilante.
J’ai supposé que les vigilantes étaient des validateurs avec une tâche supplémentaire. Ce n’est pas le cas. Ce sont des reporters qui surveillent Bitcoin et soumettent des en-têtes à Babylon. Ils observent et ils se font concurrence. Plusieurs vigilantes peuvent soumettre le même en-tête. Genesis valide le travail, pas le travailleur. Le système ne fait pas confiance au messager. Il vérifie le message.
Cela change à nouveau le modèle de confiance. Babylon supprime l’opérateur de pont. Il supprime le comité multisig. Mais il a encore besoin de porteurs de données. Les vigilantes sont le dernier maillon humain d’une chaîne conçue pour éliminer les maillons humains. Ils sont nécessaires, mais non dignes de confiance. S’ils disparaissent, le client léger se bloque. S’ils mentent, la vérification de la preuve de travail les trahit.
Je suis encore en train de déterminer si un système qui a besoin d’observateurs est vraiment sans confiance, ou s’il a simplement déplacé la confiance vers une autre couche.
La cryptographie est solide. La question est de savoir si suffisamment de participants veulent transporter les données.
Que se passe-t-il quand personne ne veut regarder ?
@BabylonLabs_io $BABY
#baby
Il s’est avéré qu’il fallait des observateurs pour les observateurs.
Le client léger BTC à l’intérieur des coffres Bitcoin sans confiance (TBV) lit les en-têtes de blocs de Bitcoin. Il vérifie la preuve de travail. Il suit la chaîne la plus longue. Mais le client léger ne se connecte pas directement à Bitcoin. Il réside sur Babylon Genesis, séparé du réseau Bitcoin. Quelqu’un doit transporter les en-têtes.
Cette personne, c’est le réseau Vigilante.
J’ai supposé que les vigilantes étaient des validateurs avec une tâche supplémentaire. Ce n’est pas le cas. Ce sont des reporters qui surveillent Bitcoin et soumettent des en-têtes à Babylon. Ils observent et ils se font concurrence. Plusieurs vigilantes peuvent soumettre le même en-tête. Genesis valide le travail, pas le travailleur. Le système ne fait pas confiance au messager. Il vérifie le message.
Cela change à nouveau le modèle de confiance. Babylon supprime l’opérateur de pont. Il supprime le comité multisig. Mais il a encore besoin de porteurs de données. Les vigilantes sont le dernier maillon humain d’une chaîne conçue pour éliminer les maillons humains. Ils sont nécessaires, mais non dignes de confiance. S’ils disparaissent, le client léger se bloque. S’ils mentent, la vérification de la preuve de travail les trahit.
Je suis encore en train de déterminer si un système qui a besoin d’observateurs est vraiment sans confiance, ou s’il a simplement déplacé la confiance vers une autre couche.
La cryptographie est solide. La question est de savoir si suffisamment de participants veulent transporter les données.
Que se passe-t-il quand personne ne veut regarder ?
@BabylonLabs_io $BABY
#baby
J’ai passé une heure à essayer de comprendre pourquoi Babylon s’intéresse au temps de bloc de Bitcoin.
Je pensais que les époques n’étaient que de la planification. Une façon de diviser le travail en manches. Les ensembles de validateurs tournent. Les récompenses se distribuent à intervalles réguliers. Des mécanismes standard du SDK Cosmos. Rien de spécifique à Bitcoin.
Puis j’ai lu comment Babylon les utilise réellement.
Babylon ne fait pas confiance à sa propre horloge. Il fait confiance à celle de Bitcoin. La logique d’époque pulse sur le rythme du battement de dix minutes de Bitcoin. Quand Bitcoin produit un bloc, le rythme avance. Quand Bitcoin ralentit, le système attend. La logique de coordination emprunte le sens du temps de Bitcoin.
Cela change ce que je pensais du temps inter-chaînes. La plupart des protocoles utilisent des horodatages locaux ou des flux d’oracles. Babylon utilise l’horloge la plus difficile à manipuler dans la crypto. Vous ne pouvez pas falsifier un bloc Bitcoin. Vous ne pouvez pas l’accélérer. Vous ne pouvez pas le remonter en arrière sans réécrire l’historique du proof-of-work.
Pour les Trustless Bitcoin Vaults (TBV), cela compte plus que je ne l’avais prévu. Le coffre a besoin de savoir quand les garanties sont verrouillées, quand les fenêtres s’ouvrent, quand les règlements sont finalisés. Il pourrait s’appuyer sur l’heure locale du Genesis. Au lieu de cela, il utilise le temps de Bitcoin. L’événement lié aux garanties et l’événement d’époque partagent la même ancre immuable.
Mais le compromis, c’est la rigidité. Bitcoin ne se soucie pas de votre urgence. Blocs de dix minutes. Six confirmations. Le calendrier suit le rythme de Bitcoin, pas le vôtre. Babylon sacrifie la flexibilité à l’immutabilité.
Je suis encore en train de déterminer si les utilisateurs remarqueront que Babylon fonctionne à l’heure de Bitcoin, pas à l’heure d’internet. La différence est invisible tant que ça compte.
J’ai passé une heure sur les époques. Maintenant je ne peux plus ignorer l’horloge.
Le temps de bloc de Bitcoin est-il la fonctionnalité de sécurité la plus sous-estimée ?
@BabylonLabs_io
$BABY
#baby
Je pensais que les époques n’étaient que de la planification. Une façon de diviser le travail en manches. Les ensembles de validateurs tournent. Les récompenses se distribuent à intervalles réguliers. Des mécanismes standard du SDK Cosmos. Rien de spécifique à Bitcoin.
Puis j’ai lu comment Babylon les utilise réellement.
Babylon ne fait pas confiance à sa propre horloge. Il fait confiance à celle de Bitcoin. La logique d’époque pulse sur le rythme du battement de dix minutes de Bitcoin. Quand Bitcoin produit un bloc, le rythme avance. Quand Bitcoin ralentit, le système attend. La logique de coordination emprunte le sens du temps de Bitcoin.
Cela change ce que je pensais du temps inter-chaînes. La plupart des protocoles utilisent des horodatages locaux ou des flux d’oracles. Babylon utilise l’horloge la plus difficile à manipuler dans la crypto. Vous ne pouvez pas falsifier un bloc Bitcoin. Vous ne pouvez pas l’accélérer. Vous ne pouvez pas le remonter en arrière sans réécrire l’historique du proof-of-work.
Pour les Trustless Bitcoin Vaults (TBV), cela compte plus que je ne l’avais prévu. Le coffre a besoin de savoir quand les garanties sont verrouillées, quand les fenêtres s’ouvrent, quand les règlements sont finalisés. Il pourrait s’appuyer sur l’heure locale du Genesis. Au lieu de cela, il utilise le temps de Bitcoin. L’événement lié aux garanties et l’événement d’époque partagent la même ancre immuable.
Mais le compromis, c’est la rigidité. Bitcoin ne se soucie pas de votre urgence. Blocs de dix minutes. Six confirmations. Le calendrier suit le rythme de Bitcoin, pas le vôtre. Babylon sacrifie la flexibilité à l’immutabilité.
Je suis encore en train de déterminer si les utilisateurs remarqueront que Babylon fonctionne à l’heure de Bitcoin, pas à l’heure d’internet. La différence est invisible tant que ça compte.
J’ai passé une heure sur les époques. Maintenant je ne peux plus ignorer l’horloge.
Le temps de bloc de Bitcoin est-il la fonctionnalité de sécurité la plus sous-estimée ?
@BabylonLabs_io
$BABY
#baby
Yes immutable time underrated
60%
No, speed matters more
20%
Only for financial settlements
20%
I had not thought about it
0%
5 Votes • Vote fermé
J’ai supposé que @BabylonLabs_io avait besoin de Bitcoin pour la sécurité.
Il en a aussi besoin pour la mémoire.
La plupart des protocoles inter-chaînes traitent le Bitcoin comme un coffre. Un endroit pour verrouiller de la valeur. Une source de poids économique. Babylon fait de même. Les Trustless Bitcoin Vaults (TBV) utilisent le BTC natif comme garantie. La valeur est réelle. La garantie est native.
Mais il existe une deuxième fonction. Moins visible. Tout aussi importante.
Le Bitcoin est un serveur d’horodatage.
Babylon enregistre (checkpointe) l’état des chaînes PoS « grand public » sur le réseau Bitcoin. Pas pour la valeur. Pour le temps. Une fois qu’un checkpoint est enfoui sous la preuve de travail de Bitcoin, le bloc PoS hérite d’un horodatage qui ne peut pas être réécrit sans réécrire Bitcoin lui-même. La chaîne « consommatrice » peut se réorganiser. Ses validateurs peuvent changer d’avis. Mais le checkpoint qui a été écrit dans Bitcoin reste écrit.
Ce n’est pas une question de vitesse. C’est une question de permanence.
Le Finality Gadget fournit une finalité rapide par rapport au risque de réorganisation (reorg) de la chaîne consommatrice. Le checkpointing fournit une finalité permanente par rapport à l’historique de Bitcoin. L’un est rapide. L’autre est pour toujours. Les deux utilisent le même actif sous-jacent. Aucun ne déplace le BTC hors de sa chaîne.
Je reviens sans cesse à cette distinction. La plupart des protocoles empruntent la valeur du Bitcoin. Babylon emprunte le temps du Bitcoin.
Est-ce une revendication plus grande que la garantie ?
@BabylonLabs_io $BABY
#baby
Il en a aussi besoin pour la mémoire.
La plupart des protocoles inter-chaînes traitent le Bitcoin comme un coffre. Un endroit pour verrouiller de la valeur. Une source de poids économique. Babylon fait de même. Les Trustless Bitcoin Vaults (TBV) utilisent le BTC natif comme garantie. La valeur est réelle. La garantie est native.
Mais il existe une deuxième fonction. Moins visible. Tout aussi importante.
Le Bitcoin est un serveur d’horodatage.
Babylon enregistre (checkpointe) l’état des chaînes PoS « grand public » sur le réseau Bitcoin. Pas pour la valeur. Pour le temps. Une fois qu’un checkpoint est enfoui sous la preuve de travail de Bitcoin, le bloc PoS hérite d’un horodatage qui ne peut pas être réécrit sans réécrire Bitcoin lui-même. La chaîne « consommatrice » peut se réorganiser. Ses validateurs peuvent changer d’avis. Mais le checkpoint qui a été écrit dans Bitcoin reste écrit.
Ce n’est pas une question de vitesse. C’est une question de permanence.
Le Finality Gadget fournit une finalité rapide par rapport au risque de réorganisation (reorg) de la chaîne consommatrice. Le checkpointing fournit une finalité permanente par rapport à l’historique de Bitcoin. L’un est rapide. L’autre est pour toujours. Les deux utilisent le même actif sous-jacent. Aucun ne déplace le BTC hors de sa chaîne.
Je reviens sans cesse à cette distinction. La plupart des protocoles empruntent la valeur du Bitcoin. Babylon emprunte le temps du Bitcoin.
Est-ce une revendication plus grande que la garantie ?
@BabylonLabs_io $BABY
#baby
Je sais ce que Babylone a construit. Je suis moins sûr de savoir pour qui il le construit.
Les coffres-forts Bitcoin sans confiance (TBV) constituent l’infrastructure. Le modèle est clair. Les chaînes plus petites obtiennent la sécurité de Bitcoin. Bitcoin acquiert une nouvelle utilité. Babylone se place au milieu.
Mais l’infrastructure et l’adoption ne suivent pas les mêmes calendriers.
Je pensais que l’écosystème des chaînes “consommatrices” serait visible en parallèle de l’infrastructure. Je ne l’ai pas encore vu. La documentation décrit l’architecture. Elle ne cite pas les chaînes qui s’y sont engagées. Le testnet montre les mécanismes. Il ne démontre pas une chaîne consommatrice en production, utilisée en conditions réelles.
Cela peut être une question de timing. L’infrastructure d’abord, les intégrations ensuite. Ou bien le fait de convaincre une chaîne de sous-traiter sa sécurité est peut-être plus difficile que de construire les conduites. Les chaînes ont leurs propres économies et leur propre souveraineté. S’appuyer sur une infrastructure externe revient à admettre que leur propre système a besoin d’une sauvegarde.
Je travaille encore pour déterminer si le plus grand défi de Babylone est technique ou social. L’infrastructure fonctionne. La question est de savoir si les chaînes veulent ce qu’elles vendent.
Qui, selon vous, devrait utiliser en premier la sécurité de Bitcoin ?
@BabylonLabs_io
$BABY
#baby
Les coffres-forts Bitcoin sans confiance (TBV) constituent l’infrastructure. Le modèle est clair. Les chaînes plus petites obtiennent la sécurité de Bitcoin. Bitcoin acquiert une nouvelle utilité. Babylone se place au milieu.
Mais l’infrastructure et l’adoption ne suivent pas les mêmes calendriers.
Je pensais que l’écosystème des chaînes “consommatrices” serait visible en parallèle de l’infrastructure. Je ne l’ai pas encore vu. La documentation décrit l’architecture. Elle ne cite pas les chaînes qui s’y sont engagées. Le testnet montre les mécanismes. Il ne démontre pas une chaîne consommatrice en production, utilisée en conditions réelles.
Cela peut être une question de timing. L’infrastructure d’abord, les intégrations ensuite. Ou bien le fait de convaincre une chaîne de sous-traiter sa sécurité est peut-être plus difficile que de construire les conduites. Les chaînes ont leurs propres économies et leur propre souveraineté. S’appuyer sur une infrastructure externe revient à admettre que leur propre système a besoin d’une sauvegarde.
Je travaille encore pour déterminer si le plus grand défi de Babylone est technique ou social. L’infrastructure fonctionne. La question est de savoir si les chaînes veulent ce qu’elles vendent.
Qui, selon vous, devrait utiliser en premier la sécurité de Bitcoin ?
@BabylonLabs_io
$BABY
#baby
Vérifié
Babylon a des validateurs. Personne n’en parle.
Les titres mentionnent le staking de Bitcoin.. Le marketing évoque des Trustless Bitcoin Vaults (TBV). La documentation explique le client léger, le gadget de finalité et le système de checkpointing. Mais la chaîne qui coordonne tout cela, Babylon Genesis, est traitée comme un bruit de fond.
Babylon Genesis est une chaîne Cosmos SDK. Elle a son propre ensemble de validateurs, ses propres époques et sa propre gouvernance. Elle ne sécurise pas Bitcoin. Elle se situe entre Bitcoin et les chaînes consommatrices qui empruntent la sécurité de Bitcoin. Les validateurs produisent des blocs Genesis qui transportent des checkpoints et une logique de coordination. Les chaînes consommatrices se connectent à Genesis. Genesis se connecte à Bitcoin.
J’ai supposé que Babylon était un protocole construit au-dessus de chaînes existantes. Je commence à penser que c’est une chaîne sur laquelle d’autres chaînes se construisent. La sécurité circule de Bitcoin vers Genesis puis vers les chaînes consommatrices. La coordination circule en retour. Cela signifie que la santé de Genesis compte. Si Genesis cale, le checkpointing cale. Si l’ensemble des validateurs est concentré, la coordination est concentrée. La preuve de travail de Bitcoin est toujours là. Mais le chemin entre Bitcoin et la chaîne consommatrice passe par Genesis.
Je suis encore en train de déterminer si les utilisateurs voient cette couche intermédiaire comme une fonctionnalité ou comme une dépendance. La sécurité de Bitcoin est réelle. La coordination de Genesis est nécessaire. Les deux doivent fonctionner pour que le système fonctionne. Mais l’un des deux seulement fait l’objet de discussions.
Que savez-vous de la chaîne au milieu ?
@BabylonLabs_io
$BABY
#baby
Les titres mentionnent le staking de Bitcoin.. Le marketing évoque des Trustless Bitcoin Vaults (TBV). La documentation explique le client léger, le gadget de finalité et le système de checkpointing. Mais la chaîne qui coordonne tout cela, Babylon Genesis, est traitée comme un bruit de fond.
Babylon Genesis est une chaîne Cosmos SDK. Elle a son propre ensemble de validateurs, ses propres époques et sa propre gouvernance. Elle ne sécurise pas Bitcoin. Elle se situe entre Bitcoin et les chaînes consommatrices qui empruntent la sécurité de Bitcoin. Les validateurs produisent des blocs Genesis qui transportent des checkpoints et une logique de coordination. Les chaînes consommatrices se connectent à Genesis. Genesis se connecte à Bitcoin.
J’ai supposé que Babylon était un protocole construit au-dessus de chaînes existantes. Je commence à penser que c’est une chaîne sur laquelle d’autres chaînes se construisent. La sécurité circule de Bitcoin vers Genesis puis vers les chaînes consommatrices. La coordination circule en retour. Cela signifie que la santé de Genesis compte. Si Genesis cale, le checkpointing cale. Si l’ensemble des validateurs est concentré, la coordination est concentrée. La preuve de travail de Bitcoin est toujours là. Mais le chemin entre Bitcoin et la chaîne consommatrice passe par Genesis.
Je suis encore en train de déterminer si les utilisateurs voient cette couche intermédiaire comme une fonctionnalité ou comme une dépendance. La sécurité de Bitcoin est réelle. La coordination de Genesis est nécessaire. Les deux doivent fonctionner pour que le système fonctionne. Mais l’un des deux seulement fait l’objet de discussions.
Que savez-vous de la chaîne au milieu ?
@BabylonLabs_io
$BABY
#baby
Connectez-vous pour découvrir plus de contenu