Lữ Khách Web3

Có một điểm khiến tôi dừng lại khi đọc về Dusk Network đó là: nếu blockchain vốn được xây dựng quanh tính minh bạch tại sao một mạng hướng tới tài chính tổ chức lại phải đặt privacy ở vị trí khá quan trọng?
Ban đầu tôi nghĩ đây có thể chỉ là cách định vị sản phẩm nhưng khi đọc tài liệu của Dusk kỹ hơn, vấn đề bắt đầu rõ hơn. Dusk mô tả các ứng dụng tài chính cần bảo vệ balance, position, counterparty và business logic thay vì đưa toàn bộ trạng thái lên public ledger.
Tôi tiếp tục kiểm tra cách họ xử lý vấn đề này. Dusk không đơn giản nói “ẩn dữ liệu”. Kiến trúc hiện tại kết hợp confidential transfers, zero-knowledge proofs và selective disclosure. Một số thông tin có thể được giữ kín trên chain trong khi thông tin cần thiết vẫn có thể được chứng minh hoặc tiết lộ có kiểm soát.
Điều tôi không ngờ là privacy ở đây không được đặt đối lập hoàn toàn với compliance. Citadel chẳng hạn, sử dụng selective disclosure để chứng minh thuộc tính như residency, age bracket hoặc accreditation mà không nhất thiết phải công khai toàn bộ dữ liệu.
Khoan, điều này vẫn chưa đủ để nói rằng Dusk đã giải quyết bài toán dữ liệu nhạy cảm của tài chính tổ chức. Privacy còn phụ thuộc vào cách ứng dụng triển khai và những metadata nào vẫn có thể bị lộ.
Nhưng sau khi đọc sâu hơn tôi bắt đầu nhìn câu hỏi khác đi: với tài chính on chain liệu vấn đề không phải là “privacy hay transparency” mà là ai được nhìn thấy dữ liệu nào, trong hoàn cảnh nào?
#dusk $DUSK @Dusk $BTC

Có gì đó khiến tôi dừng lại khi đọc docs của Dusk. Họ liên tục đặt privacy, compliance và settlement vào cùng một stack như thể ba thứ này không thể tách rời.

Dusk đang xây L1 cho regulated finance. DuskDS làm lớp settlement và data availability với finality deterministic qua Succinct Attestation. Trên đó có dual transaction model: Phoenix cho shielded, Moonlight cho transparent. Citadel lo selective disclosure. DuskEVM và DuskVM chạy execution nhưng tất cả đều settle về cùng một base.
Tôi muốn xem liệu việc gộp ba thứ này có thực sự xuất phát từ yêu cầu kỹ thuật hay chỉ là cách định vị cho RWA. Tôi đọc core components, transaction models rồi đối chiếu với cách họ mô tả workflow phát hành và settle chứng khoán.

Hóa ra architecture modular nhưng vẫn buộc privacy và compliance logic nằm sát settlement layer. Phoenix dùng ZK để che amount và participant trong khi vẫn cho phép audit path. Compliance không phải add-on ở app mà được thiết kế để chạy song song với finality.
Khoan, có lẽ đây chỉ là lựa chọn triển khai cho institutional workflow chứ không phải định luật bắt buộc. Nhiều chain khác tách privacy ra L2 hoặc side system, settlement giữ public. Dusk chọn gộp vì họ nhắm vào regulated assets, nơi data nhạy cảm và finality phải đi cùng nhau để tránh handoff giữa nhiều hệ thống.

Nhìn rộng hơn ngành đang thấy pattern tương tự ở vài protocol RWA khác: marketing nhấn mạnh “privacy + compliance native” trong khi execution thực tế vẫn phụ thuộc vào license bên ngoài và tooling quen thuộc.
Liệu settlement có thực sự cần privacy embedded ở base layer hay chỉ cần interface đủ tốt để các lớp trên tự quyết?
#dusk $DUSK @Dusk $BTC

Quelque chose m’a fait m’arrêter en lisant la documentation de Dusk. La plupart des L1 privacy parlent de transactions « shielded », mais ici, ils mettent en avant le « selective disclosure » (divulgation sélective) et le contrôle d’accès dès le protocole.

Dusk est une Layer1 publique, permissionless, axée sur l’émission native de titres numériques et d’actifs réglementés. Ils ont un partenariat avec NPEX (licences MTF, Broker, ECSP), un modèle dual Phoenix/Moonlight, Citadel pour l’identité et ils poussent DuskEVM. Le mainnet est déjà en ligne, et la documentation ainsi que GitHub Rusk sont mis à jour en continu. Je veux voir si l’architecture en coulisses est vraiment différente de celle des projets qui se contentent d’ajouter la conformité uniquement à la couche application. En lisant l’overview, les core components, puis en les confrontant aux informations sur NPEX et DLT-TSS. Il s’avère que la conformité est intégrée au protocole : éligibilité, restrictions de transfert, transfert forcé, registre des actionnaires pouvant être déchiffré de manière sélective.

La confidentialité n’est pas une anonymité absolue, mais plutôt « privée par défaut, auditable lorsque cela est nécessaire ». C’est une approche différente de celle de la plupart des DeFi actuels.
Cependant, je pense peut-être que j’exagère. Les licences NPEX appartiennent à des partenaires, et non au protocole qui en serait propriétaire intégralement. DLT-TSS est toujours en cours ; cela pourrait n’être qu’une manière de déployer leur solution pour le marché européen. Beaucoup de protocoles passent aussi d’un DeFi « pur » vers une infrastructure régulée. Le marketing arrive souvent avant le produit réel, tandis que l’adoption institutionnelle est bien plus lente que le narratif. Est-ce qu’on valorise un narratif de DeFi régulé, ou est-ce qu’on le mesure par le volume réel d’actifs qui sont effectivement « settled » onchain ?
#dusk $DUSK @Dusk $BTC

Il y a un point qui m’a fait m’arrêter lorsque j’ai lu des informations sur STOX. Au départ, je l’ai assez facilement classé dans la catégorie DEX : un endroit où échanger des actifs onchain, mais après avoir relu la documentation de Dusk, cette description commence à manquer de quelques éléments.

STOX a déjà été appelé par Dusk le nom de code interne d’une plateforme de trading dont l’objectif était de mettre des actifs réglementés sur la blockchain et de permettre aux investisseurs d’y trader. Aujourd’hui, ce produit s’appelle Dusk Trade.
J’ai essayé de regarder ce qui se trouve derrière l’acte de trader. Dusk Trade ne parle pas seulement d’achats et de ventes : la documentation actuelle liste aussi l’onboarding des investisseurs, l’éligibilité, l’appairage du portefeuille, les transferts contrôlés, la coordination des paiements et le règlement.

À ce stade, j’ai dû corriger ma compréhension initiale. La différence semble ne pas résider dans le fait de « trader ou non des tokens », mais plutôt dans les règles qui doivent accompagner la transaction lorsque l’actif est de nature réglementée.
Mais je ne veux pas non plus extrapoler. Dusk Trade est encore en cours de construction, donc on ne peut pas conclure, à partir de l’architecture annoncée, à propos de l’efficacité réelle du marché.

Ce que je trouve plus intéressant à suivre, c’est le suivant : lorsque l’éligibilité, les règles de transfert et le règlement deviennent une partie du workflow de trading, le concept de « DEX » est-il encore suffisant pour décrire ce produit ?
#dusk $DUSK @Dusk $BTC

J’ai commencé à lire Dusk Network à partir d’une question assez simple : si les RWA sont vraiment mises sur la blockchain, que faut-il que cette blockchain fasse, outre le fait d’enregistrer des tokens ?

Cette question m’a fait regarder le problème autrement : la tokenisation n’est qu’une première étape. Une fois que les actifs ont été représentés on-chain, il reste encore des choses à traiter : qui est autorisé à effectuer des transactions, comment celles-ci sont exécutées, si la leg de l’actif et la leg du paiement sont synchronisées, et enfin où les droits de propriété sont réglés (settlement).

Ainsi, plutôt que de commencer par l’histoire « Dusk est-elle une blockchain pour les RWA ou non », je veux d’abord vérifier son architecture.
Dans la documentation de Dusk, DuskDS assure le consensus, la finalité et la disponibilité des données du Dusk L1, tandis que DuskEVM fournit un environnement compatible EVM pour les applications.

Ce qui est notable, c’est que Dusk décrit aussi une infrastructure de marché avec des étapes d’onboarding, des contrôles de transfert, une coordination entre l’actif et le paiement, ainsi qu’un settlement.

À ce stade, j’ai commencé à voir une autre approche : les RWA ne nécessitent pas seulement un endroit pour émettre des tokens, mais une couche qui gère l’ensemble du cycle de vie des transactions. Pourtant, je dois toujours garder une interrogation : une architecture appropriée ne signifie pas forcément une adoption réelle.
Alors Dusk construit-elle une infrastructure de settlement, ou ne fait-elle que poser les fondations ?
#dusk $DUSK @Dusk $BTC

Si vous débutez avec Binance P2P, j’ai une habitude que je pense qu’il faut prendre tout de suite, dès les premières transactions, selon moi : ne choisissez pas un vendeur uniquement parce qu’il propose un bon prix.

Auparavant, je me disais que quelques centimes d’écart ne représentaient pas grand-chose, alors je regardais d’abord le prix puis seulement le reste des informations. Mais après plusieurs transactions, et en lisant attentivement la façon dont Binance affiche les données pour chaque annonce, j’ai commencé à voir que ce qu’il faut vérifier ne se limite pas au niveau du prix.

J’ai essayé de me construire un processus simple avant chaque ordre, que vous pouvez consulter.
D’abord, je regarde le nombre de transactions et le taux de réalisation. Ensuite, je lis les retours spécifiques s’il y a des commentaires négatifs qui reviennent souvent.
Ensuite, je vérifie si les limites de l’ordre et la méthode de paiement conviennent réellement.
Plus important encore, je rapproche les informations de paiement et je ne transfère pas la conversation vers Telegram ou une autre plateforme sans raison.

Cependant, il y a une chose que je constate : ces données ne peuvent pas transformer un partenaire en « sécurité absolue ». Elles me servent surtout de base supplémentaire pour évaluer avant de faire une transaction.

Pour des échanges P2P, à mon avis, le plus important n’est probablement pas de trouver le vendeur le moins cher, mais de former l’habitude de vérifier avant d’appuyer sur « confirmer ».
Je ne sais pas si ces expériences peuvent aider tout le monde, mais en tout cas, c’est ce que j’en ai retiré après avoir procédé à mes propres vérifications.

#binancep2pantoan @Binance Vietnam $BTC

Il y a un détail qui m’a obligé à relire plusieurs fois le consensus de Dusk. Au début, je pensais que Succinct Attestation n’était qu’une autre façon de désigner la preuve d’enjeu (PoS), mais le flux interne comporte quelques points remarquables.

D’après la documentation actuelle, DuskDS utilise Succinct Attestation (SA) que Dusk décrit clairement comme un protocole de consensus PoS permissionless et basé sur des comités. Pour participer au consensus, un provisioner doit mettre en jeu au minimum 1.000 DUSK.
Je poursuis. Un round n’est pas simplement des validateurs qui votent pour un bloc : il est divisé en trois étapes : Proposal, Validation et Ratification. Un provisioner propose un bloc, puis un comité vérifie ; ensuite, un autre comité confirme le résultat et finalise le bloc. Une fois la ratification terminée, Dusk atteint une finalité déterministe.
À ce stade, je dois corriger ma compréhension initiale.
SA n’est pas « un consensus totalement différent du PoS ». La base économique reste bien le staking ; ce que Dusk a redessiné se situe dans la manière de sélectionner les comités, la séparation des étapes de validation, et la façon dont le bloc est mené jusqu’à la finalité.
Attendez, cela ne suffit pas non plus pour dire que la SA est meilleure que la PoW ou le PoS traditionnel.
La PoW repose sur la concurrence de calcul, alors que la SA n’a pas besoin de ce mécanisme. Mais dire que Dusk « remplace le PoS par quelque chose de complètement nouveau » n’est pas exact.
Ce qui, selon moi, mérite davantage d’être étudié, c’est : dans quelle mesure une finalité conçue de façon déterministe change-t-elle l’expérience de settlement pour les applications financières ?
#dusk $DUSK @Dusk $BTC

Quelque chose m’a fait m’arrêter en lisant à propos de Dusk Network. Au début, je pensais qu’il s’agissait simplement d’une blockchain centralisée sur la confidentialité et la tokenisation d’actifs, mais en recoupant les nouveaux docs, j’ai constaté que la façon dont Dusk se positionne est bien plus large.

Dusk se décrit comme une infrastructure pour les actifs numériques régulés et la finance onchain, avec pour objectif central la confidentialité, le contrôle d’accès et le règlement déterministe. Ce n’est pas seulement une histoire de token.
J’ai commencé à examiner l’architecture. DuskDS prend en charge le consensus, la finalité et la disponibilité des données ; DuskVM exécute les smart contracts Rust/WASM directement sur la L1 ; et DuskEVM fournit un environnement EVM compatible, en s’appuyant sur DuskDS pour le settlement.

Ensuite, j’ai lu plus en profondeur sur les actifs régulés. Les docs abordent l’éligibilité, l’appairage du portefeuille (wallet binding), les restrictions de transfert, la divulgation (disclosure), le reporting et la coordination du règlement (settlement coordination). La confidentialité est aussi divisée en deux axes : Moonlight pour les transactions publiques et Phoenix pour les transferts shielded.
À ce moment-là, j’ai compris pourquoi Dusk ne se contente pas de parler de « mettre des actifs sur la blockchain ». Leur but est d’intégrer aussi les contraintes du marché financier dans un workflow onchain.
Mais attention : une architecture pensée pour la finance réglementée ne signifie pas nécessairement que l’adoption soit déjà prouvée.

Peut-être la question la plus intéressante à suivre est-elle : ces primitives deviendront-elles réellement l’infrastructure utilisée par les marchés financiers ?
#dusk $DUSK @Dusk $BTC

À première vue, je me suis dit que Binance P2P ne faisait que rajouter quelques couches de protection aux transactions entre pairs. L’Escrow, la vérification ou encore l’Appeal sont des notions assez familières.

Mais en lisant de plus près, je me rends compte que le sujet devient bien plus intéressant : qu’est-ce qui se passe lorsque les deux parties ne sont plus d’accord au sujet de la transaction.

Au départ, je pensais que Chat et Appeal n’étaient que des outils d’assistance en cas d’incident. Puis j’ai compris que leur véritable valeur réside dans le fait d’aider les parties à fournir des informations et des preuves afin que Binance puisse les examiner lorsqu’un litige survient.

Le processus de réclamation permet de consigner les étapes de traitement, les notes et les preuves pertinentes. Cela m’a fait voir l’Appeal autrement : ce n’est pas un mécanisme qui garantit un résultat, mais plutôt une procédure destinée à examiner les faits à partir des informations fournies.

Ce qui me préoccupe, c’est encore une fois le comportement des utilisateurs. Binance recommande aussi de ne pas se fier à des captures d’écran ni à des SMS pour confirmer un paiement, et de conserver les justificatifs si un Appeal est nécessaire.

C’est à ce moment-là que j’ai compris que l’élément le plus marquant ne tenait pas seulement à la technologie. Il réside dans la façon dont le système maintient une procédure pour que les deux parties puissent présenter des preuves lorsqu’un désaccord survient.

Plus j’y pense, plus je me dis que cela ressemble davantage à un modèle de coordination qu’à une simple fonctionnalité, et que la valeur de l’infrastructure ne devient vraiment visible que lorsque la transaction n’est plus aussi simple.
#binancep2pantoan @Binance Vietnam $BTC

Il y a un endroit qui m’a forcé à relire quand j’ai commencé à me renseigner sur Dusk Network. Je pensais que la tokenisation était assez simple : prendre un actif, créer un token qui le représente, puis déposer ce token sur la blockchain.
Mais la documentation de Dusk définit cela de façon plus précise. La tokenisation est l’émission de tokens représentant un actif, ou un droit sur cet actif. Le point, c’est que pour les actifs gérés, la garde (custody), le registre (registry) et le règlement (settlement) peuvent tout de même rester en dehors du ledger.

J’ai commencé à examiner le reste du cycle de vie : issuance, eligibility, transfer restrictions, disclosure, trading et settlement. Ce sont aussi des workflows que Dusk intègre dans la conception de son infrastructure de marché.
DuskDS s’occupe du settlement, de la finalité et de la disponibilité des données. Citadel fournit l’identité et la divulgation sélective. Dusk Trade se situe au niveau applicatif : il gère des workflows comme l’onboarding, le trading et la coordination du settlement asset-payment.

En fait, le point que j’avais initialement manqué ne concernait pas le token lui-même, mais ce qui se produit avant et après chaque transfert.
Attendez, cela ne veut pas dire non plus que tout soit automatiquement mis onchain : la propre documentation de Dusk précise que l’architecture concrète dépend encore du produit et des exigences juridiques.

Donc, la façon dont je vois Dusk a légèrement changé : ici, la tokenisation ne consiste pas seulement à créer une représentation, mais à construire tout le workflow autour de l’actif.
Alors, au final, la valeur se trouve-t-elle dans le token, ou dans l’infrastructure qui permet réellement à ce token de fonctionner ?
#dusk $DUSK @Dusk $BTC

Il m’est arrivé de passer une commande P2P, puis de constater que la méthode de paiement ne me convenait pas, alors j’ai voulu l’annuler. Je pensais que c’était un geste normal… jusqu’au moment où je me suis demandé : si tout le monde peut annuler à sa guise, sur quoi Binance s’appuie-t-il pour évaluer un marchand comme digne de confiance ?
Auparavant, je considérais l’annulation d’une commande comme quelque chose de plutôt simple : si je ne voulais plus effectuer la transaction, je l’annulais. Mais en consultant la documentation Binance P2P Merchant Guidelines, cette façon de voir a commencé à poser problème.

Binance précise clairement que le marchand ne doit pas « annuler des commandes arbitrairement ». En parallèle, le taux d’achèvement des commandes sur 30 jours fait partie des indicateurs utilisés pour évaluer les marchands ; un faible taux de complétion peut entraîner une exclusion du programme de marchands.

J’ai ensuite lu la section consacrée aux principes de trading pour voir si Binance interdit purement et simplement l’annulation. Non : la documentation indique toujours que, dans certains cas, le marchand peut annuler. Par exemple, lorsque les informations du compte de paiement du partenaire ne répondent pas aux exigences, ou lorsque l’utilisateur refuse certaines étapes de vérification supplémentaires.

À ce stade, j’ai dû revoir mon interprétation initiale.
Le problème ne vient pas du fait que « annuler une commande soit incorrect ». Le problème se trouve dans le terme « arbitrairement ». Binance fait la distinction entre une raison valable pour mettre fin à la transaction et l’annulation d’une commande sans fondement.
Attendez, ce n’est pas encore suffisant pour dire qu’une annulation entraînera forcément une sanction. Le document parle de critères d’évaluation et de cas de violation, et ce n’est pas aussi simple que : cliquer sur « annuler » une seule fois = être automatiquement traité.
Ce qui est peut-être plus important, c’est que dans le P2P, une action qui paraît très anodine est intégrée à l’ensemble d’un système qui évalue le taux de complétion et la fiabilité du marchand.

#binancep2pantoan @Binance Vietnam $BTC

Aujourd’hui, j’ai passé toute l’après-midi à décortiquer Dusk Network pour participer au programme Creatorpad du projet sur Binance.
Il y a un détail qui m’a obligé à relire la partie “privacy” de Dusk Network. “Selective Disclosure” paraît plutôt simple : garder les données privées, mais les révéler quand c’est nécessaire. Pourtant, en descendant dans la documentation, la façon dont Dusk découpe ses composants diffère de ce que j’avais imaginé.

Dusk décrit la confidentialité selon trois axes : un compte public avec Moonlight, des transactions shielded avec Phoenix, et la “selective disclosure” quand une partie autorisée a besoin d’une preuve.

J’ai approfondi Citadel parce que la doc indique que c’est la couche d’identité et d’accès pour la “selective disclosure”. Citadel utilise des preuves à connaissance nulle (zero knowledge proofs) pour que les utilisateurs puissent prouver qu’ils possèdent une licence valide sans devoir rendre publiques toutes les informations d’identification.

Le point marquant, c’est que, dans les exemples de la documentation, il n’est pas question de “révéler l’identité complète”. L’utilisateur génère ensuite une preuve, et le prestataire de service vérifie que les droits sont valides via le processus de Citadel.
Attendez : cela ne veut pas encore dire que toutes les données sur Dusk seraient automatiquement révélées de façon sélective. La documentation ne fait qu’exposer les primitives et les patterns afin que les applications puissent construire des workflows adaptés.

C’est peut-être là le point que je dois retenir : la “Selective Disclosure” de Dusk n’est pas une “privacy avec un bouton de publication”, mais une manière de séparer les droits de preuve d’une information de la publication de l’ensemble des données.

La question suivante devient alors intéressante : jusqu’où ces primitives sont-elles mises en œuvre dans des applications réelles ?
#dusk $DUSK @Dusk $BTC

Il existe une situation assez simple qui m’a fait changer de perspective sur la façon de choisir un partenaire sur Binance P2P.

Supposons que je doive acheter 1.000 USDT et que je voie deux annonces avec des prix presque équivalents. Le partenaire A a déjà effectué environ 2.800 transactions, avec un taux d’achèvement de 99,6%. Le partenaire B, même s’il propose un prix légèrement meilleur, n’a que 45 transactions et un taux d’achèvement de 91%.

Si je me contentais de regarder le prix, je pourrais choisir n’importe qui. Mais en lisant les consignes de Binance, je vois que la plateforme recommande de vérifier le taux d’achèvement, le nombre total de transactions réalisées et les retours de la contrepartie avant d’effectuer une transaction.
J’ai donc commencé à regarder ces deux annonces différemment.

2.800 transactions ne prouvent pas à elles seules que le partenaire A n’aura certainement aucun problème, mais elles me donnent une plus grande quantité de données historiques pour évaluer. À l’inverse, 45 transactions et un taux d’achèvement plus bas me laissent moins d’éléments pour croire en la stabilité du partenaire.

Binance affiche aussi des données comme le nombre de transactions sur 30 jours, le taux d’achèvement sur 30 jours et le délai moyen de mise à disposition.
Mais attendez : ces chiffres ne sont que des signaux, pas une garantie pour la transaction suivante.

Je ne considérerai ni le taux d’achèvement ni le nombre de transactions comme un laissez-passer qui garantit quoi que ce soit. Ils m’aident seulement à avoir davantage de bases pour choisir, tandis que la vérification des transactions concrètes reste de ma responsabilité.
#binancep2pantoan @Binance Vietnam $BTC

Il y a un détail qui m’a donné envie de relire l’architecture de Dusk une fois de plus. Au départ, je pensais que DuskDS n’était rien de plus que la partie blockchain située sous DuskEVM, mais la documentation technique la décrit comme quelque chose de plus large.

DuskDS est défini comme la couche de settlement et de disponibilité des données de Dusk L1, chargée du consensus, de la finalité et des modèles de transactions natives. DuskEVM est la couche d’exécution qui utilise DuskDS pour le settlement et la disponibilité des données. Quant à DuskVM, il exécute directement les contrats sur Dusk L1.

J’ai ensuite approfondi la façon dont le settlement est réellement confirmé. DuskDS utilise la Succinct Attestation, un mécanisme de Proof-of-Stake basé sur un comité. Le processus comprend proposal, validation puis ratification : une fois le bloc ratifié, la finalité est déterministe.

J’ai ensuite examiné le modèle de transactions. Moonlight gère des comptes publics, tandis que Phoenix utilise des shielded notes et des preuves de connaissance zéro. Deux modèles différents, mais au final, ils se règlent sur la même chaîne.
Attendez—cela ne signifie pas pour autant que DuskDS gère toute la logique applicative à elle seule. L’exécution relève toujours de DuskVM ou de DuskEVM, mais c’est précisément ici que ma perception a changé : Dusk sépare assez clairement l’exécution du settlement.

Dès lors, la question qui mérite d’être suivie n’est plus de savoir si DuskDS est ou non une couche de settlement, mais plutôt : en quoi cette architecture de séparation du settlement fera-t-elle une différence concrète lorsque les applications financières commenceront à tourner à grande échelle ?
#dusk $DUSK @Dusk

Il y a une situation que je pense que beaucoup de nouveaux arrivants peuvent facilement rencontrer en vendant de l’USDT sur Binance P2P, et que moi aussi j’ai déjà vécue.

C’était une fois où j’ai passé une offre de vente de 350 USDT. L’acheteur a signalé avoir transféré l’argent et m’a immédiatement envoyé un message : « Vérifie pour moi, puis libère, s’il te plaît, j’ai besoin d’USDT en urgence. »

Un peu après, il m’a envoyé une photo de la transaction bancaire indiquant que le transfert a réussi. J’ai ouvert l’image pour vérifier le montant, l’heure, et le nom du destinataire. Tout semblait logique, mais quand j’ai ouvert directement l’application bancaire de mon côté, l’argent n’était toujours pas apparu.

Je vais attendre que le montant apparaisse réellement sur le compte destinataire, plutôt que de laisser les pressions de l’autre partie décider du moment où je libère la transaction.

Il se peut que l’acheteur soit totalement honnête, ou que le transfert bancaire soit simplement en retard.

Je veux savoir si cette pression change vraiment le processus.
En relisant la documentation, j’ai vu que Binance recommande de garder les échanges sur la plateforme, de vérifier l’argent directement sur le compte destinataire, et de ne pas se baser sur des captures d’écran, des SMS ou la confirmation verbale de l’autre partie pour libérer la transaction. En cas de problème, la transaction peut être portée en appeal et des preuves peuvent être fournies.

Attendez… cela ne veut pas dire que quiconque presse l’autre est forcément un scam. Il est possible qu’ils veuillent juste que la transaction se termine plus vite, mais c’est précisément là que ça m’a paru notable : l’escrow protège les fonds, mais ne remplace pas l’étape de vérification de l’utilisateur.

En regardant plus largement, le P2P reste un processus assez manuel, donc la pression humaine existe toujours.

C’est pourquoi je ne laisserai pas la pression de l’autre partie décider du moment de la transaction : je libère seulement lorsque l’argent est bien arrivé sur mon compte. Peut-être que je suis un peu prudent, mais dans le P2P, être prudent vaut mieux que de croire à quelque chose que je n’ai pas vérifié.

#binancep2pantoan @Binance Vietnam $BTC

Il y a un détail qui m’a fait m’arrêter en lisant sur Dusk Network : ils ne définissent pas la privacy comme le fait de simplement cacher toutes les données, mais plutôt en la plaçant à côté de la capacité à révéler de manière sélective.

Je relis l’architecture et je constate que DuskDS prend en charge deux modèles de transaction assez différents. Moonlight est public, tandis que Phoenix utilise des notes chiffrées (shielded) et des preuves à divulgation nulle de connaissance (zero-knowledge proofs) pour ne pas divulguer publiquement le montant, l’expéditeur ni le lien entre les notes.

Ce que je veux vérifier, c’est de savoir si cette privacy est réellement liée aux exigences du marché financier, ou si ce n’est qu’une fonctionnalité technique.
Dans la documentation sur les actifs réglementés, Dusk décrit une situation assez réaliste : un investisseur n’a pas besoin que tous les participants voient l’intégralité des soldes ou des transactions, mais l’émetteur (issuer), le lieu d’exécution (venue) ou l’auditeur peut encore avoir besoin d’une partie d’informations spécifiques. Dusk appelle cette approche la divulgation sélective (selective disclosure).

Attendez, je ne devrais pas pour autant en déduire que les institutions financières ont effectivement utilisé Dusk à grande échelle.
Mais je remarque quelque chose d’important : la façon dont le problème est posé. La privacy n’est pas nécessairement opposée à la transparence. Un système peut conserver des données privées dans des transactions tout en permettant de fournir des preuves ou les informations nécessaires à la bonne partie.

Si c’est le cas, la question que je veux encore explorer est la suivante : dans la finance réglementée, la privacy a-t-elle réellement de la valeur quand les données doivent être protégées, ou quand elles doivent être divulguées aux bonnes personnes ?
#dusk $DUSK @Dusk

J’ai déjà été confronté à une situation qui m’a obligé à relire la procédure Binance P2P : c’était au moment où je vendais 200 USDT après avoir reçu l’airdrop Binance Alpha. L’acheteur m’a envoyé une capture d’écran indiquant que le paiement avait été effectué et m’a pressé de libérer les cryptos. À première vue, tout semblait normal, mais en vérifiant directement le compte sur lequel l’argent devait arriver, j’ai constaté que cette somme n’y apparaissait pas. À partir de cette situation, j’ai commencé à faire davantage attention à un détail dans le guide de Binance : le vendeur ne devrait libérer les cryptos qu’après avoir, de lui-même, confirmé qu’il a bien reçu l’argent.

J’ai relu les instructions de Binance et j’ai constaté que la procédure est assez claire. Lors d’une vente, les cryptos sont conservés en escrow ; le vendeur attend que le paiement arrive via le moyen convenu, puis confirme qu’il a réellement reçu l’argent avant de libérer.

Je voulais comprendre pourquoi cette étape de confirmation est placée avant la libération, au lieu de se baser uniquement sur la notification « paiement effectué ».

En consultant plus de documentation de sécurité P2P, la raison est devenue plus claire. Binance met en garde contre la « fausse confirmation de paiement » et recommande de vérifier directement le compte destinataire, plutôt que de se fier à une capture d’écran, un reçu ou des SMS.
Il s’avère que l’escrow ne signifie pas que le vendeur peut ignorer la dernière étape de vérification. L’escrow conserve les cryptos pendant la transaction, mais il faut quand même que le destinataire vérifie si le paiement en monnaie fiduciaire est réellement parvenu.

En regardant plus largement, le P2P implique toujours une part de responsabilité de la part des utilisateurs. Il est possible qu’en P2P, la sécurité ne consiste pas à croire que le système a entièrement géré les risques, mais plutôt à vérifier soi-même ce que le système ne peut pas confirmer à votre place.
#binancep2pantoan @Binance Vietnam $BTC

Quelque chose m’a arrêté au moment de lire l’architecture de Dusk Network. Au début, je la voyais encore comme une Layer 1 familière : il y a un consensus, des smart contracts, un token et un écosystème construit au-dessus.
Mais en lisant plus attentivement, la façon dont Dusk découpe ses composants m’a forcé à tout relire depuis le début.

La documentation de Dusk décrit DuskDS comme une fondation de settlement et de data availability, responsable du consensus, de la finalité et des modèles de transactions de Dusk L1, tandis que l’exécution est scindée en deux directions : DuskVM pour Rust/WASM, qui s’exécute directement sur L1, et DuskEVM pour un environnement compatible avec EVM d’Ethereum.

J’ai commencé à creuser pour comprendre s’il ne s’agissait que d’une restructuration d’une Layer 1 ou si cela reflétait réellement un choix d’architecture différent.
Ce que j’ai trouvé est assez clair : Dusk ne regroupe pas toute l’exécution dans un seul environnement. DuskDS gère le consensus, le settlement et la data availability, tandis que DuskVM et DuskEVM prennent en charge différents modèles d’exécution.

Attendez, ce n’est pas encore suffisant pour dire que cette architecture est meilleure, mais cela a changé ma façon de voir Dusk. La question la plus intéressante n’est peut-être pas « Dusk est-elle une Layer 1 ? », mais plutôt : le fait de séparer le settlement de l’exécution apportera-t-il réellement quelque chose lorsque ces environnements d’exécution commencent à être largement utilisés ?

#dusk $DUSK @Dusk $BTC

La première fois que j’ai vendu des crypto sur Binance P2P, l’acheteur m’a signalé qu’il avait effectué le virement et a envoyé une capture d’écran indiquant que la transaction était réussie. En voyant cela, on aurait dit que tout était presque terminé, mais lorsque j’ai ouvert l’application bancaire pour vérifier, l’argent n’était toujours pas apparu sur mon compte. Je me suis arrêté là, au lieu d’appuyer sur « Release », parce qu’à ce moment-là une question devenait assez claire : si l’acheteur a déjà dit « virement effectué », alors qu’est-ce exactement que je dois confirmer avant que la crypto soit réellement libérée ?

J’ai essayé de comprendre en sens inverse avec une transaction simple. L’acheteur effectue le paiement selon le moyen convenu, puis le vendeur vérifie le montant reçu. La documentation de Binance indique clairement que ce n’est qu’après avoir confirmé que l’argent est bien arrivé chez le vendeur que celui-ci libère la crypto depuis l’escrow.

Je voulais comprendre pourquoi cette étape de confirmation est placée côté vendeur.

En lisant les Merchant Guidelines, j’ai vu que Binance exige aussi que le nom figurant sur le compte de paiement corresponde au nom vérifié sur la plateforme. Si les informations du compte bancaire du partenaire ne correspondent pas au nom vérifié par Binance, l’accès à la libération de la crypto n’est pas autorisé ; le vendeur peut alors rembourser et signaler la transaction.

Ce n’est qu’à ce moment-là que j’ai compris que j’avais regardé le P2P un peu trop simplement. L’escrow conserve les crypto pendant la transaction, mais le fait de confirmer que le paiement a réellement été reçu reste une étape distincte du processus.

Attendez, cela ne signifie pas que Binance peut empêcher tous les risques liés aux paiements. La documentation montre seulement que la responsabilité de vérifier le montant et les informations de la personne qui a effectué le paiement existe encore avant la libération.

Peut-être que « Release » n’est pas une action qui confirme que l’argent est arrivé, mais plutôt une étape réalisée après confirmation.

Donc, avant de « Release », vérifiez soigneusement tout le monde, s’il vous plaît.
#binancep2pantoan @Binance Vietnam $BTC

Quelque chose me fait m’arrêter en lisant sur le Dusk Network : DuskDS et DuskEVM sont décrits comme deux parties différentes, mais qui ne sont pourtant pas indépendantes.

Je commence par l’architecture. La documentation Dusk appelle DuskDS la couche de règlement et d’acquisition des données, qui assure le consensus, la finalité et les modèles de transactions natives de Dusk. DuskEVM est un environnement d’exécution compatible avec l’EVM, où les smart contracts Solidity peuvent tourner avec les outils familiers. Plus important encore, DuskEVM utilise DuskDS pour le règlement et l’acquisition des données.

Je veux vérifier si ce n’est qu’une façon de nommer au niveau de l’architecture, ou s’il existe une véritable séparation des responsabilités.
En allant plus loin, je constate que DuskDS gère le consensus, la finalité et l’acquisition des données, ainsi que des modèles de transactions tels que Moonlight et Phoenix. DuskEVM se concentre sur l’exécution et permet d’utiliser Hardhat, Foundry ainsi que l’écosystème EVM. L’une fournit la base du règlement, l’autre s’occupe de l’exécution.

Attendez—ce n’est pas encore suffisant pour dire que ces deux couches « se complètent » au sens des performances ou de la sécurité. D’après ce que j’ai pu vérifier dans la documentation, le lien le plus clair est que l’exécution est séparée du règlement.
Ce qui est intéressant, c’est que Dusk utilise la modularité pour garder le règlement séparé, tout en restant ouvert aux développeurs grâce à l’EVM.
Alors, si l’adoption des applications augmente, cette frontière entre exécution et règlement crée-t-elle vraiment un avantage, ou s’agit-il simplement d’une manière d’organiser l’architecture?
#dusk $DUSK @Dusk $BTC