#dusk
Je me suis rendu compte que j’ai écrit la formule « preuve à connaissance nulle » dans probablement huit messages différents, sans jamais expliquer réellement ce qu’on est en train de calculer.
Je me suis mis à chercher les primitives cryptographiques sous le capot, plutôt que de simplement réutiliser le terme.
Il s’avère que ce n’est pas une seule pièce de mathématiques qui fait tout. Ce sont quatre éléments, chacun gérant un rôle différent.
BLS12-381 est la courbe elliptique sous le système de signature et de preuve.
C’est une courbe « pairing-friendly » (compatible avec les appariements), une propriété spécifique qui rend l’agrégation des signatures et la construction de preuves compactes praticables au lieu d’être brutalement coûteuses en calcul.
JubJub est une courbe distincte, optimisée spécifiquement pour fonctionner efficacement dans les circuits SNARK : c’est là que les notes masquées de Phoenix voient leur confidentialité prouvée.
Poseidon est la fonction de hachage qui fait le gros du travail à l’intérieur de ces circuits.
Les fonctions de hachage classiques comme SHA-256 conviennent pour un usage normal, mais elles sont coûteuses à calculer dans une preuve à connaissance nulle.
Poseidon est construit précisément pour être peu cher dans ce contexte, c’est pourquoi on le retrouve pour les engagements (commitments) et le hachage des arbres de Merkle plutôt que pour quelque chose de plus familier.
PLONK est la partie qui transforme tout cela en une affirmation vérifiable.
C’est le système de preuve : la chose qui permet à un développeur de définir un circuit une fois, puis de générer des preuves qui sont vérifiées on-chain sans refaire le calcul original.
Ce qui m’a frappé en les mettant ensemble : aucun d’eux n’est une invention propre à Dusk.
Ce sont des briques cryptographiques établies, choisies et assemblées pour un travail précis.
La décision d’ingénierie réelle a été de sélectionner la bonne combinaison, pas d’inventer une nouvelle mathématique à partir de zéro.
$DUSK
Donc, @Dusk .
Utiliser des primitives cryptographiques établies et très étudiées plutôt que de la cryptographie nouvelle rend-elle une chaîne de confidentialité plus digne de confiance, ou bien empiler quatre systèmes différents ne fait-il que créer de nouveaux points de défaillance aux interfaces ?
Et est-ce qu’une personne moyenne utilisant l’un de ces éléments doit jamais connaître l’un de ces noms, ou est-ce définitivement « en coulisses », important seulement pour les auditeurs et les chercheurs ?
Je me suis rendu compte que j’ai écrit la formule « preuve à connaissance nulle » dans probablement huit messages différents, sans jamais expliquer réellement ce qu’on est en train de calculer.
Je me suis mis à chercher les primitives cryptographiques sous le capot, plutôt que de simplement réutiliser le terme.
Il s’avère que ce n’est pas une seule pièce de mathématiques qui fait tout. Ce sont quatre éléments, chacun gérant un rôle différent.
BLS12-381 est la courbe elliptique sous le système de signature et de preuve.
C’est une courbe « pairing-friendly » (compatible avec les appariements), une propriété spécifique qui rend l’agrégation des signatures et la construction de preuves compactes praticables au lieu d’être brutalement coûteuses en calcul.
JubJub est une courbe distincte, optimisée spécifiquement pour fonctionner efficacement dans les circuits SNARK : c’est là que les notes masquées de Phoenix voient leur confidentialité prouvée.
Poseidon est la fonction de hachage qui fait le gros du travail à l’intérieur de ces circuits.
Les fonctions de hachage classiques comme SHA-256 conviennent pour un usage normal, mais elles sont coûteuses à calculer dans une preuve à connaissance nulle.
Poseidon est construit précisément pour être peu cher dans ce contexte, c’est pourquoi on le retrouve pour les engagements (commitments) et le hachage des arbres de Merkle plutôt que pour quelque chose de plus familier.
PLONK est la partie qui transforme tout cela en une affirmation vérifiable.
C’est le système de preuve : la chose qui permet à un développeur de définir un circuit une fois, puis de générer des preuves qui sont vérifiées on-chain sans refaire le calcul original.
Ce qui m’a frappé en les mettant ensemble : aucun d’eux n’est une invention propre à Dusk.
Ce sont des briques cryptographiques établies, choisies et assemblées pour un travail précis.
La décision d’ingénierie réelle a été de sélectionner la bonne combinaison, pas d’inventer une nouvelle mathématique à partir de zéro.
$DUSK
Donc, @Dusk .
Utiliser des primitives cryptographiques établies et très étudiées plutôt que de la cryptographie nouvelle rend-elle une chaîne de confidentialité plus digne de confiance, ou bien empiler quatre systèmes différents ne fait-il que créer de nouveaux points de défaillance aux interfaces ?
Et est-ce qu’une personne moyenne utilisant l’un de ces éléments doit jamais connaître l’un de ces noms, ou est-ce définitivement « en coulisses », important seulement pour les auditeurs et les chercheurs ?
