La preuve à divulgation nulle de connaissance signifie-t-elle automatiquement 100% sans confiance?
Cela semble logique. Personne ne voit le secret, et les mathématiques vérifient la preuve.
Mais le propre papier de la Citadelle de Dusk pointe vers une couche moins confortable sous PLONK : le setup de confiance.
L’implémentation PLONK de Dusk s’exécute sur BLS12-381 et utilise KZG10 comme schéma d’engagement de polynômes par défaut. KZG a besoin d’une Common Reference String générée à partir d’un secret d’aléa. Si ce « déchet toxique » survit et tombe entre les mains d’un attaquant, l’hypothèse de solidité peut s’effondrer.
Le papier de la Citadelle le dit clairement : une aléa de setup compromis pourrait permettre de fausses transactions et « de grosses pertes d’argent ». Pour la Citadelle, il indique que la conséquence serait l’usurpation d’identité et l’utilisation des licences d’autres personnes.
Alors, que signifie concrètement « setup de confiance » ?
Ne pas faire confiance à une seule entreprise avec un mot de passe maître.
Une cérémonie permet à plusieurs participants d’ajouter séquentiellement leur propre aléa. Chacun détruit ensuite sa contribution privée. La propriété clé est que la configuration reste sûre si au moins un participant était honnête et a supprimé définitivement son secret.
Cela m’a amené à me demander : qui a participé à la cérémonie de Dusk ?
En réalité, c’est plus documenté que je ne m’y attendais.
Le dépôt public de Dusk pour le trusted setup indique qu’il a démarré à partir d’une réponse vérifiée de Zcash Powers-of-Tau #87, puis a ajouté 15 contributeurs Dusk listés. Le dépôt expose des enregistrements de contributions et des étapes de vérification, tandis que Dusk a indiqué que les résultats seraient publics pour que d’autres puissent les vérifier.
Cela ne prouve pas toutes les hypothèses opérationnelles pour toujours. Je voudrais quand même savoir si les paramètres de production correspondent bien à la transcription publiée et comment, de façon indépendante, ce lien a été vérifié dans la pratique aujourd’hui.
La question la plus juste devient alors plus précise : puis-je tracer les paramètres cryptographiques « en direct » jusqu’à la cérémonie publiquement vérifiable ?
Quand un projet admet ouvertement une faiblesse cryptographique dans son propre papier, est-ce que cela renforce la confiance grâce à la transparence — ou est-ce que cela vous donne simplement envie de savoir exactement à quel point ce risque est réel ?
#dusk $DUSK @Dusk
Cela semble logique. Personne ne voit le secret, et les mathématiques vérifient la preuve.
Mais le propre papier de la Citadelle de Dusk pointe vers une couche moins confortable sous PLONK : le setup de confiance.
L’implémentation PLONK de Dusk s’exécute sur BLS12-381 et utilise KZG10 comme schéma d’engagement de polynômes par défaut. KZG a besoin d’une Common Reference String générée à partir d’un secret d’aléa. Si ce « déchet toxique » survit et tombe entre les mains d’un attaquant, l’hypothèse de solidité peut s’effondrer.
Le papier de la Citadelle le dit clairement : une aléa de setup compromis pourrait permettre de fausses transactions et « de grosses pertes d’argent ». Pour la Citadelle, il indique que la conséquence serait l’usurpation d’identité et l’utilisation des licences d’autres personnes.
Alors, que signifie concrètement « setup de confiance » ?
Ne pas faire confiance à une seule entreprise avec un mot de passe maître.
Une cérémonie permet à plusieurs participants d’ajouter séquentiellement leur propre aléa. Chacun détruit ensuite sa contribution privée. La propriété clé est que la configuration reste sûre si au moins un participant était honnête et a supprimé définitivement son secret.
Cela m’a amené à me demander : qui a participé à la cérémonie de Dusk ?
En réalité, c’est plus documenté que je ne m’y attendais.
Le dépôt public de Dusk pour le trusted setup indique qu’il a démarré à partir d’une réponse vérifiée de Zcash Powers-of-Tau #87, puis a ajouté 15 contributeurs Dusk listés. Le dépôt expose des enregistrements de contributions et des étapes de vérification, tandis que Dusk a indiqué que les résultats seraient publics pour que d’autres puissent les vérifier.
Cela ne prouve pas toutes les hypothèses opérationnelles pour toujours. Je voudrais quand même savoir si les paramètres de production correspondent bien à la transcription publiée et comment, de façon indépendante, ce lien a été vérifié dans la pratique aujourd’hui.
La question la plus juste devient alors plus précise : puis-je tracer les paramètres cryptographiques « en direct » jusqu’à la cérémonie publiquement vérifiable ?
Quand un projet admet ouvertement une faiblesse cryptographique dans son propre papier, est-ce que cela renforce la confiance grâce à la transparence — ou est-ce que cela vous donne simplement envie de savoir exactement à quel point ce risque est réel ?
#dusk $DUSK @Dusk
