#dusk $DUSK @Dusk
Eu esperava que $DUSK fosse outro whitepaper cheio de promessas familiares sobre privacidade. Então mergulhei na criptografia, e uma pequena escolha de design continuou me puxando de volta.
A Dusk não parece interessada em fazer uma única primitiva fazer tudo.
BLS12-381 é usado onde assinaturas e provas compatíveis com emparelhamento fazem sentido. Jubjub se encaixa melhor dentro de circuitos orientados à privacidade. Poseidon é escolhido para hashing onde os custos das restrições de zero-knowledge realmente importam.
A última parte foi o que me chamou a atenção.
Uma hash pode ser perfeitamente eficiente em computação normal e ainda assim se tornar cara quando você a coloca dentro de um sistema de prova. Então a otimização não é realmente “qual primitiva é a mais forte?”.
É mais “qual primitiva é a mais barata para o trabalho que ela de fato precisa executar?”.
Até a agregação BLS segue essa lógica. Múltiplas atestações podem ser comprimidas em vez de serem carregadas e verificadas de forma independente, reduzindo tanto os dados quanto a pressão de verificação.
Eu gosto do raciocínio por trás disso.
Mas a especialização também tem um custo. Cada componente extra cria outro relacionamento que precisa continuar correto conforme o sistema cresce.
Então eu estou menos interessado em como a criptografia da Dusk parece sofisticada no papel.
Estou mais curioso para saber se essas peças especializadas permanecem composáveis sem transformar a complexidade em fragilidade oculta à medida que mais aplicações de privacidade compartilham a mesma pilha.
@Dusk #dusk $DUSK
Eu esperava que $DUSK fosse outro whitepaper cheio de promessas familiares sobre privacidade. Então mergulhei na criptografia, e uma pequena escolha de design continuou me puxando de volta.
A Dusk não parece interessada em fazer uma única primitiva fazer tudo.
BLS12-381 é usado onde assinaturas e provas compatíveis com emparelhamento fazem sentido. Jubjub se encaixa melhor dentro de circuitos orientados à privacidade. Poseidon é escolhido para hashing onde os custos das restrições de zero-knowledge realmente importam.
A última parte foi o que me chamou a atenção.
Uma hash pode ser perfeitamente eficiente em computação normal e ainda assim se tornar cara quando você a coloca dentro de um sistema de prova. Então a otimização não é realmente “qual primitiva é a mais forte?”.
É mais “qual primitiva é a mais barata para o trabalho que ela de fato precisa executar?”.
Até a agregação BLS segue essa lógica. Múltiplas atestações podem ser comprimidas em vez de serem carregadas e verificadas de forma independente, reduzindo tanto os dados quanto a pressão de verificação.
Eu gosto do raciocínio por trás disso.
Mas a especialização também tem um custo. Cada componente extra cria outro relacionamento que precisa continuar correto conforme o sistema cresce.
Então eu estou menos interessado em como a criptografia da Dusk parece sofisticada no papel.
Estou mais curioso para saber se essas peças especializadas permanecem composáveis sem transformar a complexidade em fragilidade oculta à medida que mais aplicações de privacidade compartilham a mesma pilha.
@Dusk #dusk $DUSK