J’ai commencé à remettre en question le récit de DUSK sur le nombre de portes lorsque, dans une modélisation, un XOR 8 bits est passé de 31 portes à une simple recherche PlonKup. La compression paraît spectaculaire à 96,8 %. Mais cela reflète l’arithmétique du circuit, pas la vitesse réelle de preuve.
Une recherche implique toutefois la gestion de tables, le tri des engagements et une pression sur la mémoire. Donc 31 fois moins de portes ne signifie pas 31 fois plus rapide pour prouver. Le coût peut simplement se déplacer vers la RAM.
C’est important car les recommandations d’opérateurs de DUSK prévoient environ 1 Go par worker de preuve et 8 Go pour un serveur minimal. Ce sont des chiffres de dimensionnement, pas des mesures du pic de mémoire. La métrique manquante est le nombre de preuves par Go aux charges P50 et P99, notamment avec des workers en concurrence.
Vient ensuite l’accessibilité. Que se passe-t-il sur un téléphone milieu de gamme après la chaleur, des applications en arrière-plan et des preuves répétées ? Si P50 est acceptable mais que P99 se bloque, alors la confidentialité devient une source de friction utilisateur, pas seulement un avantage cryptographique.
Je surveille aussi les preuves mal formées. Combien de CPU un input invalide peut-il consommer avant d’être rejeté, et combien un filtrage précoce permet-il d’économiser ? Un certain surcoût est normal. Une amplification non bornée ne l’est pas.
DUSK peut réussir si la compression par recherche améliore le débit réel sans concentrer la génération de preuves sur du matériel très gourmand en mémoire. Tant que DUSK ne publie pas des benchmarks de temps de preuve, d’utilisation d’énergie et de RAM au pic, ainsi que des mesures de rejet des preuves invalides, l’évaluation reste incomplète.
#dusk $DUSK @Dusk
Une recherche implique toutefois la gestion de tables, le tri des engagements et une pression sur la mémoire. Donc 31 fois moins de portes ne signifie pas 31 fois plus rapide pour prouver. Le coût peut simplement se déplacer vers la RAM.
C’est important car les recommandations d’opérateurs de DUSK prévoient environ 1 Go par worker de preuve et 8 Go pour un serveur minimal. Ce sont des chiffres de dimensionnement, pas des mesures du pic de mémoire. La métrique manquante est le nombre de preuves par Go aux charges P50 et P99, notamment avec des workers en concurrence.
Vient ensuite l’accessibilité. Que se passe-t-il sur un téléphone milieu de gamme après la chaleur, des applications en arrière-plan et des preuves répétées ? Si P50 est acceptable mais que P99 se bloque, alors la confidentialité devient une source de friction utilisateur, pas seulement un avantage cryptographique.
Je surveille aussi les preuves mal formées. Combien de CPU un input invalide peut-il consommer avant d’être rejeté, et combien un filtrage précoce permet-il d’économiser ? Un certain surcoût est normal. Une amplification non bornée ne l’est pas.
DUSK peut réussir si la compression par recherche améliore le débit réel sans concentrer la génération de preuves sur du matériel très gourmand en mémoire. Tant que DUSK ne publie pas des benchmarks de temps de preuve, d’utilisation d’énergie et de RAM au pic, ainsi que des mesures de rejet des preuves invalides, l’évaluation reste incomplète.
#dusk $DUSK @Dusk