#dusk $DUSK @Dusk Je ne cessais de revenir à une seule chose dans les récents développements de Dusk, et ce n’est pas la cryptographie elle-même.
C’est l’effort pour faire en sorte que la même cryptographie produise davantage.
Le travail d’optimisation des performances PLONK n’a pas remplacé les mathématiques sous-jacentes, la structure du transcript, ni le format de preuve. Au lieu de cela, Dusk s’est attaqué au travail perdu autour de tout ça : mise en cache des données déterministes, regroupement des inversions et des opérations MSM, parallélisation des tâches FFT indépendantes, et évitement des calculs répétés.
Le résultat a attiré mon attention : temps de preuve en baisse de 58 %, environ 2,4× de capacité de preuve, vérification 44 % plus rapide, et compilation 25 % plus rapide.
Mais soyons honnêtes : les chiffres sont presque secondaires.
Ce qui m’intéresse, ce sont les enseignements qu’ils révèlent sur le prochain problème.
La confidentialité peut être mathématiquement solide et pourtant devenir impraticable si la preuve, la vérification ou l’exécution ne suivent pas.
Je vois une question similaire dans les tests DuskEVM × DuskDS. Des modèles d’exécution et d’état différents sont mis à l’épreuve via des charges mixtes plutôt que d’être jugés séparément.
Cela ressemble davantage au défi réel : pas de savoir si chaque élément fonctionne, mais s’ils continuent de fonctionner ensemble quand le système devient très sollicité.
Je me demande donc si le problème d’ingénierie le plus difficile de Dusk n’est plus de faire fonctionner la confidentialité.
C’est de rendre la confidentialité, l’exécution et la coordination presque invisibles pour l’utilisateur.
C’est probablement le test le plus intéressant.
#dusk
C’est l’effort pour faire en sorte que la même cryptographie produise davantage.
Le travail d’optimisation des performances PLONK n’a pas remplacé les mathématiques sous-jacentes, la structure du transcript, ni le format de preuve. Au lieu de cela, Dusk s’est attaqué au travail perdu autour de tout ça : mise en cache des données déterministes, regroupement des inversions et des opérations MSM, parallélisation des tâches FFT indépendantes, et évitement des calculs répétés.
Le résultat a attiré mon attention : temps de preuve en baisse de 58 %, environ 2,4× de capacité de preuve, vérification 44 % plus rapide, et compilation 25 % plus rapide.
Mais soyons honnêtes : les chiffres sont presque secondaires.
Ce qui m’intéresse, ce sont les enseignements qu’ils révèlent sur le prochain problème.
La confidentialité peut être mathématiquement solide et pourtant devenir impraticable si la preuve, la vérification ou l’exécution ne suivent pas.
Je vois une question similaire dans les tests DuskEVM × DuskDS. Des modèles d’exécution et d’état différents sont mis à l’épreuve via des charges mixtes plutôt que d’être jugés séparément.
Cela ressemble davantage au défi réel : pas de savoir si chaque élément fonctionne, mais s’ils continuent de fonctionner ensemble quand le système devient très sollicité.
Je me demande donc si le problème d’ingénierie le plus difficile de Dusk n’est plus de faire fonctionner la confidentialité.
C’est de rendre la confidentialité, l’exécution et la coordination presque invisibles pour l’utilisateur.
C’est probablement le test le plus intéressant.
#dusk