#dusk $DUSK @Dusk Hier, j’ai dîné avec ma meilleure amie, la “Shirley”. Elle n’arrêtait pas d’en parler : @Dusk . Ensuite, elle m’a directement approché son téléphone pour que je voie le site officiel. Pendant que je mangeais, je feuilletais la documentation… et plus je la lisais, plus ça devenait passionnant. Je n’ai pas pu m’empêcher d’en débattre avec elle pendant un bon moment.
D’abord, parlons de Phoenix : à la base, c’est un transfert “déguisé” via UTXO + PLONK zk-SNARK. D’après l’officiel, on peut choisir de divulguer aux régulateurs. Mais j’ai remarqué un détail : à partir de Phoenix 2.0, l’identité de l’expéditeur est visible pour le destinataire. Tu crois faire des transactions privées… mais en face, ils savent qui tu es. Est-ce que ce mécanisme est vraiment capable d’empêcher qu’on “trace” ton portefeuille quand on veut le protéger ?
Ensuite, Moonlight coexiste avec Phoenix. L’officiel dit qu’on peut passer librement de l’un à l’autre. Je l’ai testé sur le moment : il faut d’abord répartir les actifs selon le modèle, puis comprendre comment le convert prouve la propriété, et en plus les frais sont à part. Ceux qui tapent tous les jours sur la chaîne doivent lire la doc ; pour un utilisateur normal, comment pourrait-on switcher facilement ? Finalement, tout le monde va forcément choisir la facilité et utiliser Moonlight, et Phoenix risque bien de finir au placard.
La divulgation sélective d’identité de Citadel a effectivement quelque chose d’intéressant. Mais la partie “License Provider délivre les certificats” : la légitimité de l’identité reste entre les mains du prestataire émetteur. En quoi c’est vraiment différent de l’ouverture d’un compte bancaire ? Les primitives comme PLONK, Poseidon, c’est ingénieux, certes, mais elles ne sont pas forcément simples à bien exploiter.
Pour le cycle de vie des transactions, là c’est plus concret. L’interface renvoie 202 Accepted : ça signifie seulement que le nœud a reçu le routage, pas que la transaction est entrée dans le mempool, et encore moins qu’elle s’est exécutée avec succès. D’après ce que je vois dans la doc officielle, ce qui est vraiment fiable, c’est de vérifier qu’il n’y a pas d’erreur d’exécution et que le bloc est “finalized”. Si le portefeuille ou l’échange affiche “soumise” comme “terminée”, entre-temps ça peut expirer ou être remplacé.
Franchement, Dusk explique la technique de façon très détaillée, mais ce qui m’importe le plus, c’est surtout : l’affichage de l’état côté front est-il clair ? le chemin de conversion est-il fluide ? et il reste quelle part de confidentialité lors des entrées/sorties ? La vraie certitude vient de la manière dont l’interface et les intégrateurs l’utilisent correctement, pas juste en lisant la documentation et en s’en contentant. $DUSK #dusk
Selon vous, quel est le point le plus déroutant / le plus problématique des solutions de confidentialité de Dusk ?
D’abord, parlons de Phoenix : à la base, c’est un transfert “déguisé” via UTXO + PLONK zk-SNARK. D’après l’officiel, on peut choisir de divulguer aux régulateurs. Mais j’ai remarqué un détail : à partir de Phoenix 2.0, l’identité de l’expéditeur est visible pour le destinataire. Tu crois faire des transactions privées… mais en face, ils savent qui tu es. Est-ce que ce mécanisme est vraiment capable d’empêcher qu’on “trace” ton portefeuille quand on veut le protéger ?
Ensuite, Moonlight coexiste avec Phoenix. L’officiel dit qu’on peut passer librement de l’un à l’autre. Je l’ai testé sur le moment : il faut d’abord répartir les actifs selon le modèle, puis comprendre comment le convert prouve la propriété, et en plus les frais sont à part. Ceux qui tapent tous les jours sur la chaîne doivent lire la doc ; pour un utilisateur normal, comment pourrait-on switcher facilement ? Finalement, tout le monde va forcément choisir la facilité et utiliser Moonlight, et Phoenix risque bien de finir au placard.
La divulgation sélective d’identité de Citadel a effectivement quelque chose d’intéressant. Mais la partie “License Provider délivre les certificats” : la légitimité de l’identité reste entre les mains du prestataire émetteur. En quoi c’est vraiment différent de l’ouverture d’un compte bancaire ? Les primitives comme PLONK, Poseidon, c’est ingénieux, certes, mais elles ne sont pas forcément simples à bien exploiter.
Pour le cycle de vie des transactions, là c’est plus concret. L’interface renvoie 202 Accepted : ça signifie seulement que le nœud a reçu le routage, pas que la transaction est entrée dans le mempool, et encore moins qu’elle s’est exécutée avec succès. D’après ce que je vois dans la doc officielle, ce qui est vraiment fiable, c’est de vérifier qu’il n’y a pas d’erreur d’exécution et que le bloc est “finalized”. Si le portefeuille ou l’échange affiche “soumise” comme “terminée”, entre-temps ça peut expirer ou être remplacé.
Franchement, Dusk explique la technique de façon très détaillée, mais ce qui m’importe le plus, c’est surtout : l’affichage de l’état côté front est-il clair ? le chemin de conversion est-il fluide ? et il reste quelle part de confidentialité lors des entrées/sorties ? La vraie certitude vient de la manière dont l’interface et les intégrateurs l’utilisent correctement, pas juste en lisant la documentation et en s’en contentant. $DUSK #dusk
Selon vous, quel est le point le plus déroutant / le plus problématique des solutions de confidentialité de Dusk ?
A. 双模型切换太麻烦,普通用户根本玩不转
67%
B. Phoenix隐私有后门,发送方可视是硬伤
14%
C. Citadel发证权还是中心化,跟银行没本质区别
14%
D. 交易所出入金环节隐私缩水,落地打折扣
5%
21 Votes • Vote fermé
