#dusk $DUSK @Dusk Eu estava verificando minha pequena posição de teste DUSK hoje e me peguei fazendo uma suposição bem básica: antes eu achava que árvores de Merkle e provas de conhecimento zero estavam fazendo aproximadamente o mesmo trabalho.
Ao olhar mais a fundo para a @Dusk, isso mudou para mim.
Dusk-Merkle e PLONK não são intercambiáveis. Elas resolvem problemas diferentes, e essa distinção importa quando tentamos entender de onde a privacidade realmente vem.
Dusk-Merkle é uma árvore Merkle esparsa personalizada, agnóstica a funções hash. Ela pode ser usada em diferentes partes da rede, incluindo Stake, Transfer e Citadel.
A forma simples como penso agora:
Merkle = comprometer-se com o estado.
PLONK = provar um cálculo.
Uma árvore de Merkle pode compactar um estado estruturado em uma raiz. Uma abertura Merkle pode então provar que um item específico pertence a essa estrutura comprometida, sem exigir que o verificador processe toda a árvore.
PLONK vai para outro lugar. Ele permite que um provador demonstre que uma afirmação ou cálculo satisfaz um circuito sem revelar a informação privada usada para produzir essa prova.
Essa separação realmente tornou a arquitetura $DUSK mais fácil de entender para mim.
A árvore organiza e se compromete com o estado.
O circuito define o que deve ser verdadeiro.
A prova demonstra que as regras foram satisfeitas.
O contrato pode então determinar qual transição de estado segue.
Mas aqui está a parte que eu acho mais interessante.
Flexibilidade não é automaticamente segurança.
Uma implementação agnóstica a função hash de Merkle ainda depende de escolher a função hash certa e de implementar as aberturas corretamente. Circuitos PLONK reutilizáveis têm uma troca semelhante: eles reduzem trabalho duplicado, mas uma suposição falha pode potencialmente ser reutilizada em várias aplicações.
Então eu não estou apenas observando se o DUSK usa ZK.
Estou observando se cada componente criptográfico está fazendo exatamente o trabalho que deveria fazer.
#dusk $DUSK
@Dusk
$BTW
$TUT
$CYS
O que mais importa para a privacidade do Dusk?
Ao olhar mais a fundo para a @Dusk, isso mudou para mim.
Dusk-Merkle e PLONK não são intercambiáveis. Elas resolvem problemas diferentes, e essa distinção importa quando tentamos entender de onde a privacidade realmente vem.
Dusk-Merkle é uma árvore Merkle esparsa personalizada, agnóstica a funções hash. Ela pode ser usada em diferentes partes da rede, incluindo Stake, Transfer e Citadel.
A forma simples como penso agora:
Merkle = comprometer-se com o estado.
PLONK = provar um cálculo.
Uma árvore de Merkle pode compactar um estado estruturado em uma raiz. Uma abertura Merkle pode então provar que um item específico pertence a essa estrutura comprometida, sem exigir que o verificador processe toda a árvore.
PLONK vai para outro lugar. Ele permite que um provador demonstre que uma afirmação ou cálculo satisfaz um circuito sem revelar a informação privada usada para produzir essa prova.
Essa separação realmente tornou a arquitetura $DUSK mais fácil de entender para mim.
A árvore organiza e se compromete com o estado.
O circuito define o que deve ser verdadeiro.
A prova demonstra que as regras foram satisfeitas.
O contrato pode então determinar qual transição de estado segue.
Mas aqui está a parte que eu acho mais interessante.
Flexibilidade não é automaticamente segurança.
Uma implementação agnóstica a função hash de Merkle ainda depende de escolher a função hash certa e de implementar as aberturas corretamente. Circuitos PLONK reutilizáveis têm uma troca semelhante: eles reduzem trabalho duplicado, mas uma suposição falha pode potencialmente ser reutilizada em várias aplicações.
Então eu não estou apenas observando se o DUSK usa ZK.
Estou observando se cada componente criptográfico está fazendo exatamente o trabalho que deveria fazer.
#dusk $DUSK
@Dusk
$BTW
$TUT
$CYS
O que mais importa para a privacidade do Dusk?
Merkle commits state
0%
PLONK proves rules
0%
Both have boundaries
0%
Which matters most?
0%
0 Votos • Votação encerrada