Ces deux jours, en fouillant les choix de cryptographie de Dusk, j’ai découvert une décision très facile à négliger : changer de courbe elliptique. La plupart des gens pensent que ça ne change pas grand-chose, mais en réalité, ça entraîne tout le reste.
//
D’abord, pourquoi on ne peut pas simplement reprendre la même logique que pour Bitcoin et Ethereum
secp256k1 est la courbe la plus populaire dans le monde des portefeuilles de mineurs, mais elle n’a absolument pas été conçue pour les preuves zk. Le système de preuve (par exemple, les courbes comme BN254 derrière Plonk, ou BLS12-381) restreint toutes les opérations à un domaine scalaire spécifique. Dans le circuit, les additions et multiplications doivent toutes être effectuées dans ce domaine. Le domaine de secp256k1 ne correspond tout simplement pas à celui de ces systèmes de preuve. Forcer la vérification d’une signature secp256k1 dans le circuit nécessite de simuler des « opérations non natives », au coût qui peut atteindre des centaines de fois celui des opérations natives — ce n’est pas impossible, c’est juste beaucoup trop cher.
//
JubJub, en revanche, a précisément été pensée pour résoudre cette incompatibilité
C’est une courbe de type twisted Edwards. Son domaine s’insère exactement dans le domaine scalaire de BLS12-381. Autrement dit, dans le circuit Plonk, les opérations sur les points de JubJub se font avec des opérations natives : le coût baisse drastiquement. Pour traiter la génération de clés, la signature et le chiffrement, c’est naturellement aligné avec le système de preuve, sans détour.
//
Parlons aussi de ce que “l’abstraction de groupe” doit résoudre
Les courbes sous forme Edwards ont généralement un cofactor différent de 1. En clair, ce que l’on appelle un « même point logique » peut correspondre à plusieurs représentations d’octets différentes sur la courbe. Cette ambiguïté de représentation a effectivement causé des failles dans l’histoire : l’attaquant peut exploiter des sous-groupes liés au cofactor pour construire des cas limites et contourner la vérification. Dans l’industrie, une solution courante consiste à ajouter une couche d’abstraction de groupe par-dessus la courbe afin d’éliminer cette ambiguïté, garantissant qu’un point n’a qu’une seule écriture normalisée, et donc en bloquant ces attaques à la source.
//
Comparer ce choix avec secp256k1, la courbe la plus populaire dans le monde des mineurs, rend tout évident : l’une est conçue pour l’efficacité de la vérification de signatures et la compatibilité d’écosystème, l’autre pour le coût des opérations et les frontières de sécurité au sein du système de preuve. Elles ne poursuivent pas du tout le même objectif. Changer de courbe peut sembler très technique, très “pointu”, mais la décision détermine directement si toute la chaîne zk sera peu coûteuse ou non, propre ou susceptible de laisser des failles.
@Dusk_Foundation $DUSK #dusk
Pourquoi la courbe JubJub s’intègre-t-elle aussi bien au système de preuves de Dusk ?
//
D’abord, pourquoi on ne peut pas simplement reprendre la même logique que pour Bitcoin et Ethereum
secp256k1 est la courbe la plus populaire dans le monde des portefeuilles de mineurs, mais elle n’a absolument pas été conçue pour les preuves zk. Le système de preuve (par exemple, les courbes comme BN254 derrière Plonk, ou BLS12-381) restreint toutes les opérations à un domaine scalaire spécifique. Dans le circuit, les additions et multiplications doivent toutes être effectuées dans ce domaine. Le domaine de secp256k1 ne correspond tout simplement pas à celui de ces systèmes de preuve. Forcer la vérification d’une signature secp256k1 dans le circuit nécessite de simuler des « opérations non natives », au coût qui peut atteindre des centaines de fois celui des opérations natives — ce n’est pas impossible, c’est juste beaucoup trop cher.
//
JubJub, en revanche, a précisément été pensée pour résoudre cette incompatibilité
C’est une courbe de type twisted Edwards. Son domaine s’insère exactement dans le domaine scalaire de BLS12-381. Autrement dit, dans le circuit Plonk, les opérations sur les points de JubJub se font avec des opérations natives : le coût baisse drastiquement. Pour traiter la génération de clés, la signature et le chiffrement, c’est naturellement aligné avec le système de preuve, sans détour.
//
Parlons aussi de ce que “l’abstraction de groupe” doit résoudre
Les courbes sous forme Edwards ont généralement un cofactor différent de 1. En clair, ce que l’on appelle un « même point logique » peut correspondre à plusieurs représentations d’octets différentes sur la courbe. Cette ambiguïté de représentation a effectivement causé des failles dans l’histoire : l’attaquant peut exploiter des sous-groupes liés au cofactor pour construire des cas limites et contourner la vérification. Dans l’industrie, une solution courante consiste à ajouter une couche d’abstraction de groupe par-dessus la courbe afin d’éliminer cette ambiguïté, garantissant qu’un point n’a qu’une seule écriture normalisée, et donc en bloquant ces attaques à la source.
//
Comparer ce choix avec secp256k1, la courbe la plus populaire dans le monde des mineurs, rend tout évident : l’une est conçue pour l’efficacité de la vérification de signatures et la compatibilité d’écosystème, l’autre pour le coût des opérations et les frontières de sécurité au sein du système de preuve. Elles ne poursuivent pas du tout le même objectif. Changer de courbe peut sembler très technique, très “pointu”, mais la décision détermine directement si toute la chaîne zk sera peu coûteuse ou non, propre ou susceptible de laisser des failles.
@Dusk_Foundation $DUSK #dusk
Pourquoi la courbe JubJub s’intègre-t-elle aussi bien au système de preuves de Dusk ?
A. 域嵌在BLS12-381标量域里运算走原生路径,成本低
B. 它是secp256k1的升级版,兼容性更好
C. 它算力消耗更大,安全性更强
3 jour(s) restant(s)
