Eu comecei a questionar a narrativa de contagem de portas da DUSK quando um XOR de 8 bits modelado caiu de 31 portas para uma única busca (lookup) PlonKup. A compressão parece impressionante, 96,8%. Mas isso reflete aritmética do circuito e não a velocidade real de prova.
Uma busca ainda exige lidar com tabelas, ordenação de compromissos e pressão de memória. Então, 31× menos portas não significa 31× mais rápido para provar. O custo pode simplesmente mudar para a RAM.
Isso importa porque as diretrizes do operador da DUSK orçam cerca de 1 GB por worker de prova e 8 GB para um servidor mínimo. Esses são valores de dimensionamento, não memória de pico medida. A métrica que falta é provas por GB no P50 e no P99 sob carga, especialmente com workers concorrentes.
Depois vem a acessibilidade. O que acontece em um celular de faixa média depois de aquecimento, apps em segundo plano e provas repetidas? Se o P50 for aceitável, mas o P99 travar, a privacidade vira atrito para o usuário, não apenas um ganho em criptografia.
Também estou observando provas malformadas. Quanta CPU uma entrada inválida pode consumir antes da rejeição e quanto o filtro antecipado economiza? Alguma sobrecarga é normal. Amplificação ilimitada não.
A DUSK pode ter sucesso se a compressão via lookup melhorar o throughput real sem concentrar a prova em hardware de alta memória. Até a DUSK publicar tempo de prova, uso de RAM de pico e energia, além de benchmarks de rejeição de provas inválidas, permanece incompleto.
#dusk $DUSK @Dusk
Uma busca ainda exige lidar com tabelas, ordenação de compromissos e pressão de memória. Então, 31× menos portas não significa 31× mais rápido para provar. O custo pode simplesmente mudar para a RAM.
Isso importa porque as diretrizes do operador da DUSK orçam cerca de 1 GB por worker de prova e 8 GB para um servidor mínimo. Esses são valores de dimensionamento, não memória de pico medida. A métrica que falta é provas por GB no P50 e no P99 sob carga, especialmente com workers concorrentes.
Depois vem a acessibilidade. O que acontece em um celular de faixa média depois de aquecimento, apps em segundo plano e provas repetidas? Se o P50 for aceitável, mas o P99 travar, a privacidade vira atrito para o usuário, não apenas um ganho em criptografia.
Também estou observando provas malformadas. Quanta CPU uma entrada inválida pode consumir antes da rejeição e quanto o filtro antecipado economiza? Alguma sobrecarga é normal. Amplificação ilimitada não.
A DUSK pode ter sucesso se a compressão via lookup melhorar o throughput real sem concentrar a prova em hardware de alta memória. Até a DUSK publicar tempo de prova, uso de RAM de pico e energia, além de benchmarks de rejeição de provas inválidas, permanece incompleto.
#dusk $DUSK @Dusk