#dusk DUSK présente une caractéristique que je n’ai jamais vue faire l’objet d’un débat sérieux : en mode Phoenix, les preuves à divulgation nulle de connaissance (ZK) sont générées par qui, et qui en assume le coût de génération ?
Ce n’est pas un détail technique, c’est un problème de structure économique. Le coût de calcul des preuves ZK n’est pas négligeable, surtout lorsqu’il faut gérer des structures d’actifs complexes. Si la génération des preuves est exécutée par l’émetteur lui-même, alors le seuil d’onboarding en chaîne pour les petites et moyennes institutions n’est pas seulement un coût de conformité, mais aussi un coût de puissance de calcul. Si ce sont les nœuds qui génèrent à la place, alors ces nœuds détiennent l’entrée de génération des preuves : la limite de confidentialité se retrouve en réalité fendue dès le niveau des nœuds.$SPCXB
J’ai parcouru la documentation technique de DUSK, et sur cette partie, les descriptions sont relativement vagues : le texte utilise le concept de « prover network ». Mais le mécanisme d’incitation des prover, les conditions d’accès, ainsi que les hypothèses de confiance entre le prover et l’émetteur ne sont pas détaillés. Dans un scénario RWA, c’est un véritable point de friction : les institutions ne confieront pas les détails de la structure de leurs actifs à un prover dont la relation de confiance n’est pas clairement définie, même si, à la fin, ce qui est seulement enregistré on-chain n’est que la preuve, et non les données brutes.$SNDKB
Plus en profondeur encore : si le réseau de prover est décentralisé, alors la latence de génération des preuves devient une variable aléatoire. Combinée à la latence de consensus de la commission, la fenêtre de temps entre la « décision d’émettre » et le moment où « l’actif est enregistrable et échangeable on-chain » devient imprévisible.
Pour l’intention de 300 M€ de NPEX, si elle se concrétise vraiment en règlement effectif, les performances du réseau de prover seront le premier maillon mis à l’épreuve (stress test). Pas les TPS, pas la TVL : plutôt, à la taille réelle du patrimoine d’actifs, la preuve ZK peut-elle être générée de façon stable, rapide et à faible coût ?
Mon évaluation actuelle de $DUSK est la suivante : l’argumentaire lié à la conformité en matière de confidentialité tient la route, mais les coûts de friction côté exécution n’ont pas encore été suffisamment valorisés. Si le modèle économique du réseau de prover n’est pas bien conçu, les institutions choisiront d’exécuter les preuves off-chain, puis n’en soumettront que le résultat — ce qui est techniquement faisable, mais cela fera que la participation réelle au réseau DUSK sera bien inférieure aux attentes.
Ce qu’il faut observer n’est pas l’annonce de collaboration suivante, mais plutôt à quel moment les paramètres d’incitation du réseau de prover seront rendus publics, et dans quelle fourchette se situent les coûts de génération des preuves pour les premiers utilisateurs institutionnels réels.
#dusk @Dusk
Ce n’est pas un détail technique, c’est un problème de structure économique. Le coût de calcul des preuves ZK n’est pas négligeable, surtout lorsqu’il faut gérer des structures d’actifs complexes. Si la génération des preuves est exécutée par l’émetteur lui-même, alors le seuil d’onboarding en chaîne pour les petites et moyennes institutions n’est pas seulement un coût de conformité, mais aussi un coût de puissance de calcul. Si ce sont les nœuds qui génèrent à la place, alors ces nœuds détiennent l’entrée de génération des preuves : la limite de confidentialité se retrouve en réalité fendue dès le niveau des nœuds.$SPCXB
J’ai parcouru la documentation technique de DUSK, et sur cette partie, les descriptions sont relativement vagues : le texte utilise le concept de « prover network ». Mais le mécanisme d’incitation des prover, les conditions d’accès, ainsi que les hypothèses de confiance entre le prover et l’émetteur ne sont pas détaillés. Dans un scénario RWA, c’est un véritable point de friction : les institutions ne confieront pas les détails de la structure de leurs actifs à un prover dont la relation de confiance n’est pas clairement définie, même si, à la fin, ce qui est seulement enregistré on-chain n’est que la preuve, et non les données brutes.$SNDKB
Plus en profondeur encore : si le réseau de prover est décentralisé, alors la latence de génération des preuves devient une variable aléatoire. Combinée à la latence de consensus de la commission, la fenêtre de temps entre la « décision d’émettre » et le moment où « l’actif est enregistrable et échangeable on-chain » devient imprévisible.
Pour l’intention de 300 M€ de NPEX, si elle se concrétise vraiment en règlement effectif, les performances du réseau de prover seront le premier maillon mis à l’épreuve (stress test). Pas les TPS, pas la TVL : plutôt, à la taille réelle du patrimoine d’actifs, la preuve ZK peut-elle être générée de façon stable, rapide et à faible coût ?
Mon évaluation actuelle de $DUSK est la suivante : l’argumentaire lié à la conformité en matière de confidentialité tient la route, mais les coûts de friction côté exécution n’ont pas encore été suffisamment valorisés. Si le modèle économique du réseau de prover n’est pas bien conçu, les institutions choisiront d’exécuter les preuves off-chain, puis n’en soumettront que le résultat — ce qui est techniquement faisable, mais cela fera que la participation réelle au réseau DUSK sera bien inférieure aux attentes.
Ce qu’il faut observer n’est pas l’annonce de collaboration suivante, mais plutôt à quel moment les paramètres d’incitation du réseau de prover seront rendus publics, et dans quelle fourchette se situent les coûts de génération des preuves pour les premiers utilisateurs institutionnels réels.
#dusk @Dusk
你认为 prover 成本会成为机构上链的隐形门槛吗?
0%
ZK 证明延迟对债券结算影响有多大?
100%
prover 去中心化和隐私保护之间能两全吗?
0%
2 Votes • Vote fermé