HumairaBTC
228 Publications
HumairaBTC
Signaler
Bloquer l’utilisateur
57 Suivis
679 Abonnés
149 J’aime
Publications
·
--
#dusk $DUSK @Dusk_Foundation J’ai commencé à me poser une question que l’on remet rarement en cause dans la crypto :
À quel moment une transaction est-elle réellement terminée ?
Imaginez l’achat d’un bien immobilier.
L’agent vous dit :
« Votre paiement est passé. »
Mais ensuite il ajoute :
« Il existe une petite chance que la notice de propriété change demain. »
Vous ne qualifieriez probablement pas cela de “régler”.
Pourtant, dans de nombreuses blockchains, “confirmé” et “final” ne signifient pas nécessairement la même chose.
Cette distinction a retenu mon attention lorsque j’ai creusé davantage sur DUSK.
Le consensus de DUSK est conçu autour d’une finalité déterministe.
Une fois qu’un bloc est ratifié, la transaction atteint la finalité plutôt que de rester dans un état où les utilisateurs doivent continuer à attendre des confirmations supplémentaires pour gagner en confiance. DUSK décrit cela comme le fait d’éviter des réorganisations visibles par l’utilisateur en fonctionnement normal.
Cela ressemble à un détail technique.
Mais pour les marchés financiers, je ne pense pas que ce soit le cas.
Imaginez régler une transaction obligataire, transférer la propriété d’un titre, ou mettre à jour un enregistrement financier.
La question importante n’est pas seulement :
« À quelle vitesse la transaction est-elle apparue ? »
C’est :
« À quel point exact tout le monde peut-il considérer ce résultat comme réglé ? »
C’est pourquoi la finalité déterministe me paraît plus pertinente dans le contexte de DUSK.
Il ne s’agit pas seulement de rendre une transaction “rapide” à l’écran...
Il s’agit plutôt de donner au marché un point clair d’absence de retour en arrière.
Car dans la finance, l’incertitude après le règlement n’est pas seulement gênante.
Elle peut engendrer des problèmes de réconciliation, opérationnels et avec les contreparties.
Alors la question qui me reste est :
Si un marché financier ne peut pas vous dire clairement quand une transaction est finale, était-elle vraiment réglée au départ ?
#dusk $DUSK @Dusk_Foundation
#dusk $DUSK @Dusk J’ai commencé à me poser une question que l’on remet rarement en cause dans la crypto :
À quel moment une transaction est-elle réellement terminée ?
Imaginez l’achat d’un bien immobilier.
L’agent vous dit :
« Votre paiement est passé. »
Mais ensuite il ajoute :
« Il existe une petite chance que la notice de propriété change demain. »
Vous ne qualifieriez probablement pas cela de “régler”.
Pourtant, dans de nombreuses blockchains, “confirmé” et “final” ne signifient pas nécessairement la même chose.
Cette distinction a retenu mon attention lorsque j’ai creusé davantage sur DUSK.
Le consensus de DUSK est conçu autour d’une finalité déterministe.
Une fois qu’un bloc est ratifié, la transaction atteint la finalité plutôt que de rester dans un état où les utilisateurs doivent continuer à attendre des confirmations supplémentaires pour gagner en confiance. DUSK décrit cela comme le fait d’éviter des réorganisations visibles par l’utilisateur en fonctionnement normal.
Cela ressemble à un détail technique.
Mais pour les marchés financiers, je ne pense pas que ce soit le cas.
Imaginez régler une transaction obligataire, transférer la propriété d’un titre, ou mettre à jour un enregistrement financier.
La question importante n’est pas seulement :
« À quelle vitesse la transaction est-elle apparue ? »
C’est :
« À quel point exact tout le monde peut-il considérer ce résultat comme réglé ? »
C’est pourquoi la finalité déterministe me paraît plus pertinente dans le contexte de DUSK.
Il ne s’agit pas seulement de rendre une transaction “rapide” à l’écran...
Il s’agit plutôt de donner au marché un point clair d’absence de retour en arrière.
Car dans la finance, l’incertitude après le règlement n’est pas seulement gênante.
Elle peut engendrer des problèmes de réconciliation, opérationnels et avec les contreparties.
Alors la question qui me reste est :
Si un marché financier ne peut pas vous dire clairement quand une transaction est finale, était-elle vraiment réglée au départ ?
#dusk $DUSK @Dusk
À quel moment une transaction est-elle réellement terminée ?
Imaginez l’achat d’un bien immobilier.
L’agent vous dit :
« Votre paiement est passé. »
Mais ensuite il ajoute :
« Il existe une petite chance que la notice de propriété change demain. »
Vous ne qualifieriez probablement pas cela de “régler”.
Pourtant, dans de nombreuses blockchains, “confirmé” et “final” ne signifient pas nécessairement la même chose.
Cette distinction a retenu mon attention lorsque j’ai creusé davantage sur DUSK.
Le consensus de DUSK est conçu autour d’une finalité déterministe.
Une fois qu’un bloc est ratifié, la transaction atteint la finalité plutôt que de rester dans un état où les utilisateurs doivent continuer à attendre des confirmations supplémentaires pour gagner en confiance. DUSK décrit cela comme le fait d’éviter des réorganisations visibles par l’utilisateur en fonctionnement normal.
Cela ressemble à un détail technique.
Mais pour les marchés financiers, je ne pense pas que ce soit le cas.
Imaginez régler une transaction obligataire, transférer la propriété d’un titre, ou mettre à jour un enregistrement financier.
La question importante n’est pas seulement :
« À quelle vitesse la transaction est-elle apparue ? »
C’est :
« À quel point exact tout le monde peut-il considérer ce résultat comme réglé ? »
C’est pourquoi la finalité déterministe me paraît plus pertinente dans le contexte de DUSK.
Il ne s’agit pas seulement de rendre une transaction “rapide” à l’écran...
Il s’agit plutôt de donner au marché un point clair d’absence de retour en arrière.
Car dans la finance, l’incertitude après le règlement n’est pas seulement gênante.
Elle peut engendrer des problèmes de réconciliation, opérationnels et avec les contreparties.
Alors la question qui me reste est :
Si un marché financier ne peut pas vous dire clairement quand une transaction est finale, était-elle vraiment réglée au départ ?
#dusk $DUSK @Dusk
102
·
--
#dusk $DUSK @Dusk_Foundation J’ai commencé à examiner ce qui se passe après l’exécution d’une transaction.
Et j’ai découvert un problème que je n’avais pas vraiment envisagé.
Une blockchain peut savoir qu’une chose s’est produite.
Mais comment le reste du système financier le sait-il ?
Imaginez une bourse où une transaction a lieu à l’intérieur du bâtiment, mais où personne n’envoie un message à la chambre de compensation.
La transaction existe.
Mais les systèmes qui l’entourent attendent encore.
C’est ce qui a rendu le système d’événements RUES de DUSK intéressant à mes yeux.
Les nœuds DUSK peuvent exposer des événements pour des choses comme des blocs acceptés, des transactions incluses ou exécutées, et des événements spécifiques au contrat. Les applications externes peuvent s’abonner à ces événements via des WebSockets au lieu de demander en permanence à la chaîne :
« Quelque chose s’est-il produit ? »
Et il y a un détail important ici.
DUSK prend aussi en charge les données historiques d’événements via des nœuds d’archives et des requêtes GraphQL, y compris les événements finalisés.
Donc ce n’est pas seulement une question de notifications.
Cela crée un pont entre ce qui s’est passé on-chain et les systèmes qui doivent y réagir.
Cela compte bien plus pour l’infrastructure financière que ce que cela peut sembler.
Parce qu’un marché tokenisé n’est pas utile si la blockchain est le seul système à savoir ce qui s’est passé.
Les dépositaires, les bourses, les tableaux de bord, les systèmes de conformité et d’autres infrastructures peuvent tous avoir besoin de réagir au même événement.
Cela m’a fait regarder RUES différemment.
Ce n’est pas la transaction.
C’est le signal qui permet à tout ce qui entoure la transaction de continuer à avancer.
Et maintenant je me demande :
La finance on-chain peut-elle vraiment s’étendre à l’infrastructure financière existante si les systèmes situés en dehors de la chaîne ne peuvent pas réagir de façon fiable à ce qui se passe à l’intérieur ?
#dusk $DUSK @Dusk_Foundation
#dusk $DUSK @Dusk J’ai commencé à examiner ce qui se passe après l’exécution d’une transaction.
Et j’ai découvert un problème que je n’avais pas vraiment envisagé.
Une blockchain peut savoir qu’une chose s’est produite.
Mais comment le reste du système financier le sait-il ?
Imaginez une bourse où une transaction a lieu à l’intérieur du bâtiment, mais où personne n’envoie un message à la chambre de compensation.
La transaction existe.
Mais les systèmes qui l’entourent attendent encore.
C’est ce qui a rendu le système d’événements RUES de DUSK intéressant à mes yeux.
Les nœuds DUSK peuvent exposer des événements pour des choses comme des blocs acceptés, des transactions incluses ou exécutées, et des événements spécifiques au contrat. Les applications externes peuvent s’abonner à ces événements via des WebSockets au lieu de demander en permanence à la chaîne :
« Quelque chose s’est-il produit ? »
Et il y a un détail important ici.
DUSK prend aussi en charge les données historiques d’événements via des nœuds d’archives et des requêtes GraphQL, y compris les événements finalisés.
Donc ce n’est pas seulement une question de notifications.
Cela crée un pont entre ce qui s’est passé on-chain et les systèmes qui doivent y réagir.
Cela compte bien plus pour l’infrastructure financière que ce que cela peut sembler.
Parce qu’un marché tokenisé n’est pas utile si la blockchain est le seul système à savoir ce qui s’est passé.
Les dépositaires, les bourses, les tableaux de bord, les systèmes de conformité et d’autres infrastructures peuvent tous avoir besoin de réagir au même événement.
Cela m’a fait regarder RUES différemment.
Ce n’est pas la transaction.
C’est le signal qui permet à tout ce qui entoure la transaction de continuer à avancer.
Et maintenant je me demande :
La finance on-chain peut-elle vraiment s’étendre à l’infrastructure financière existante si les systèmes situés en dehors de la chaîne ne peuvent pas réagir de façon fiable à ce qui se passe à l’intérieur ?
#dusk $DUSK @Dusk
Et j’ai découvert un problème que je n’avais pas vraiment envisagé.
Une blockchain peut savoir qu’une chose s’est produite.
Mais comment le reste du système financier le sait-il ?
Imaginez une bourse où une transaction a lieu à l’intérieur du bâtiment, mais où personne n’envoie un message à la chambre de compensation.
La transaction existe.
Mais les systèmes qui l’entourent attendent encore.
C’est ce qui a rendu le système d’événements RUES de DUSK intéressant à mes yeux.
Les nœuds DUSK peuvent exposer des événements pour des choses comme des blocs acceptés, des transactions incluses ou exécutées, et des événements spécifiques au contrat. Les applications externes peuvent s’abonner à ces événements via des WebSockets au lieu de demander en permanence à la chaîne :
« Quelque chose s’est-il produit ? »
Et il y a un détail important ici.
DUSK prend aussi en charge les données historiques d’événements via des nœuds d’archives et des requêtes GraphQL, y compris les événements finalisés.
Donc ce n’est pas seulement une question de notifications.
Cela crée un pont entre ce qui s’est passé on-chain et les systèmes qui doivent y réagir.
Cela compte bien plus pour l’infrastructure financière que ce que cela peut sembler.
Parce qu’un marché tokenisé n’est pas utile si la blockchain est le seul système à savoir ce qui s’est passé.
Les dépositaires, les bourses, les tableaux de bord, les systèmes de conformité et d’autres infrastructures peuvent tous avoir besoin de réagir au même événement.
Cela m’a fait regarder RUES différemment.
Ce n’est pas la transaction.
C’est le signal qui permet à tout ce qui entoure la transaction de continuer à avancer.
Et maintenant je me demande :
La finance on-chain peut-elle vraiment s’étendre à l’infrastructure financière existante si les systèmes situés en dehors de la chaîne ne peuvent pas réagir de façon fiable à ce qui se passe à l’intérieur ?
#dusk $DUSK @Dusk
2
1
89
·
--
#dusk $DUSK @Dusk_Foundation J’ai repéré un choix de conception dans DUSK qui m’a d’abord semblé contradictoire.
Si DUSK dispose de son propre environnement d’exécution, pourquoi construire une voie basée sur l’EVM ?
Pensez à un aéroport spécialisé.
Vous pouvez construire un tout nouvel avion depuis zéro.
Mais si vous voulez que des milliers de pilotes existants utilisent votre aéroport, leur offrir une piste familière facilite énormément l’adoption.
C’est ce qui m’a rendu DuskEVM intéressant.
DUSK dispose déjà de DuskVM pour les contrats qui ont besoin d’un accès direct au L1.
Pourtant, DuskEVM offre aux développeurs l’environnement Ethereum familier — Solidity, Vyper, les outils EVM standard et les portefeuilles — tout en utilisant DuskDS en dessous pour le règlement et la disponibilité des données.
Puis j’ai remarqué Hedger.
C’est l’évolution de Zedger, mais construite sur DuskEVM — essentiellement en apportant la focalisation de DUSK sur les actifs réglementés dans un environnement d’abord orienté EVM.
Cela me dit quelque chose sur la stratégie de DUSK.
On dirait que ce n’est pas en train de dire :
« Oubliez Ethereum. Apprenez notre pile. »
C’est plutôt proche de :
« Gardez la porte d’entrée familière pour les développeurs, mais reliez-la à une infrastructure conçue pour la finance réglementée. »
Et c’est important, car la supériorité technique compte peu si les développeurs doivent abandonner les outils qu’ils connaissent déjà avant de pouvoir l’utiliser.
Donc la question intéressante n’est pas :
« DUSK prend-il en charge l’EVM ?
C’est plutôt :
« L’infrastructure financière peut-elle rester spécialisée sans forcer l’écosystème développeur à repartir de zéro ? »
C’est ce que je vais surveiller avec Hedger.
#dusk $DUSK @Dusk_Foundation
#dusk $DUSK @Dusk J’ai repéré un choix de conception dans DUSK qui m’a d’abord semblé contradictoire.
Si DUSK dispose de son propre environnement d’exécution, pourquoi construire une voie basée sur l’EVM ?
Pensez à un aéroport spécialisé.
Vous pouvez construire un tout nouvel avion depuis zéro.
Mais si vous voulez que des milliers de pilotes existants utilisent votre aéroport, leur offrir une piste familière facilite énormément l’adoption.
C’est ce qui m’a rendu DuskEVM intéressant.
DUSK dispose déjà de DuskVM pour les contrats qui ont besoin d’un accès direct au L1.
Pourtant, DuskEVM offre aux développeurs l’environnement Ethereum familier — Solidity, Vyper, les outils EVM standard et les portefeuilles — tout en utilisant DuskDS en dessous pour le règlement et la disponibilité des données.
Puis j’ai remarqué Hedger.
C’est l’évolution de Zedger, mais construite sur DuskEVM — essentiellement en apportant la focalisation de DUSK sur les actifs réglementés dans un environnement d’abord orienté EVM.
Cela me dit quelque chose sur la stratégie de DUSK.
On dirait que ce n’est pas en train de dire :
« Oubliez Ethereum. Apprenez notre pile. »
C’est plutôt proche de :
« Gardez la porte d’entrée familière pour les développeurs, mais reliez-la à une infrastructure conçue pour la finance réglementée. »
Et c’est important, car la supériorité technique compte peu si les développeurs doivent abandonner les outils qu’ils connaissent déjà avant de pouvoir l’utiliser.
Donc la question intéressante n’est pas :
« DUSK prend-il en charge l’EVM ?
C’est plutôt :
« L’infrastructure financière peut-elle rester spécialisée sans forcer l’écosystème développeur à repartir de zéro ? »
C’est ce que je vais surveiller avec Hedger.
#dusk $DUSK @Dusk
Si DUSK dispose de son propre environnement d’exécution, pourquoi construire une voie basée sur l’EVM ?
Pensez à un aéroport spécialisé.
Vous pouvez construire un tout nouvel avion depuis zéro.
Mais si vous voulez que des milliers de pilotes existants utilisent votre aéroport, leur offrir une piste familière facilite énormément l’adoption.
C’est ce qui m’a rendu DuskEVM intéressant.
DUSK dispose déjà de DuskVM pour les contrats qui ont besoin d’un accès direct au L1.
Pourtant, DuskEVM offre aux développeurs l’environnement Ethereum familier — Solidity, Vyper, les outils EVM standard et les portefeuilles — tout en utilisant DuskDS en dessous pour le règlement et la disponibilité des données.
Puis j’ai remarqué Hedger.
C’est l’évolution de Zedger, mais construite sur DuskEVM — essentiellement en apportant la focalisation de DUSK sur les actifs réglementés dans un environnement d’abord orienté EVM.
Cela me dit quelque chose sur la stratégie de DUSK.
On dirait que ce n’est pas en train de dire :
« Oubliez Ethereum. Apprenez notre pile. »
C’est plutôt proche de :
« Gardez la porte d’entrée familière pour les développeurs, mais reliez-la à une infrastructure conçue pour la finance réglementée. »
Et c’est important, car la supériorité technique compte peu si les développeurs doivent abandonner les outils qu’ils connaissent déjà avant de pouvoir l’utiliser.
Donc la question intéressante n’est pas :
« DUSK prend-il en charge l’EVM ?
C’est plutôt :
« L’infrastructure financière peut-elle rester spécialisée sans forcer l’écosystème développeur à repartir de zéro ? »
C’est ce que je vais surveiller avec Hedger.
#dusk $DUSK @Dusk
82
·
--
#dusk $DUSK @Dusk_Foundation J’ai remarqué quelque chose qui, au départ, n’avait pas vraiment de sens.
Si DUSK veut que les développeurs construisent des applications financières, pourquoi créer son propre environnement d’exécution alors qu’un EVM existe déjà ?
Imaginez ouvrir un atelier spécialisé à côté d’une énorme usine généraliste.
L’usine peut fabriquer presque tout.
Mais votre atelier est conçu autour d’un seul type de travail.
C’est la différence que j’ai trouvée entre DuskVM et DuskEVM.
DuskEVM offre aux développeurs l’environnement Ethereum familier : Solidity, Vyper, les outils standard EVM et les portefeuilles.
Mais DuskVM prend une autre voie.
Il exécute directement sur le Dusk L1 des contrats intelligents Rust/WASM, donnant aux contrats un accès direct aux modèles natifs de transactions de Dusk, aux actifs, à la confidentialité et aux capacités de preuve à connaissance nulle.
C’est là que l’architecture m’a semblé évidente.
DUSK ne force pas chaque application à entrer dans un seul modèle d’exécution.
Il conserve l’environnement familier pour assurer la compatibilité…
tout en conservant un environnement natif pour les applications qui ont besoin d’un accès plus profond au L1.
Et c’est important, car les applications financières réglementées ne sont pas toujours de simples contrats DeFi ordinaires.
Certaines ont besoin directement des primitives de règlement et de confidentialité.
Alors peut-être que la question intéressante n’est pas :
« Pourquoi DUSK a deux VMs ? »
C’est plutôt :
« Que se passe-t-il quand la compatibilité et la spécialisation sont traitées comme deux problèmes d’ingénierie différents ? »
Ce compromis m’en dit beaucoup sur ce que DUSK essaie réellement de construire.
#dusk $DUSK @Dusk_Foundation
#dusk $DUSK @Dusk J’ai remarqué quelque chose qui, au départ, n’avait pas vraiment de sens.
Si DUSK veut que les développeurs construisent des applications financières, pourquoi créer son propre environnement d’exécution alors qu’un EVM existe déjà ?
Imaginez ouvrir un atelier spécialisé à côté d’une énorme usine généraliste.
L’usine peut fabriquer presque tout.
Mais votre atelier est conçu autour d’un seul type de travail.
C’est la différence que j’ai trouvée entre DuskVM et DuskEVM.
DuskEVM offre aux développeurs l’environnement Ethereum familier : Solidity, Vyper, les outils standard EVM et les portefeuilles.
Mais DuskVM prend une autre voie.
Il exécute directement sur le Dusk L1 des contrats intelligents Rust/WASM, donnant aux contrats un accès direct aux modèles natifs de transactions de Dusk, aux actifs, à la confidentialité et aux capacités de preuve à connaissance nulle.
C’est là que l’architecture m’a semblé évidente.
DUSK ne force pas chaque application à entrer dans un seul modèle d’exécution.
Il conserve l’environnement familier pour assurer la compatibilité…
tout en conservant un environnement natif pour les applications qui ont besoin d’un accès plus profond au L1.
Et c’est important, car les applications financières réglementées ne sont pas toujours de simples contrats DeFi ordinaires.
Certaines ont besoin directement des primitives de règlement et de confidentialité.
Alors peut-être que la question intéressante n’est pas :
« Pourquoi DUSK a deux VMs ? »
C’est plutôt :
« Que se passe-t-il quand la compatibilité et la spécialisation sont traitées comme deux problèmes d’ingénierie différents ? »
Ce compromis m’en dit beaucoup sur ce que DUSK essaie réellement de construire.
#dusk $DUSK @Dusk
Si DUSK veut que les développeurs construisent des applications financières, pourquoi créer son propre environnement d’exécution alors qu’un EVM existe déjà ?
Imaginez ouvrir un atelier spécialisé à côté d’une énorme usine généraliste.
L’usine peut fabriquer presque tout.
Mais votre atelier est conçu autour d’un seul type de travail.
C’est la différence que j’ai trouvée entre DuskVM et DuskEVM.
DuskEVM offre aux développeurs l’environnement Ethereum familier : Solidity, Vyper, les outils standard EVM et les portefeuilles.
Mais DuskVM prend une autre voie.
Il exécute directement sur le Dusk L1 des contrats intelligents Rust/WASM, donnant aux contrats un accès direct aux modèles natifs de transactions de Dusk, aux actifs, à la confidentialité et aux capacités de preuve à connaissance nulle.
C’est là que l’architecture m’a semblé évidente.
DUSK ne force pas chaque application à entrer dans un seul modèle d’exécution.
Il conserve l’environnement familier pour assurer la compatibilité…
tout en conservant un environnement natif pour les applications qui ont besoin d’un accès plus profond au L1.
Et c’est important, car les applications financières réglementées ne sont pas toujours de simples contrats DeFi ordinaires.
Certaines ont besoin directement des primitives de règlement et de confidentialité.
Alors peut-être que la question intéressante n’est pas :
« Pourquoi DUSK a deux VMs ? »
C’est plutôt :
« Que se passe-t-il quand la compatibilité et la spécialisation sont traitées comme deux problèmes d’ingénierie différents ? »
Ce compromis m’en dit beaucoup sur ce que DUSK essaie réellement de construire.
#dusk $DUSK @Dusk
7
1
121
·
--
#dusk $DUSK @Dusk_Foundation Je suis tombé sur un détail dans le design de consensus de DUSK qui m’a fait repenser ce que signifie réellement « décentralisé ».
Imaginez un tribunal où les mêmes 20 personnes jugent chaque affaire.
Même si elles sont honnêtes, vous commenceriez probablement à vous demander :
Pourquoi eux ?
Maintenant, imaginez que le jury soit tiré au sort pour chaque affaire.
Des personnes différentes examinent les preuves, un autre groupe confirme la décision, et une fois le verdict ratifié, l’affaire est close.
C’est ce modèle mental qui m’a aidé à comprendre l’Attestation concise de DUSK.
Au lieu d’avoir un groupe fixe responsable de chaque bloc, DUSK utilise des dispensateurs sélectionnés aléatoirement en comités.
Un comité peut proposer, tandis qu’un autre peut valider et ratifier le résultat.
La partie intéressante, c’est ce qui se passe après la ratification :
le bloc atteint une finalité déterministe.
Alors j’ai commencé à voir cela moins comme « un autre design de Proof-of-Stake » et davantage comme un problème de coordination.
Si les mêmes validateurs contrôlaient en permanence chaque décision, la décentralisation pourrait progressivement devenir une question de qui a le siège.
La sélection aléatoire des comités change cette dynamique.
Et je pense qu’il y a une raison pour laquelle DUSK s’intéresse à cette architecture.
L’infrastructure financière n’a pas seulement besoin de blocs à produire.
Elle a besoin d’un processus permettant aux acteurs du marché de savoir quand une décision est réellement finale.
C’est la partie qui m’intéresse dans l’AS :
DUSK n’a pas seulement demandé qui devrait valider le prochain bloc. Elle a conçu un processus pour décider qui a le droit de le juger — et quand ce jugement devient final.
#dusk $DUSK @Dusk_Foundation
#dusk $DUSK @Dusk Je suis tombé sur un détail dans le design de consensus de DUSK qui m’a fait repenser ce que signifie réellement « décentralisé ».
Imaginez un tribunal où les mêmes 20 personnes jugent chaque affaire.
Même si elles sont honnêtes, vous commenceriez probablement à vous demander :
Pourquoi eux ?
Maintenant, imaginez que le jury soit tiré au sort pour chaque affaire.
Des personnes différentes examinent les preuves, un autre groupe confirme la décision, et une fois le verdict ratifié, l’affaire est close.
C’est ce modèle mental qui m’a aidé à comprendre l’Attestation concise de DUSK.
Au lieu d’avoir un groupe fixe responsable de chaque bloc, DUSK utilise des dispensateurs sélectionnés aléatoirement en comités.
Un comité peut proposer, tandis qu’un autre peut valider et ratifier le résultat.
La partie intéressante, c’est ce qui se passe après la ratification :
le bloc atteint une finalité déterministe.
Alors j’ai commencé à voir cela moins comme « un autre design de Proof-of-Stake » et davantage comme un problème de coordination.
Si les mêmes validateurs contrôlaient en permanence chaque décision, la décentralisation pourrait progressivement devenir une question de qui a le siège.
La sélection aléatoire des comités change cette dynamique.
Et je pense qu’il y a une raison pour laquelle DUSK s’intéresse à cette architecture.
L’infrastructure financière n’a pas seulement besoin de blocs à produire.
Elle a besoin d’un processus permettant aux acteurs du marché de savoir quand une décision est réellement finale.
C’est la partie qui m’intéresse dans l’AS :
DUSK n’a pas seulement demandé qui devrait valider le prochain bloc. Elle a conçu un processus pour décider qui a le droit de le juger — et quand ce jugement devient final.
#dusk $DUSK @Dusk
Imaginez un tribunal où les mêmes 20 personnes jugent chaque affaire.
Même si elles sont honnêtes, vous commenceriez probablement à vous demander :
Pourquoi eux ?
Maintenant, imaginez que le jury soit tiré au sort pour chaque affaire.
Des personnes différentes examinent les preuves, un autre groupe confirme la décision, et une fois le verdict ratifié, l’affaire est close.
C’est ce modèle mental qui m’a aidé à comprendre l’Attestation concise de DUSK.
Au lieu d’avoir un groupe fixe responsable de chaque bloc, DUSK utilise des dispensateurs sélectionnés aléatoirement en comités.
Un comité peut proposer, tandis qu’un autre peut valider et ratifier le résultat.
La partie intéressante, c’est ce qui se passe après la ratification :
le bloc atteint une finalité déterministe.
Alors j’ai commencé à voir cela moins comme « un autre design de Proof-of-Stake » et davantage comme un problème de coordination.
Si les mêmes validateurs contrôlaient en permanence chaque décision, la décentralisation pourrait progressivement devenir une question de qui a le siège.
La sélection aléatoire des comités change cette dynamique.
Et je pense qu’il y a une raison pour laquelle DUSK s’intéresse à cette architecture.
L’infrastructure financière n’a pas seulement besoin de blocs à produire.
Elle a besoin d’un processus permettant aux acteurs du marché de savoir quand une décision est réellement finale.
C’est la partie qui m’intéresse dans l’AS :
DUSK n’a pas seulement demandé qui devrait valider le prochain bloc. Elle a conçu un processus pour décider qui a le droit de le juger — et quand ce jugement devient final.
#dusk $DUSK @Dusk
1
102
·
--
#dusk $DUSK @Dusk_Foundation J'ai identifié un problème avec le « règlement instantané » auquel je n’avais pas vraiment réfléchi.
Et si l’actif arrive avant l’argent ?
Imaginez acheter une maison.
Le vendeur vous remet d’abord les clés.
Vous vous engagez à payer demain.
Techniquement, le transfert de propriété a eu lieu rapidement.
Mais la transaction reste exposée à un problème très ancien :
Un des deux côtés a livré. L’autre côté ne l’a pas fait.
Ce même écart existe dans les marchés financiers lorsque la partie « actif » et la partie « paiement » sont traitées séparément.
Alors, j’ai regardé ce que DUSK construit autour de ce sujet.
Son infrastructure de marché est conçue pour coordonner la partie « actif » et la partie « paiement », avec un règlement déterministe en dessous. Dusk Trade décrit cela comme la coordination des deux côtés d’un échange réglementé, plutôt que de traiter le transfert d’actifs comme un événement isolé.
Cela ressemble à une décision d’architecture plutôt mineure.
Je ne pense pas que ce soit le cas.
Parce que le vrai problème du règlement n’est pas simplement :
« À quelle vitesse le token peut-il se déplacer ? »
C’est plutôt :
« Comment les deux parties de la transaction savent-elles que l’accord est réellement terminé ? »
La réponse de DUSK consiste à faire entrer les deux « legs » dans le même workflow de règlement.
C’est une idée très différente de celle qui consisterait simplement à mettre des titres on-chain.
Vous ne faites pas que numériser l’actif.
Vous essayez de coordonner l’échange lui-même.
Et cela m’a amené à une question :
Si l’actif et le paiement se règlent encore de manière indépendante, peut-on vraiment parler de règlement atomique ?
@Dusk_Foundation $DUSK #Dusk.
#dusk $DUSK @Dusk J'ai identifié un problème avec le « règlement instantané » auquel je n’avais pas vraiment réfléchi.
Et si l’actif arrive avant l’argent ?
Imaginez acheter une maison.
Le vendeur vous remet d’abord les clés.
Vous vous engagez à payer demain.
Techniquement, le transfert de propriété a eu lieu rapidement.
Mais la transaction reste exposée à un problème très ancien :
Un des deux côtés a livré. L’autre côté ne l’a pas fait.
Ce même écart existe dans les marchés financiers lorsque la partie « actif » et la partie « paiement » sont traitées séparément.
Alors, j’ai regardé ce que DUSK construit autour de ce sujet.
Son infrastructure de marché est conçue pour coordonner la partie « actif » et la partie « paiement », avec un règlement déterministe en dessous. Dusk Trade décrit cela comme la coordination des deux côtés d’un échange réglementé, plutôt que de traiter le transfert d’actifs comme un événement isolé.
Cela ressemble à une décision d’architecture plutôt mineure.
Je ne pense pas que ce soit le cas.
Parce que le vrai problème du règlement n’est pas simplement :
« À quelle vitesse le token peut-il se déplacer ? »
C’est plutôt :
« Comment les deux parties de la transaction savent-elles que l’accord est réellement terminé ? »
La réponse de DUSK consiste à faire entrer les deux « legs » dans le même workflow de règlement.
C’est une idée très différente de celle qui consisterait simplement à mettre des titres on-chain.
Vous ne faites pas que numériser l’actif.
Vous essayez de coordonner l’échange lui-même.
Et cela m’a amené à une question :
Si l’actif et le paiement se règlent encore de manière indépendante, peut-on vraiment parler de règlement atomique ?
@Dusk $DUSK #Dusk.
Et si l’actif arrive avant l’argent ?
Imaginez acheter une maison.
Le vendeur vous remet d’abord les clés.
Vous vous engagez à payer demain.
Techniquement, le transfert de propriété a eu lieu rapidement.
Mais la transaction reste exposée à un problème très ancien :
Un des deux côtés a livré. L’autre côté ne l’a pas fait.
Ce même écart existe dans les marchés financiers lorsque la partie « actif » et la partie « paiement » sont traitées séparément.
Alors, j’ai regardé ce que DUSK construit autour de ce sujet.
Son infrastructure de marché est conçue pour coordonner la partie « actif » et la partie « paiement », avec un règlement déterministe en dessous. Dusk Trade décrit cela comme la coordination des deux côtés d’un échange réglementé, plutôt que de traiter le transfert d’actifs comme un événement isolé.
Cela ressemble à une décision d’architecture plutôt mineure.
Je ne pense pas que ce soit le cas.
Parce que le vrai problème du règlement n’est pas simplement :
« À quelle vitesse le token peut-il se déplacer ? »
C’est plutôt :
« Comment les deux parties de la transaction savent-elles que l’accord est réellement terminé ? »
La réponse de DUSK consiste à faire entrer les deux « legs » dans le même workflow de règlement.
C’est une idée très différente de celle qui consisterait simplement à mettre des titres on-chain.
Vous ne faites pas que numériser l’actif.
Vous essayez de coordonner l’échange lui-même.
Et cela m’a amené à une question :
Si l’actif et le paiement se règlent encore de manière indépendante, peut-on vraiment parler de règlement atomique ?
@Dusk $DUSK #Dusk.
94
·
--
#dusk $DUSK @Dusk_Foundation J’ai continué à voir des “actifs tokenisés” décrits comme si la partie difficile s’arrêtait au moment où le jeton change de mains.
Ça m’a fait m’arrêter.
Imaginez acheter des actions d’une entreprise.
L’achat est terminé.
Mais que se passe-t-il quand l’entreprise déclare un dividende ?
Organise-t-elle un vote des actionnaires ?
Modifie-t-elle les conditions du titre ?
Envoie-t-elle une mise à jour aux investisseurs ?
La trace de propriété doit encore faire quelque chose.
C’est là que j’ai trouvé une autre partie intéressante de l’architecture de DUSK : le service aux actifs (asset servicing).
La conception de l’infrastructure de marché de DUSK considère les actifs réglementés comme davantage que de simples jetons transférables.
Le workflow doit aussi gérer des éléments comme les opérations sur titres (corporate actions), les mises à jour des investisseurs, le reporting et les pistes d’audit, en plus de l’émission, des transferts et du règlement.
Cela change ma façon de voir la tokenisation.
Un jeton qui peut passer de Wallet A à Wallet B n’est qu’un instant dans la vie d’un actif.
La question la plus difficile est donc :
Que devient l’actif après la transaction ?
Si les dividendes, le vote, les changements de propriété et le reporting dépendent encore de systèmes déconnectés, alors la blockchain a peut-être numérisé le transfert sans vraiment numériser le cycle de vie de l’actif.
C’est pour cela que l’approche de DUSK a attiré mon attention.
Ce n’est pas seulement en train de demander :
“Peut-on mettre des titres sur la chaîne ?”
Il semble plutôt s’agir de demander :
“L’actif peut-il continuer à fonctionner sur la chaîne une fois qu’il y est arrivé ?”
Et franchement, je pense que c’est le problème le plus difficile.
#dusk $DUSK @Dusk_Foundation
#dusk $DUSK @Dusk J’ai continué à voir des “actifs tokenisés” décrits comme si la partie difficile s’arrêtait au moment où le jeton change de mains.
Ça m’a fait m’arrêter.
Imaginez acheter des actions d’une entreprise.
L’achat est terminé.
Mais que se passe-t-il quand l’entreprise déclare un dividende ?
Organise-t-elle un vote des actionnaires ?
Modifie-t-elle les conditions du titre ?
Envoie-t-elle une mise à jour aux investisseurs ?
La trace de propriété doit encore faire quelque chose.
C’est là que j’ai trouvé une autre partie intéressante de l’architecture de DUSK : le service aux actifs (asset servicing).
La conception de l’infrastructure de marché de DUSK considère les actifs réglementés comme davantage que de simples jetons transférables.
Le workflow doit aussi gérer des éléments comme les opérations sur titres (corporate actions), les mises à jour des investisseurs, le reporting et les pistes d’audit, en plus de l’émission, des transferts et du règlement.
Cela change ma façon de voir la tokenisation.
Un jeton qui peut passer de Wallet A à Wallet B n’est qu’un instant dans la vie d’un actif.
La question la plus difficile est donc :
Que devient l’actif après la transaction ?
Si les dividendes, le vote, les changements de propriété et le reporting dépendent encore de systèmes déconnectés, alors la blockchain a peut-être numérisé le transfert sans vraiment numériser le cycle de vie de l’actif.
C’est pour cela que l’approche de DUSK a attiré mon attention.
Ce n’est pas seulement en train de demander :
“Peut-on mettre des titres sur la chaîne ?”
Il semble plutôt s’agir de demander :
“L’actif peut-il continuer à fonctionner sur la chaîne une fois qu’il y est arrivé ?”
Et franchement, je pense que c’est le problème le plus difficile.
#dusk $DUSK @Dusk
Ça m’a fait m’arrêter.
Imaginez acheter des actions d’une entreprise.
L’achat est terminé.
Mais que se passe-t-il quand l’entreprise déclare un dividende ?
Organise-t-elle un vote des actionnaires ?
Modifie-t-elle les conditions du titre ?
Envoie-t-elle une mise à jour aux investisseurs ?
La trace de propriété doit encore faire quelque chose.
C’est là que j’ai trouvé une autre partie intéressante de l’architecture de DUSK : le service aux actifs (asset servicing).
La conception de l’infrastructure de marché de DUSK considère les actifs réglementés comme davantage que de simples jetons transférables.
Le workflow doit aussi gérer des éléments comme les opérations sur titres (corporate actions), les mises à jour des investisseurs, le reporting et les pistes d’audit, en plus de l’émission, des transferts et du règlement.
Cela change ma façon de voir la tokenisation.
Un jeton qui peut passer de Wallet A à Wallet B n’est qu’un instant dans la vie d’un actif.
La question la plus difficile est donc :
Que devient l’actif après la transaction ?
Si les dividendes, le vote, les changements de propriété et le reporting dépendent encore de systèmes déconnectés, alors la blockchain a peut-être numérisé le transfert sans vraiment numériser le cycle de vie de l’actif.
C’est pour cela que l’approche de DUSK a attiré mon attention.
Ce n’est pas seulement en train de demander :
“Peut-on mettre des titres sur la chaîne ?”
Il semble plutôt s’agir de demander :
“L’actif peut-il continuer à fonctionner sur la chaîne une fois qu’il y est arrivé ?”
Et franchement, je pense que c’est le problème le plus difficile.
#dusk $DUSK @Dusk
3
2
102
·
--
#dusk $DUSK @Dusk_Foundation La tokenisation est censée rendre les marchés financiers plus faciles d’accès.
Mais cela m’a fait réfléchir :
Que se passe-t-il quand l’actif est plus facile à obtenir que les règles qui déterminent qui peut en être propriétaire ?
Imaginez une vente aux enchères privée.
Elle est entièrement numérique.
Les enchères sont instantanées.
Mais il y a quand même une liste d’invités.
Le fait de pouvoir voir l’enchère ne signifie pas que vous êtes autorisé à acheter ce qui est mis en vente.
Cette distinction devient cruciale pour les actifs réglementés.
Je me suis penché sur la façon dont DUSK gère cela et j’ai trouvé des contrôles d’accès + une liaison du portefeuille intégrés à la conception de son infrastructure de marché.
L’idée est simple :
D’abord, établir qu’un participant est éligible.
Ensuite, lier ce participant vérifié au portefeuille qui interagit avec l’actif.
Ensuite, les transferts peuvent être vérifiés par rapport aux règles.
Ainsi, la blockchain ne sert pas uniquement à enregistrer :
« Le portefeuille A a envoyé un actif au portefeuille B. »
La question la plus intéressante devient :
« Le portefeuille B était-il réellement autorisé à le recevoir ? »
Cela change la signification de ce que « la conformité onchain » représente pour moi.
Il ne s’agit pas seulement de stocker quelque part un résultat de KYC.
C’est relier l’identité → l’éligibilité → le portefeuille → le transfert dans le même flux de travail lié à l’actif.
Et cela devient particulièrement passionnant à mesure que la tokenisation cherche à ouvrir des marchés traditionnellement privés à davantage d’investisseurs.
Car rendre un actif plus facile d’accès n’est utile que si l’infrastructure peut encore répondre :
Qui est autorisé à franchir la porte ? #dusk $DUSK @Dusk_Foundation
#dusk $DUSK @Dusk La tokenisation est censée rendre les marchés financiers plus faciles d’accès.
Mais cela m’a fait réfléchir :
Que se passe-t-il quand l’actif est plus facile à obtenir que les règles qui déterminent qui peut en être propriétaire ?
Imaginez une vente aux enchères privée.
Elle est entièrement numérique.
Les enchères sont instantanées.
Mais il y a quand même une liste d’invités.
Le fait de pouvoir voir l’enchère ne signifie pas que vous êtes autorisé à acheter ce qui est mis en vente.
Cette distinction devient cruciale pour les actifs réglementés.
Je me suis penché sur la façon dont DUSK gère cela et j’ai trouvé des contrôles d’accès + une liaison du portefeuille intégrés à la conception de son infrastructure de marché.
L’idée est simple :
D’abord, établir qu’un participant est éligible.
Ensuite, lier ce participant vérifié au portefeuille qui interagit avec l’actif.
Ensuite, les transferts peuvent être vérifiés par rapport aux règles.
Ainsi, la blockchain ne sert pas uniquement à enregistrer :
« Le portefeuille A a envoyé un actif au portefeuille B. »
La question la plus intéressante devient :
« Le portefeuille B était-il réellement autorisé à le recevoir ? »
Cela change la signification de ce que « la conformité onchain » représente pour moi.
Il ne s’agit pas seulement de stocker quelque part un résultat de KYC.
C’est relier l’identité → l’éligibilité → le portefeuille → le transfert dans le même flux de travail lié à l’actif.
Et cela devient particulièrement passionnant à mesure que la tokenisation cherche à ouvrir des marchés traditionnellement privés à davantage d’investisseurs.
Car rendre un actif plus facile d’accès n’est utile que si l’infrastructure peut encore répondre :
Qui est autorisé à franchir la porte ? #dusk $DUSK @Dusk
Mais cela m’a fait réfléchir :
Que se passe-t-il quand l’actif est plus facile à obtenir que les règles qui déterminent qui peut en être propriétaire ?
Imaginez une vente aux enchères privée.
Elle est entièrement numérique.
Les enchères sont instantanées.
Mais il y a quand même une liste d’invités.
Le fait de pouvoir voir l’enchère ne signifie pas que vous êtes autorisé à acheter ce qui est mis en vente.
Cette distinction devient cruciale pour les actifs réglementés.
Je me suis penché sur la façon dont DUSK gère cela et j’ai trouvé des contrôles d’accès + une liaison du portefeuille intégrés à la conception de son infrastructure de marché.
L’idée est simple :
D’abord, établir qu’un participant est éligible.
Ensuite, lier ce participant vérifié au portefeuille qui interagit avec l’actif.
Ensuite, les transferts peuvent être vérifiés par rapport aux règles.
Ainsi, la blockchain ne sert pas uniquement à enregistrer :
« Le portefeuille A a envoyé un actif au portefeuille B. »
La question la plus intéressante devient :
« Le portefeuille B était-il réellement autorisé à le recevoir ? »
Cela change la signification de ce que « la conformité onchain » représente pour moi.
Il ne s’agit pas seulement de stocker quelque part un résultat de KYC.
C’est relier l’identité → l’éligibilité → le portefeuille → le transfert dans le même flux de travail lié à l’actif.
Et cela devient particulièrement passionnant à mesure que la tokenisation cherche à ouvrir des marchés traditionnellement privés à davantage d’investisseurs.
Car rendre un actif plus facile d’accès n’est utile que si l’infrastructure peut encore répondre :
Qui est autorisé à franchir la porte ? #dusk $DUSK @Dusk
3
3
96
·
--
#dusk $DUSK @Dusk_Foundation J’ai commencé à me demander pourquoi prouver qu’on est éligible à quelque chose implique généralement de remettre l’intégralité de son identité.
Imaginez une boîte de nuit qui vérifie si vous avez plus de 18 ans.
Est-ce que cela aurait du sens pour le videur de photocopier tout votre passeport juste pour vérifier un seul fait.
C’est essentiellement le problème que j’ai découvert en creusant davantage la KYC numérique.
L’institution doit savoir.
« Cette personne répond-elle à l’exigence ?
Mais la vérification traditionnelle en donne souvent beaucoup plus.
nom, adresse, date de naissance, détails du document.
Alors j’ai regardé comment DUSK aborde cela avec Citadel.
Citadel utilise des preuves à divulgation nulle de connaissance afin qu’un utilisateur puisse prouver qu’il détient une preuve d’éligibilité valide sans exposer en elle-même l’information sous-jacente. Son protocole peut émettre une licence en chaîne, puis permettre à l’utilisateur de prouver qu’il détient une licence valide lorsqu’il demande un service.
Cela change la relation entre KYC et la confidentialité.
Au lieu de.
« Voici mon identité. Vérifiez tout.
Il devient.
« Voici une preuve cryptographique qui montre que je satisfais à l’exigence.
Et je pense que cela explique pourquoi DUSK avait besoin de Citadel.
Si l’objectif est d’amener la finance réglementée en chaîne, la conformité ne peut pas simplement disparaître.
Mais aucune interaction financière ne devrait non plus exiger une nouvelle copie des données personnelles de quelqu’un.
La question intéressante n’est pas de savoir si le KYC doit exister.
C’est.
De quelle quantité d’informations la preuve d’éligibilité a-t-elle réellement besoin pour vous obliger à la révéler ?
@Dusk_Foundation $DUSK
#dusk
#dusk $DUSK @Dusk J’ai commencé à me demander pourquoi prouver qu’on est éligible à quelque chose implique généralement de remettre l’intégralité de son identité.
Imaginez une boîte de nuit qui vérifie si vous avez plus de 18 ans.
Est-ce que cela aurait du sens pour le videur de photocopier tout votre passeport juste pour vérifier un seul fait.
C’est essentiellement le problème que j’ai découvert en creusant davantage la KYC numérique.
L’institution doit savoir.
« Cette personne répond-elle à l’exigence ?
Mais la vérification traditionnelle en donne souvent beaucoup plus.
nom, adresse, date de naissance, détails du document.
Alors j’ai regardé comment DUSK aborde cela avec Citadel.
Citadel utilise des preuves à divulgation nulle de connaissance afin qu’un utilisateur puisse prouver qu’il détient une preuve d’éligibilité valide sans exposer en elle-même l’information sous-jacente. Son protocole peut émettre une licence en chaîne, puis permettre à l’utilisateur de prouver qu’il détient une licence valide lorsqu’il demande un service.
Cela change la relation entre KYC et la confidentialité.
Au lieu de.
« Voici mon identité. Vérifiez tout.
Il devient.
« Voici une preuve cryptographique qui montre que je satisfais à l’exigence.
Et je pense que cela explique pourquoi DUSK avait besoin de Citadel.
Si l’objectif est d’amener la finance réglementée en chaîne, la conformité ne peut pas simplement disparaître.
Mais aucune interaction financière ne devrait non plus exiger une nouvelle copie des données personnelles de quelqu’un.
La question intéressante n’est pas de savoir si le KYC doit exister.
C’est.
De quelle quantité d’informations la preuve d’éligibilité a-t-elle réellement besoin pour vous obliger à la révéler ?
@Dusk $DUSK
#dusk
Imaginez une boîte de nuit qui vérifie si vous avez plus de 18 ans.
Est-ce que cela aurait du sens pour le videur de photocopier tout votre passeport juste pour vérifier un seul fait.
C’est essentiellement le problème que j’ai découvert en creusant davantage la KYC numérique.
L’institution doit savoir.
« Cette personne répond-elle à l’exigence ?
Mais la vérification traditionnelle en donne souvent beaucoup plus.
nom, adresse, date de naissance, détails du document.
Alors j’ai regardé comment DUSK aborde cela avec Citadel.
Citadel utilise des preuves à divulgation nulle de connaissance afin qu’un utilisateur puisse prouver qu’il détient une preuve d’éligibilité valide sans exposer en elle-même l’information sous-jacente. Son protocole peut émettre une licence en chaîne, puis permettre à l’utilisateur de prouver qu’il détient une licence valide lorsqu’il demande un service.
Cela change la relation entre KYC et la confidentialité.
Au lieu de.
« Voici mon identité. Vérifiez tout.
Il devient.
« Voici une preuve cryptographique qui montre que je satisfais à l’exigence.
Et je pense que cela explique pourquoi DUSK avait besoin de Citadel.
Si l’objectif est d’amener la finance réglementée en chaîne, la conformité ne peut pas simplement disparaître.
Mais aucune interaction financière ne devrait non plus exiger une nouvelle copie des données personnelles de quelqu’un.
La question intéressante n’est pas de savoir si le KYC doit exister.
C’est.
De quelle quantité d’informations la preuve d’éligibilité a-t-elle réellement besoin pour vous obliger à la révéler ?
@Dusk $DUSK
#dusk
14
4
91
·
--
#dusk $DUSK @Dusk_Foundation Je regardais comment une sécurité “normale” est transférée, et une chose me dérangeait.
L’actif peut être transféré.
Mais qui vérifie si le transfert était réellement autorisé ?
Pensez à un club privé.
Avoir une carte de membre ne signifie pas automatiquement que vous pouvez la remettre à n’importe qui. Il existe des règles concernant qui peut entrer, qui peut la recevoir et quand un transfert est autorisé.
Cela m’a amené à regarder de plus près le Zedger de DUSK.
Zedger ne se limite pas à la création d’un actif numérique.
Il est conçu pour l’émission et la gestion privées et conformes d’actifs réglementés, où des éléments comme l’éligibilité, les restrictions de transfert et la confidentialité peuvent faire partie du workflow.
C’est important, car les titres réglementés ne sont pas de simples jetons.
Par exemple, une obligation peut avoir des règles sur qui peut la détenir, comment elle peut être transférée et quelles informations les différents participants sont autorisés à voir.
DUSK semble poser une question plus intéressante :
Et si le “règlement” de l’actif ne se trouvait pas dans une feuille de calcul ou une base de données séparée, mais devenait une partie de l’infrastructure qui gère l’actif lui-même ?
C’est pour cela que Zedger a retenu mon attention.
La partie intéressante n’est pas de déposer une sécurité on-chain.
C’est de rendre les règles relatives à cette sécurité exécutables, en même temps qu’elle.
@Dusk_Foundation $DUSK #dusk
#dusk $DUSK @Dusk Je regardais comment une sécurité “normale” est transférée, et une chose me dérangeait.
L’actif peut être transféré.
Mais qui vérifie si le transfert était réellement autorisé ?
Pensez à un club privé.
Avoir une carte de membre ne signifie pas automatiquement que vous pouvez la remettre à n’importe qui. Il existe des règles concernant qui peut entrer, qui peut la recevoir et quand un transfert est autorisé.
Cela m’a amené à regarder de plus près le Zedger de DUSK.
Zedger ne se limite pas à la création d’un actif numérique.
Il est conçu pour l’émission et la gestion privées et conformes d’actifs réglementés, où des éléments comme l’éligibilité, les restrictions de transfert et la confidentialité peuvent faire partie du workflow.
C’est important, car les titres réglementés ne sont pas de simples jetons.
Par exemple, une obligation peut avoir des règles sur qui peut la détenir, comment elle peut être transférée et quelles informations les différents participants sont autorisés à voir.
DUSK semble poser une question plus intéressante :
Et si le “règlement” de l’actif ne se trouvait pas dans une feuille de calcul ou une base de données séparée, mais devenait une partie de l’infrastructure qui gère l’actif lui-même ?
C’est pour cela que Zedger a retenu mon attention.
La partie intéressante n’est pas de déposer une sécurité on-chain.
C’est de rendre les règles relatives à cette sécurité exécutables, en même temps qu’elle.
@Dusk $DUSK #dusk
L’actif peut être transféré.
Mais qui vérifie si le transfert était réellement autorisé ?
Pensez à un club privé.
Avoir une carte de membre ne signifie pas automatiquement que vous pouvez la remettre à n’importe qui. Il existe des règles concernant qui peut entrer, qui peut la recevoir et quand un transfert est autorisé.
Cela m’a amené à regarder de plus près le Zedger de DUSK.
Zedger ne se limite pas à la création d’un actif numérique.
Il est conçu pour l’émission et la gestion privées et conformes d’actifs réglementés, où des éléments comme l’éligibilité, les restrictions de transfert et la confidentialité peuvent faire partie du workflow.
C’est important, car les titres réglementés ne sont pas de simples jetons.
Par exemple, une obligation peut avoir des règles sur qui peut la détenir, comment elle peut être transférée et quelles informations les différents participants sont autorisés à voir.
DUSK semble poser une question plus intéressante :
Et si le “règlement” de l’actif ne se trouvait pas dans une feuille de calcul ou une base de données séparée, mais devenait une partie de l’infrastructure qui gère l’actif lui-même ?
C’est pour cela que Zedger a retenu mon attention.
La partie intéressante n’est pas de déposer une sécurité on-chain.
C’est de rendre les règles relatives à cette sécurité exécutables, en même temps qu’elle.
@Dusk $DUSK #dusk
3
2
83
·
--
#dusk $DUSK Je me suis mis à me poser des questions en explorant DUSK.
Quand quelqu’un dit « ce lien est on-chain », qu’est-ce que cela signifie exactement « on-chain » ?
Imaginez que vous mettiez la photo d’une voiture dans une base de données numérique.
La photo est numérique.
Mais les registres de propriété, l’assurance, l’entretien et l’immatriculation sont toujours répartis entre différents bureaux.
C’est à peu près le problème que j’ai trouvé avec la simple tokenisation.
Un token peut représenter un actif financier, tandis que le cycle de vie réel de l’actif dépend encore de systèmes distincts.
DUSK emprunte une voie différente avec l’émission native.
Au lieu de considérer le token de la blockchain comme une simple enveloppe, l’actif peut être créé et géré autour du registre lui-même — avec l’émission, la propriété, les transferts, le service et le règlement conçus comme faisant partie du même flux de travail.
Cette distinction peut sembler minime.
Mais elle change la question de :
« Peut-on mettre un actif financier on-chain ? »
à :
« L’actif peut-il vraiment vivre l’ensemble de son cycle de vie on-chain ? »
Je pense que c’est pourquoi DUSK a adopté l’émission native.
L’objectif n’est pas d’avoir un autre token.
Il s’agit de réduire le nombre d’enregistrements et de transferts séparés dont un actif réglementé dépend.
Et cela me fait me demander :
Si le workflow financier sous-jacent vit encore off-chain, quelle part réelle de cet actif a-t-on vraiment mise on-chain ?
@Dusk_Foundation $DUSK #duks
#dusk $DUSK Je me suis mis à me poser des questions en explorant DUSK.
Quand quelqu’un dit « ce lien est on-chain », qu’est-ce que cela signifie exactement « on-chain » ?
Imaginez que vous mettiez la photo d’une voiture dans une base de données numérique.
La photo est numérique.
Mais les registres de propriété, l’assurance, l’entretien et l’immatriculation sont toujours répartis entre différents bureaux.
C’est à peu près le problème que j’ai trouvé avec la simple tokenisation.
Un token peut représenter un actif financier, tandis que le cycle de vie réel de l’actif dépend encore de systèmes distincts.
DUSK emprunte une voie différente avec l’émission native.
Au lieu de considérer le token de la blockchain comme une simple enveloppe, l’actif peut être créé et géré autour du registre lui-même — avec l’émission, la propriété, les transferts, le service et le règlement conçus comme faisant partie du même flux de travail.
Cette distinction peut sembler minime.
Mais elle change la question de :
« Peut-on mettre un actif financier on-chain ? »
à :
« L’actif peut-il vraiment vivre l’ensemble de son cycle de vie on-chain ? »
Je pense que c’est pourquoi DUSK a adopté l’émission native.
L’objectif n’est pas d’avoir un autre token.
Il s’agit de réduire le nombre d’enregistrements et de transferts séparés dont un actif réglementé dépend.
Et cela me fait me demander :
Si le workflow financier sous-jacent vit encore off-chain, quelle part réelle de cet actif a-t-on vraiment mise on-chain ?
@Dusk $DUSK #duks
Quand quelqu’un dit « ce lien est on-chain », qu’est-ce que cela signifie exactement « on-chain » ?
Imaginez que vous mettiez la photo d’une voiture dans une base de données numérique.
La photo est numérique.
Mais les registres de propriété, l’assurance, l’entretien et l’immatriculation sont toujours répartis entre différents bureaux.
C’est à peu près le problème que j’ai trouvé avec la simple tokenisation.
Un token peut représenter un actif financier, tandis que le cycle de vie réel de l’actif dépend encore de systèmes distincts.
DUSK emprunte une voie différente avec l’émission native.
Au lieu de considérer le token de la blockchain comme une simple enveloppe, l’actif peut être créé et géré autour du registre lui-même — avec l’émission, la propriété, les transferts, le service et le règlement conçus comme faisant partie du même flux de travail.
Cette distinction peut sembler minime.
Mais elle change la question de :
« Peut-on mettre un actif financier on-chain ? »
à :
« L’actif peut-il vraiment vivre l’ensemble de son cycle de vie on-chain ? »
Je pense que c’est pourquoi DUSK a adopté l’émission native.
L’objectif n’est pas d’avoir un autre token.
Il s’agit de réduire le nombre d’enregistrements et de transferts séparés dont un actif réglementé dépend.
Et cela me fait me demander :
Si le workflow financier sous-jacent vit encore off-chain, quelle part réelle de cet actif a-t-on vraiment mise on-chain ?
@Dusk $DUSK #duks
9
3
130
·
--
#dusk $DUSK J’ai remarqué quelque chose d’étrange en regardant l’activité de DUSK.
Pourquoi une chaîne axée sur la confidentialité garderait-elle volontairement un système de transactions publiques ?
Imaginez une banque avec deux portes.
Une porte s’ouvre sur un hall public.
Tout le monde peut voir qui est entré et ce qui s’est passé.
L’autre mène dans une salle privée.
Seules les personnes concernées connaissent les détails.
C’est étonnamment proche de la façon dont DUSK fonctionne.
Moonlight est la porte publique : les comptes, les soldes, l’expéditeur, le destinataire et les montants peuvent être visibles.
Phoenix est la porte privée : les fonds circulent sous forme de notes protégées, avec des preuves à divulgation nulle (zero-knowledge) qui dissimulent les détails sensibles des transactions.
Et ce n’est pas qu’une théorie.
En observant l’activité en chaîne de DUSK, les deux modèles de transaction sont en réalité utilisés — des transactions publiques Moonlight en parallèle avec l’activité protégée de Phoenix.
Alors pourquoi en construire deux ?
Parce que l’infrastructure financière n’a pas besoin de “tout garder privé”.
Certains flux ont besoin de transparence.
D’autres ont besoin de confidentialité.
Le pari intéressant de DUSK, c’est que la confidentialité doit être un outil que vous pouvez utiliser, et non une règle imposée à chaque transaction.
Cela ressemble beaucoup plus à la manière dont fonctionnent réellement les marchés financiers.
#dusk $DUSK @Dusk_Foundation
#dusk $DUSK J’ai remarqué quelque chose d’étrange en regardant l’activité de DUSK.
Pourquoi une chaîne axée sur la confidentialité garderait-elle volontairement un système de transactions publiques ?
Imaginez une banque avec deux portes.
Une porte s’ouvre sur un hall public.
Tout le monde peut voir qui est entré et ce qui s’est passé.
L’autre mène dans une salle privée.
Seules les personnes concernées connaissent les détails.
C’est étonnamment proche de la façon dont DUSK fonctionne.
Moonlight est la porte publique : les comptes, les soldes, l’expéditeur, le destinataire et les montants peuvent être visibles.
Phoenix est la porte privée : les fonds circulent sous forme de notes protégées, avec des preuves à divulgation nulle (zero-knowledge) qui dissimulent les détails sensibles des transactions.
Et ce n’est pas qu’une théorie.
En observant l’activité en chaîne de DUSK, les deux modèles de transaction sont en réalité utilisés — des transactions publiques Moonlight en parallèle avec l’activité protégée de Phoenix.
Alors pourquoi en construire deux ?
Parce que l’infrastructure financière n’a pas besoin de “tout garder privé”.
Certains flux ont besoin de transparence.
D’autres ont besoin de confidentialité.
Le pari intéressant de DUSK, c’est que la confidentialité doit être un outil que vous pouvez utiliser, et non une règle imposée à chaque transaction.
Cela ressemble beaucoup plus à la manière dont fonctionnent réellement les marchés financiers.
#dusk $DUSK @Dusk
Pourquoi une chaîne axée sur la confidentialité garderait-elle volontairement un système de transactions publiques ?
Imaginez une banque avec deux portes.
Une porte s’ouvre sur un hall public.
Tout le monde peut voir qui est entré et ce qui s’est passé.
L’autre mène dans une salle privée.
Seules les personnes concernées connaissent les détails.
C’est étonnamment proche de la façon dont DUSK fonctionne.
Moonlight est la porte publique : les comptes, les soldes, l’expéditeur, le destinataire et les montants peuvent être visibles.
Phoenix est la porte privée : les fonds circulent sous forme de notes protégées, avec des preuves à divulgation nulle (zero-knowledge) qui dissimulent les détails sensibles des transactions.
Et ce n’est pas qu’une théorie.
En observant l’activité en chaîne de DUSK, les deux modèles de transaction sont en réalité utilisés — des transactions publiques Moonlight en parallèle avec l’activité protégée de Phoenix.
Alors pourquoi en construire deux ?
Parce que l’infrastructure financière n’a pas besoin de “tout garder privé”.
Certains flux ont besoin de transparence.
D’autres ont besoin de confidentialité.
Le pari intéressant de DUSK, c’est que la confidentialité doit être un outil que vous pouvez utiliser, et non une règle imposée à chaque transaction.
Cela ressemble beaucoup plus à la manière dont fonctionnent réellement les marchés financiers.
#dusk $DUSK @Dusk
7
4
93
·
--
#dusk $DUSK Pourquoi construire un coffre-fort privé… puis donner une clé à quelqu’un ?
Imaginez conserver vos documents financiers dans une pièce verrouillée.
Vous ne voulez pas que chaque visiteur les lise.
Mais lorsqu’un auditeur arrive, vous avez quand même besoin d’un moyen de prouver ce qu’il y a à l’intérieur.
C’est là que les clés de visualisation Phoenix de DUSK ont attiré mon attention.
Phoenix protège les détails des transactions, mais les clés de visualisation permettent aux utilisateurs de révéler sélectivement des informations aux parties autorisées.
Ainsi, la confidentialité ne signifie pas :
« Tout cacher pour toujours. »
Cela signifie :
« Décider qui a le droit de voir quoi. »
C’est essentiel pour les marchés financiers, car un investisseur peut ne pas vouloir que ses transactions soient exposées à tout le monde sur la chaîne, tandis qu’un auditeur ou une partie autorisée peut tout de même avoir besoin de preuves spécifiques.
DUSK a adopté cette approche parce que la finance réglementée doit concilier confidentialité et responsabilité.
C’est une définition de la confidentialité beaucoup plus concrète.
@DuskFoundation $DUSK
#DUSK $DUSK #dusk @Dusk_Foundation
#dusk $DUSK Pourquoi construire un coffre-fort privé… puis donner une clé à quelqu’un ?
Imaginez conserver vos documents financiers dans une pièce verrouillée.
Vous ne voulez pas que chaque visiteur les lise.
Mais lorsqu’un auditeur arrive, vous avez quand même besoin d’un moyen de prouver ce qu’il y a à l’intérieur.
C’est là que les clés de visualisation Phoenix de DUSK ont attiré mon attention.
Phoenix protège les détails des transactions, mais les clés de visualisation permettent aux utilisateurs de révéler sélectivement des informations aux parties autorisées.
Ainsi, la confidentialité ne signifie pas :
« Tout cacher pour toujours. »
Cela signifie :
« Décider qui a le droit de voir quoi. »
C’est essentiel pour les marchés financiers, car un investisseur peut ne pas vouloir que ses transactions soient exposées à tout le monde sur la chaîne, tandis qu’un auditeur ou une partie autorisée peut tout de même avoir besoin de preuves spécifiques.
DUSK a adopté cette approche parce que la finance réglementée doit concilier confidentialité et responsabilité.
C’est une définition de la confidentialité beaucoup plus concrète.
@DuskFoundation $DUSK
#DUSK $DUSK #dusk @Dusk
Imaginez conserver vos documents financiers dans une pièce verrouillée.
Vous ne voulez pas que chaque visiteur les lise.
Mais lorsqu’un auditeur arrive, vous avez quand même besoin d’un moyen de prouver ce qu’il y a à l’intérieur.
C’est là que les clés de visualisation Phoenix de DUSK ont attiré mon attention.
Phoenix protège les détails des transactions, mais les clés de visualisation permettent aux utilisateurs de révéler sélectivement des informations aux parties autorisées.
Ainsi, la confidentialité ne signifie pas :
« Tout cacher pour toujours. »
Cela signifie :
« Décider qui a le droit de voir quoi. »
C’est essentiel pour les marchés financiers, car un investisseur peut ne pas vouloir que ses transactions soient exposées à tout le monde sur la chaîne, tandis qu’un auditeur ou une partie autorisée peut tout de même avoir besoin de preuves spécifiques.
DUSK a adopté cette approche parce que la finance réglementée doit concilier confidentialité et responsabilité.
C’est une définition de la confidentialité beaucoup plus concrète.
@DuskFoundation $DUSK
#DUSK $DUSK #dusk @Dusk
12
5
315
·
--
Haussier
#baby $BABY Avez-vous déjà remarqué que la plupart des arguments ne portent pas sur ce qui s’est passé, mais sur le moment où cela s’est passé ?
Je l’ai réalisé en écoutant deux amis raconter la même histoire d’un voyage que nous avons fait ensemble.
Aucun des deux n’inventait. Ils se souvenaient simplement de l’ordre des événements différemment, et d’une certaine façon cela a changé toute l’histoire.
Cela m’a fait penser aux blockchains.
À mesure que davantage de réseaux commencent à interagir, ils ont aussi besoin d’une manière partagée de s’accorder sur l’historique. Sinon, chacun peut finir par croire sa propre version de ce qui s’est passé en premier.
C’est l’une des choses qui m’a semblé intéressantes à propos de Babylon.
Au lieu de demander à chaque chaîne de faire confiance à la chronologie d’une autre, Babylon leur permet d’ancrer des points de contrôle importants sur Bitcoin. Cela donne aux réseaux indépendants un point de référence commun quand la finalité compte vraiment.
Au début, je me suis demandé pourquoi Babylon avait choisi cette approche plutôt que de simplement rendre tout plus rapide.
Puis j’ai compris : quand on protège la valeur, la certitude prime souvent sur la vitesse.
Il y a, bien sûr, un compromis. Attendre une finalité adossée à Bitcoin peut prendre plus de temps que de se fier uniquement à la confirmation locale. Mais si l’objectif est d’empêcher des histoires contradictoires, ce temps supplémentaire finit par ressembler moins à un retard qu’à une protection.
Peut-être que l’avenir de Bitcoin n’est pas seulement d’être l’endroit le plus fiable pour stocker de la valeur.
Peut-être que c’est en train de devenir l’endroit vers lequel d’autres réseaux se tournent quand ils ont besoin de certitude.
$BABY #Babylon #BTCFi
$BABY #baby @babylonlabs_io
#baby $BABY Avez-vous déjà remarqué que la plupart des arguments ne portent pas sur ce qui s’est passé, mais sur le moment où cela s’est passé ?
Je l’ai réalisé en écoutant deux amis raconter la même histoire d’un voyage que nous avons fait ensemble.
Aucun des deux n’inventait. Ils se souvenaient simplement de l’ordre des événements différemment, et d’une certaine façon cela a changé toute l’histoire.
Cela m’a fait penser aux blockchains.
À mesure que davantage de réseaux commencent à interagir, ils ont aussi besoin d’une manière partagée de s’accorder sur l’historique. Sinon, chacun peut finir par croire sa propre version de ce qui s’est passé en premier.
C’est l’une des choses qui m’a semblé intéressantes à propos de Babylon.
Au lieu de demander à chaque chaîne de faire confiance à la chronologie d’une autre, Babylon leur permet d’ancrer des points de contrôle importants sur Bitcoin. Cela donne aux réseaux indépendants un point de référence commun quand la finalité compte vraiment.
Au début, je me suis demandé pourquoi Babylon avait choisi cette approche plutôt que de simplement rendre tout plus rapide.
Puis j’ai compris : quand on protège la valeur, la certitude prime souvent sur la vitesse.
Il y a, bien sûr, un compromis. Attendre une finalité adossée à Bitcoin peut prendre plus de temps que de se fier uniquement à la confirmation locale. Mais si l’objectif est d’empêcher des histoires contradictoires, ce temps supplémentaire finit par ressembler moins à un retard qu’à une protection.
Peut-être que l’avenir de Bitcoin n’est pas seulement d’être l’endroit le plus fiable pour stocker de la valeur.
Peut-être que c’est en train de devenir l’endroit vers lequel d’autres réseaux se tournent quand ils ont besoin de certitude.
$BABY #Babylon #BTCFi
$BABY #baby @BabylonLabs_io
Je l’ai réalisé en écoutant deux amis raconter la même histoire d’un voyage que nous avons fait ensemble.
Aucun des deux n’inventait. Ils se souvenaient simplement de l’ordre des événements différemment, et d’une certaine façon cela a changé toute l’histoire.
Cela m’a fait penser aux blockchains.
À mesure que davantage de réseaux commencent à interagir, ils ont aussi besoin d’une manière partagée de s’accorder sur l’historique. Sinon, chacun peut finir par croire sa propre version de ce qui s’est passé en premier.
C’est l’une des choses qui m’a semblé intéressantes à propos de Babylon.
Au lieu de demander à chaque chaîne de faire confiance à la chronologie d’une autre, Babylon leur permet d’ancrer des points de contrôle importants sur Bitcoin. Cela donne aux réseaux indépendants un point de référence commun quand la finalité compte vraiment.
Au début, je me suis demandé pourquoi Babylon avait choisi cette approche plutôt que de simplement rendre tout plus rapide.
Puis j’ai compris : quand on protège la valeur, la certitude prime souvent sur la vitesse.
Il y a, bien sûr, un compromis. Attendre une finalité adossée à Bitcoin peut prendre plus de temps que de se fier uniquement à la confirmation locale. Mais si l’objectif est d’empêcher des histoires contradictoires, ce temps supplémentaire finit par ressembler moins à un retard qu’à une protection.
Peut-être que l’avenir de Bitcoin n’est pas seulement d’être l’endroit le plus fiable pour stocker de la valeur.
Peut-être que c’est en train de devenir l’endroit vers lequel d’autres réseaux se tournent quand ils ont besoin de certitude.
$BABY #Babylon #BTCFi
$BABY #baby @BabylonLabs_io
6
2
150
·
--
#baby $BABY Avez-vous déjà remarqué que les équipes les plus solides n’attendent pas que tout le monde fasse tout ?
Je m’en suis rendu compte en regardant un match de cricket local.
Le capitaine n’était pas le lanceur le plus rapide. Le gardien de guichet ne commençait pas au bâton. Chacun avait un rôle différent, et d’une certaine manière, cela rendait l’équipe plus forte.
Cette idée m’est revenue en lisant au sujet de Babylone.
Une chose qui m’a semblé intéressante, c’est que les détenteurs de Bitcoin n’ont pas besoin d’effectuer eux-mêmes tout le travail technique. Babylone introduit des Finality Providers (fournisseurs de finalité), dont le rôle est d’aider à finaliser les blocs et à sécuriser le réseau, tandis que les détenteurs de BTC peuvent contribuer à la sécurité via le staking.
Au début, je me suis demandé pourquoi Babylone ne demandait pas simplement à chaque staker de tout gérer.
Puis cela a eu du sens. La plupart des détenteurs de Bitcoin veulent simplement soutenir le réseau sans exécuter une infrastructure complexe. En séparant ces responsabilités, Babylone rend la participation plus pratique tout en confiant les tâches critiques à des opérateurs spécialisés.
Bien sûr, il y a un compromis. Ces opérateurs portent plus de responsabilités, c’est pourquoi le protocole a besoin d’incitations solides et de mécanismes de responsabilité pour maintenir le système sécurisé.
Plus j’y pense, plus j’apprécie les conceptions qui n’attendent pas que tout le monde fasse le même travail. Parfois, un réseau plus fort naît du fait de donner à chaque participant un rôle qu’il peut réellement accomplir au mieux.
$BABY #Babylon #BTCFi
$BABY #baby @babylonlabs_io
#baby $BABY Avez-vous déjà remarqué que les équipes les plus solides n’attendent pas que tout le monde fasse tout ?
Je m’en suis rendu compte en regardant un match de cricket local.
Le capitaine n’était pas le lanceur le plus rapide. Le gardien de guichet ne commençait pas au bâton. Chacun avait un rôle différent, et d’une certaine manière, cela rendait l’équipe plus forte.
Cette idée m’est revenue en lisant au sujet de Babylone.
Une chose qui m’a semblé intéressante, c’est que les détenteurs de Bitcoin n’ont pas besoin d’effectuer eux-mêmes tout le travail technique. Babylone introduit des Finality Providers (fournisseurs de finalité), dont le rôle est d’aider à finaliser les blocs et à sécuriser le réseau, tandis que les détenteurs de BTC peuvent contribuer à la sécurité via le staking.
Au début, je me suis demandé pourquoi Babylone ne demandait pas simplement à chaque staker de tout gérer.
Puis cela a eu du sens. La plupart des détenteurs de Bitcoin veulent simplement soutenir le réseau sans exécuter une infrastructure complexe. En séparant ces responsabilités, Babylone rend la participation plus pratique tout en confiant les tâches critiques à des opérateurs spécialisés.
Bien sûr, il y a un compromis. Ces opérateurs portent plus de responsabilités, c’est pourquoi le protocole a besoin d’incitations solides et de mécanismes de responsabilité pour maintenir le système sécurisé.
Plus j’y pense, plus j’apprécie les conceptions qui n’attendent pas que tout le monde fasse le même travail. Parfois, un réseau plus fort naît du fait de donner à chaque participant un rôle qu’il peut réellement accomplir au mieux.
$BABY #Babylon #BTCFi
$BABY #baby @BabylonLabs_io
Je m’en suis rendu compte en regardant un match de cricket local.
Le capitaine n’était pas le lanceur le plus rapide. Le gardien de guichet ne commençait pas au bâton. Chacun avait un rôle différent, et d’une certaine manière, cela rendait l’équipe plus forte.
Cette idée m’est revenue en lisant au sujet de Babylone.
Une chose qui m’a semblé intéressante, c’est que les détenteurs de Bitcoin n’ont pas besoin d’effectuer eux-mêmes tout le travail technique. Babylone introduit des Finality Providers (fournisseurs de finalité), dont le rôle est d’aider à finaliser les blocs et à sécuriser le réseau, tandis que les détenteurs de BTC peuvent contribuer à la sécurité via le staking.
Au début, je me suis demandé pourquoi Babylone ne demandait pas simplement à chaque staker de tout gérer.
Puis cela a eu du sens. La plupart des détenteurs de Bitcoin veulent simplement soutenir le réseau sans exécuter une infrastructure complexe. En séparant ces responsabilités, Babylone rend la participation plus pratique tout en confiant les tâches critiques à des opérateurs spécialisés.
Bien sûr, il y a un compromis. Ces opérateurs portent plus de responsabilités, c’est pourquoi le protocole a besoin d’incitations solides et de mécanismes de responsabilité pour maintenir le système sécurisé.
Plus j’y pense, plus j’apprécie les conceptions qui n’attendent pas que tout le monde fasse le même travail. Parfois, un réseau plus fort naît du fait de donner à chaque participant un rôle qu’il peut réellement accomplir au mieux.
$BABY #Babylon #BTCFi
$BABY #baby @BabylonLabs_io
10
4
144
·
--
#baby $BABY Et si la chose la plus précieuse que Bitcoin puisse offrir n’était pas l’argent… mais le temps ?
Cette question m’a surpris lorsque je lisais à propos de Babylon.
J’ai toujours considéré Bitcoin comme l’endroit où la valeur est stockée. Je n’aurais jamais imaginé qu’une chose aussi simple qu’un horodatage puisse en être l’une de ses plus grandes forces.
Pensez-y de cette façon. Si quelqu’un écrit un événement dans un carnet aujourd’hui, tout le monde pourrait ensuite contester à quel moment il a réellement été rédigé. Mais si le même événement est enregistré de manière permanente sur Bitcoin, modifier son historique devient incroyablement difficile.
C’est ce qui m’a intéressé dans le mécanisme d’horodatage de Babylon. Au lieu de demander à d’autres réseaux de se faire confiance aveuglément, il leur permet d’ancrer des jalons importants dans la chronologie de Bitcoin. Ainsi, chacun peut vérifier quand quelque chose s’est produit, sans dépendre d’une seule partie.
Plus j’en apprenais, plus je me disais que l’avenir de Bitcoin ne portera peut-être pas seulement sur la protection de la richesse. Il pourrait aussi devenir l’horloge qui aide d’autres réseaux de blockchain à rester honnêtes.
C’est un rôle que je n’avais jamais prévu pour Bitcoin.
$BABY #Babylon #BTCFi
$BABY #baby @babylonlabs_io
#baby $BABY Et si la chose la plus précieuse que Bitcoin puisse offrir n’était pas l’argent… mais le temps ?
Cette question m’a surpris lorsque je lisais à propos de Babylon.
J’ai toujours considéré Bitcoin comme l’endroit où la valeur est stockée. Je n’aurais jamais imaginé qu’une chose aussi simple qu’un horodatage puisse en être l’une de ses plus grandes forces.
Pensez-y de cette façon. Si quelqu’un écrit un événement dans un carnet aujourd’hui, tout le monde pourrait ensuite contester à quel moment il a réellement été rédigé. Mais si le même événement est enregistré de manière permanente sur Bitcoin, modifier son historique devient incroyablement difficile.
C’est ce qui m’a intéressé dans le mécanisme d’horodatage de Babylon. Au lieu de demander à d’autres réseaux de se faire confiance aveuglément, il leur permet d’ancrer des jalons importants dans la chronologie de Bitcoin. Ainsi, chacun peut vérifier quand quelque chose s’est produit, sans dépendre d’une seule partie.
Plus j’en apprenais, plus je me disais que l’avenir de Bitcoin ne portera peut-être pas seulement sur la protection de la richesse. Il pourrait aussi devenir l’horloge qui aide d’autres réseaux de blockchain à rester honnêtes.
C’est un rôle que je n’avais jamais prévu pour Bitcoin.
$BABY #Babylon #BTCFi
$BABY #baby @BabylonLabs_io
Cette question m’a surpris lorsque je lisais à propos de Babylon.
J’ai toujours considéré Bitcoin comme l’endroit où la valeur est stockée. Je n’aurais jamais imaginé qu’une chose aussi simple qu’un horodatage puisse en être l’une de ses plus grandes forces.
Pensez-y de cette façon. Si quelqu’un écrit un événement dans un carnet aujourd’hui, tout le monde pourrait ensuite contester à quel moment il a réellement été rédigé. Mais si le même événement est enregistré de manière permanente sur Bitcoin, modifier son historique devient incroyablement difficile.
C’est ce qui m’a intéressé dans le mécanisme d’horodatage de Babylon. Au lieu de demander à d’autres réseaux de se faire confiance aveuglément, il leur permet d’ancrer des jalons importants dans la chronologie de Bitcoin. Ainsi, chacun peut vérifier quand quelque chose s’est produit, sans dépendre d’une seule partie.
Plus j’en apprenais, plus je me disais que l’avenir de Bitcoin ne portera peut-être pas seulement sur la protection de la richesse. Il pourrait aussi devenir l’horloge qui aide d’autres réseaux de blockchain à rester honnêtes.
C’est un rôle que je n’avais jamais prévu pour Bitcoin.
$BABY #Babylon #BTCFi
$BABY #baby @BabylonLabs_io
21
4
131
·
--
#baby $BABY Je pensais toujours que la partie la plus difficile de la construction d’une blockchain, c’était la technologie. Maintenant, je n’en suis plus aussi sûr.
Une conversation avec un ami a changé ma façon de voir les choses. Nous discutions de nouveaux projets, et il m’a posé une question simple : « Qui a vraiment une chance équitable d’en faire partie ? »
Je n’ai pas eu de réponse tout de suite.
Plus j’y pensais, plus je me rendais compte que la distribution ne consiste pas seulement à distribuer des tokens. Elle façonne les personnes qui rejoignent tôt, celles qui aident à sécuriser le réseau, et celles qui grandissent avec l’écosystème au fil du temps.
C’est pourquoi Babylon a retenu mon attention. Si son mécanisme de distribution est conçu pour rendre la participation plus accessible au lieu de récompenser uniquement un petit groupe, alors il fait plus que lancer un token. Il donne le ton à la communauté qu’il veut construire.
Au final, la technologie de qualité compte. Mais parfois, la façon dont les gens sont invités compte tout autant.
$BABY #Babylon #BTCFi
$BABY #baby @babylonlabs_io
#baby $BABY Je pensais toujours que la partie la plus difficile de la construction d’une blockchain, c’était la technologie. Maintenant, je n’en suis plus aussi sûr.
Une conversation avec un ami a changé ma façon de voir les choses. Nous discutions de nouveaux projets, et il m’a posé une question simple : « Qui a vraiment une chance équitable d’en faire partie ? »
Je n’ai pas eu de réponse tout de suite.
Plus j’y pensais, plus je me rendais compte que la distribution ne consiste pas seulement à distribuer des tokens. Elle façonne les personnes qui rejoignent tôt, celles qui aident à sécuriser le réseau, et celles qui grandissent avec l’écosystème au fil du temps.
C’est pourquoi Babylon a retenu mon attention. Si son mécanisme de distribution est conçu pour rendre la participation plus accessible au lieu de récompenser uniquement un petit groupe, alors il fait plus que lancer un token. Il donne le ton à la communauté qu’il veut construire.
Au final, la technologie de qualité compte. Mais parfois, la façon dont les gens sont invités compte tout autant.
$BABY #Babylon #BTCFi
$BABY #baby @BabylonLabs_io
Une conversation avec un ami a changé ma façon de voir les choses. Nous discutions de nouveaux projets, et il m’a posé une question simple : « Qui a vraiment une chance équitable d’en faire partie ? »
Je n’ai pas eu de réponse tout de suite.
Plus j’y pensais, plus je me rendais compte que la distribution ne consiste pas seulement à distribuer des tokens. Elle façonne les personnes qui rejoignent tôt, celles qui aident à sécuriser le réseau, et celles qui grandissent avec l’écosystème au fil du temps.
C’est pourquoi Babylon a retenu mon attention. Si son mécanisme de distribution est conçu pour rendre la participation plus accessible au lieu de récompenser uniquement un petit groupe, alors il fait plus que lancer un token. Il donne le ton à la communauté qu’il veut construire.
Au final, la technologie de qualité compte. Mais parfois, la façon dont les gens sont invités compte tout autant.
$BABY #Babylon #BTCFi
$BABY #baby @BabylonLabs_io
8
2
83
·
--
#baby $BABY Voici une version plus humaine et réfléchie, qui ressemble à l’analyse d’une vraie personne plutôt qu’à un contenu promotionnel :
Et si Bitcoin n’avait jamais eu à choisir entre sécurité et utilité ?
Cette idée m’est venue en rattrapant un vieil ami. Il détient du BTC depuis des années, mais à chaque fois que la DeFi était abordée, il avait la même réponse : « Je ne veux pas déplacer mon Bitcoin juste pour gagner un peu plus. » Je ne pouvais pas le lui reprocher. La plupart des options donnaient l’impression d’échanger une certitude contre une opportunité.
Plus je me suis plongé dans Babylon, plus j’ai compris que la conversation pourrait être en train de changer. Au lieu de retirer le BTC natif de Bitcoin, l’idée est de le laisser devenir une garantie rapide pour la DeFi tout en restant natif. Cela ressemble à une direction très différente.
Si cette approche fait ses preuves au fil du temps, elle pourrait faire tomber l’un des plus grands obstacles psychologiques pour les détenteurs de Bitcoin sur le long terme. Peut-être que l’avenir du BTCFi n’est pas de convaincre les gens de faire confiance à quelque chose de nouveau : c’est de leur offrir un moyen d’utiliser ce qu’ils ont déjà appris à considérer comme fiable.
$BABY #Babylon #BTCFi
$BABY #baby @babylonlabs_io
#baby $BABY Voici une version plus humaine et réfléchie, qui ressemble à l’analyse d’une vraie personne plutôt qu’à un contenu promotionnel :
Et si Bitcoin n’avait jamais eu à choisir entre sécurité et utilité ?
Cette idée m’est venue en rattrapant un vieil ami. Il détient du BTC depuis des années, mais à chaque fois que la DeFi était abordée, il avait la même réponse : « Je ne veux pas déplacer mon Bitcoin juste pour gagner un peu plus. » Je ne pouvais pas le lui reprocher. La plupart des options donnaient l’impression d’échanger une certitude contre une opportunité.
Plus je me suis plongé dans Babylon, plus j’ai compris que la conversation pourrait être en train de changer. Au lieu de retirer le BTC natif de Bitcoin, l’idée est de le laisser devenir une garantie rapide pour la DeFi tout en restant natif. Cela ressemble à une direction très différente.
Si cette approche fait ses preuves au fil du temps, elle pourrait faire tomber l’un des plus grands obstacles psychologiques pour les détenteurs de Bitcoin sur le long terme. Peut-être que l’avenir du BTCFi n’est pas de convaincre les gens de faire confiance à quelque chose de nouveau : c’est de leur offrir un moyen d’utiliser ce qu’ils ont déjà appris à considérer comme fiable.
$BABY #Babylon #BTCFi
$BABY #baby @BabylonLabs_io
Et si Bitcoin n’avait jamais eu à choisir entre sécurité et utilité ?
Cette idée m’est venue en rattrapant un vieil ami. Il détient du BTC depuis des années, mais à chaque fois que la DeFi était abordée, il avait la même réponse : « Je ne veux pas déplacer mon Bitcoin juste pour gagner un peu plus. » Je ne pouvais pas le lui reprocher. La plupart des options donnaient l’impression d’échanger une certitude contre une opportunité.
Plus je me suis plongé dans Babylon, plus j’ai compris que la conversation pourrait être en train de changer. Au lieu de retirer le BTC natif de Bitcoin, l’idée est de le laisser devenir une garantie rapide pour la DeFi tout en restant natif. Cela ressemble à une direction très différente.
Si cette approche fait ses preuves au fil du temps, elle pourrait faire tomber l’un des plus grands obstacles psychologiques pour les détenteurs de Bitcoin sur le long terme. Peut-être que l’avenir du BTCFi n’est pas de convaincre les gens de faire confiance à quelque chose de nouveau : c’est de leur offrir un moyen d’utiliser ce qu’ils ont déjà appris à considérer comme fiable.
$BABY #Babylon #BTCFi
$BABY #baby @BabylonLabs_io
11
5
167
·
--
#baby $BABY Je connais très bien ce sentiment de naufrage.
Voir des fonds disparaître parce qu’un pont que vous aviez confiance en vous effondre soudainement, c’est brutal.
Sans avertissement. Juste un solde à zéro qui vous fait face.
Cela vous fait réaliser à quel point il est risqué de s’en remettre à des ponts douteux ou à des comités multi-signataires centralisés.
Cette frustration précise est la raison pour laquelle les détenteurs de $baby en ont assez des promesses vides et veulent une sécurité irréprochable.
C’est là que EOTS change tout.
Au lieu d’espérer qu’un comité punisse réellement les mauvais acteurs, le protocole le fait par le biais d’une logique purement mathématique.
Si un validateur tente de double-sign et de tromper le réseau, sa clé privée est divulguée directement on-chain comme sanction immédiate.
La vraie décentralisation ne consiste pas à faire confiance aux gens pour faire ce qu’il faut.
Il s’agit de créer un système où la triche est mathématiquement impossible.
Les mathématiques gagnent toujours.
Honnêtement, ça donne à réfléchir — si la sécurité devient totalement auto-exécutoire, combien de temps avant que les ponts traditionnels ne deviennent une chose du passé ?$BABY #baby @babylonlabs_io
#baby $BABY Je connais très bien ce sentiment de naufrage.
Voir des fonds disparaître parce qu’un pont que vous aviez confiance en vous effondre soudainement, c’est brutal.
Sans avertissement. Juste un solde à zéro qui vous fait face.
Cela vous fait réaliser à quel point il est risqué de s’en remettre à des ponts douteux ou à des comités multi-signataires centralisés.
Cette frustration précise est la raison pour laquelle les détenteurs de $baby en ont assez des promesses vides et veulent une sécurité irréprochable.
C’est là que EOTS change tout.
Au lieu d’espérer qu’un comité punisse réellement les mauvais acteurs, le protocole le fait par le biais d’une logique purement mathématique.
Si un validateur tente de double-sign et de tromper le réseau, sa clé privée est divulguée directement on-chain comme sanction immédiate.
La vraie décentralisation ne consiste pas à faire confiance aux gens pour faire ce qu’il faut.
Il s’agit de créer un système où la triche est mathématiquement impossible.
Les mathématiques gagnent toujours.
Honnêtement, ça donne à réfléchir — si la sécurité devient totalement auto-exécutoire, combien de temps avant que les ponts traditionnels ne deviennent une chose du passé ?$BABY #baby @BabylonLabs_io
Voir des fonds disparaître parce qu’un pont que vous aviez confiance en vous effondre soudainement, c’est brutal.
Sans avertissement. Juste un solde à zéro qui vous fait face.
Cela vous fait réaliser à quel point il est risqué de s’en remettre à des ponts douteux ou à des comités multi-signataires centralisés.
Cette frustration précise est la raison pour laquelle les détenteurs de $baby en ont assez des promesses vides et veulent une sécurité irréprochable.
C’est là que EOTS change tout.
Au lieu d’espérer qu’un comité punisse réellement les mauvais acteurs, le protocole le fait par le biais d’une logique purement mathématique.
Si un validateur tente de double-sign et de tromper le réseau, sa clé privée est divulguée directement on-chain comme sanction immédiate.
La vraie décentralisation ne consiste pas à faire confiance aux gens pour faire ce qu’il faut.
Il s’agit de créer un système où la triche est mathématiquement impossible.
Les mathématiques gagnent toujours.
Honnêtement, ça donne à réfléchir — si la sécurité devient totalement auto-exécutoire, combien de temps avant que les ponts traditionnels ne deviennent une chose du passé ?$BABY #baby @BabylonLabs_io
2
2
130
·
--
#newt $NEWT Quelque chose s’est déclenché pour moi aujourd’hui.
Dès qu’il y a un piratage ou une mauvaise transaction, tout le monde commence à parler de sécurité. Mais à ce moment-là, la transaction a déjà eu lieu.
Cela m’a fait me demander pourquoi on accepte ça comme une norme.
Peut-être que la plus grande amélioration n’est pas de réagir plus vite. Peut-être que c’est d’empêcher des transactions risquées avant même qu’elles ne soient exécutées.
C’est l’une des raisons pour lesquelles je suis de près @NewtonProtocol . Newton Protocol construit un réseau d’infrastructure décentralisé pour héberger, exécuter et vérifier des modèles d’IA. Ce qui m’intéresse, c’est qu’il s’oriente vers l’évaluation du risque avant l’exécution, tout en séparant l’inférence de la vérification, afin que l’IA puisse répondre rapidement et que les preuves puissent être confirmées ensuite.
Si cette idée fonctionne dans la pratique, elle pourrait changer la manière dont la finance on-chain gère la confiance. L’opportunité est immense. Dans le même temps, une bonne infrastructure a encore besoin d’une adoption réelle, et rien ne le garantit jamais.
C’est pourquoi je pense que cela mérite d’être surveillé : pas parce que j’attends des résultats immédiats, mais parce que l’orientation elle-même me semble différente.
Si l’IA doit prendre davantage de décisions on-chain, la priorité devrait-elle être de corriger les erreurs après coup, ou de les empêcher avant qu’elles ne se produisent ? $NEWT #Newt @NewtonProtocol
#newt $NEWT Quelque chose s’est déclenché pour moi aujourd’hui.
Dès qu’il y a un piratage ou une mauvaise transaction, tout le monde commence à parler de sécurité. Mais à ce moment-là, la transaction a déjà eu lieu.
Cela m’a fait me demander pourquoi on accepte ça comme une norme.
Peut-être que la plus grande amélioration n’est pas de réagir plus vite. Peut-être que c’est d’empêcher des transactions risquées avant même qu’elles ne soient exécutées.
C’est l’une des raisons pour lesquelles je suis de près @NewtonProtocol . Newton Protocol construit un réseau d’infrastructure décentralisé pour héberger, exécuter et vérifier des modèles d’IA. Ce qui m’intéresse, c’est qu’il s’oriente vers l’évaluation du risque avant l’exécution, tout en séparant l’inférence de la vérification, afin que l’IA puisse répondre rapidement et que les preuves puissent être confirmées ensuite.
Si cette idée fonctionne dans la pratique, elle pourrait changer la manière dont la finance on-chain gère la confiance. L’opportunité est immense. Dans le même temps, une bonne infrastructure a encore besoin d’une adoption réelle, et rien ne le garantit jamais.
C’est pourquoi je pense que cela mérite d’être surveillé : pas parce que j’attends des résultats immédiats, mais parce que l’orientation elle-même me semble différente.
Si l’IA doit prendre davantage de décisions on-chain, la priorité devrait-elle être de corriger les erreurs après coup, ou de les empêcher avant qu’elles ne se produisent ? $NEWT #Newt @NewtonProtocol
Dès qu’il y a un piratage ou une mauvaise transaction, tout le monde commence à parler de sécurité. Mais à ce moment-là, la transaction a déjà eu lieu.
Cela m’a fait me demander pourquoi on accepte ça comme une norme.
Peut-être que la plus grande amélioration n’est pas de réagir plus vite. Peut-être que c’est d’empêcher des transactions risquées avant même qu’elles ne soient exécutées.
C’est l’une des raisons pour lesquelles je suis de près @NewtonProtocol . Newton Protocol construit un réseau d’infrastructure décentralisé pour héberger, exécuter et vérifier des modèles d’IA. Ce qui m’intéresse, c’est qu’il s’oriente vers l’évaluation du risque avant l’exécution, tout en séparant l’inférence de la vérification, afin que l’IA puisse répondre rapidement et que les preuves puissent être confirmées ensuite.
Si cette idée fonctionne dans la pratique, elle pourrait changer la manière dont la finance on-chain gère la confiance. L’opportunité est immense. Dans le même temps, une bonne infrastructure a encore besoin d’une adoption réelle, et rien ne le garantit jamais.
C’est pourquoi je pense que cela mérite d’être surveillé : pas parce que j’attends des résultats immédiats, mais parce que l’orientation elle-même me semble différente.
Si l’IA doit prendre davantage de décisions on-chain, la priorité devrait-elle être de corriger les erreurs après coup, ou de les empêcher avant qu’elles ne se produisent ? $NEWT #Newt @NewtonProtocol
2
2
91
Connectez-vous pour découvrir plus de contenu
Rejoignez la communauté mondiale des adeptes de cryptomonnaies sur Binance Square
⚡️ Suviez les dernières informations importantes sur les cryptomonnaies.
💬 Jugé digne de confiance par la plus grande plateforme d’échange de cryptomonnaies au monde.
👍 Découvrez les connaissances que partagent les créateurs vérifiés.
Adresse e-mail/Nº de téléphone
Sujets d’actualité
BitcoinHoldsAbove$77000
0 vues
20 mentions
Je décide d’ouvrir un énorme long sur $BTC 💀🔥
Le BTC respecte la tendance de la ligne 4H puis va pomper
Entrée : 76826 - 76500
Profit : 76900 - 77000 - 77300
Stop loss : 76400
Garde aussi long $LSK et $POWR
LedgerXpert
·2 mentions J’aime
·831 vues
BitcoinCrosses$78000
1,539 vues
103 mentions
AvalancheIntegratesIntoUAEPassDigitalVault
5,625 vues
215 mentions