No campo da privacidade na blockchain e das provas de conhecimento zero, quem realmente realiza um desenvolvimento profundo costuma admitir uma dor de cabeça central: ZK nunca foi uma questão de viabilidade funcional, mas sim de desempenho utilizável. Por mais refinados que sejam os artigos e white papers, uma vez na fase de implantação prática, o tempo de geração das provas costuma levar dezenas de segundos ou até minutos, fazendo com que a experiência do usuário colapse.
Muitas blockchains no mercado afirmam suportar provas de conhecimento zero, mas na prática, fazem uma integração forçada da lógica de circuito dentro do framework EVM. Essa solução, embora teoricamente viável, na prática é extremamente precária, como usar um trator na autoestrada — por mais que se pressione o acelerador, não se consegue alcançar a eficiência adequada.
Nos últimos anos, poucas blockchains conseguiram lidar com lógica de privacidade complexa; a razão não é a teoria da criptografia ainda não estar madura, mas sim que o ambiente de execução subjacente não acompanha as demandas. É por isso que a Dusk adotou uma rota de prática de engenharia completamente diferente: ao invés de aplicar patches na base do EVM, ela optou por redesenhar completamente a camada da máquina virtual, resultando na Piecrust Virtual Machine.
A missão da Piecrust VM é bem clara — ela não busca generalidade, mas sim um ambiente de execução especialmente criado para cálculos de conhecimento zero. A importância dessa escolha de design muitas vezes é negligenciada. O EVM, essencialmente, é otimizado para determinismo de estado e reprodutibilidade, nunca tendo considerado a compatibilidade com provas. Executar cálculos de conhecimento zero sobre o EVM equivale a executar lógica de negócio enquanto se lida com um custo adicional enorme de provas.
A Dusk inverteu essa lógica: já que o objetivo é privacidade e cálculo verificável, o modelo de execução, o conjunto de instruções e o gerenciamento de estado devem ser projetados desde o primeiro dia em torno das provas de conhecimento zero. O resultado é um salto de desempenho que parece contraintuitivo, mas é realmente viável — o tempo de geração das provas foi drasticamente reduzido, transformando o ZK de uma ideia teórica em um produto utilizável.
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
13 gostos
Recompensa
13
4
Republicar
Partilhar
Comentar
0/400
consensus_failure
· 11h atrás
No papel, tudo parece possível, mas na prática falha, essa é a verdadeira imagem do ZK
Espera aí, essa implementação Piecrust VM do Dusk realmente consegue rodar ou é mais uma daquelas que só serve para especulação...
Forçar lógica ZK na EVM como usar um martelo para pregar pregos, cedo ou tarde vai dar problema
A estrada de uma VM dedicada depende dos dados de testes reais, só falar não adianta
Falando nisso, alguém realmente usou algo do Dusk? Parece que o mercado está bem animado, mas o feedback real é escasso
Essa é a abordagem séria de engenharia, em vez de juntar coisas aleatórias, é melhor redesenhar do zero
ZK só vale a pena se for implementado na prática, mais um projeto que só existe na teoria sem usuários, o que adianta?
A ideia de uma designação exclusiva para Piecrust é realmente inovadora, mas dá para realmente superar o desempenho da EVM?
Ver originalResponder0
GasFeeTears
· 11h atrás
Mais uma analogia de um trator na autoestrada, mas desta vez parece que realmente há alguém a tentar resolver?
Ver originalResponder0
MEVHunterX
· 12h atrás
Porra, EVM com ZK é uma fraqueza, já devia ter mudado de abordagem há muito tempo
Ver originalResponder0
FreeMinter
· 12h atrás
Mais uma vez, o desempenho de ZK é um tema recorrente, mas a abordagem da Dusk realmente é diferente
Agora entendi por que tantas redes promovem resultados ZK que são apenas PPTs, a raiz do problema está errada
A operação do Piecrust é um pouco agressiva, uma VM dedicada realmente é uma solução viável
Mas será que realmente consegue rodar? Ainda temos que esperar pelos dados reais para falar
Dar patches forçados ao EVM é realmente como um trator acelerando, uma metáfora excelente haha
Essa é a postura de design correta, pensando no ZK desde a camada fundamental
Parece que o mercado de criptomoedas realmente carece de projetos que façam trabalho duro de verdade
No campo da privacidade na blockchain e das provas de conhecimento zero, quem realmente realiza um desenvolvimento profundo costuma admitir uma dor de cabeça central: ZK nunca foi uma questão de viabilidade funcional, mas sim de desempenho utilizável. Por mais refinados que sejam os artigos e white papers, uma vez na fase de implantação prática, o tempo de geração das provas costuma levar dezenas de segundos ou até minutos, fazendo com que a experiência do usuário colapse.
Muitas blockchains no mercado afirmam suportar provas de conhecimento zero, mas na prática, fazem uma integração forçada da lógica de circuito dentro do framework EVM. Essa solução, embora teoricamente viável, na prática é extremamente precária, como usar um trator na autoestrada — por mais que se pressione o acelerador, não se consegue alcançar a eficiência adequada.
Nos últimos anos, poucas blockchains conseguiram lidar com lógica de privacidade complexa; a razão não é a teoria da criptografia ainda não estar madura, mas sim que o ambiente de execução subjacente não acompanha as demandas. É por isso que a Dusk adotou uma rota de prática de engenharia completamente diferente: ao invés de aplicar patches na base do EVM, ela optou por redesenhar completamente a camada da máquina virtual, resultando na Piecrust Virtual Machine.
A missão da Piecrust VM é bem clara — ela não busca generalidade, mas sim um ambiente de execução especialmente criado para cálculos de conhecimento zero. A importância dessa escolha de design muitas vezes é negligenciada. O EVM, essencialmente, é otimizado para determinismo de estado e reprodutibilidade, nunca tendo considerado a compatibilidade com provas. Executar cálculos de conhecimento zero sobre o EVM equivale a executar lógica de negócio enquanto se lida com um custo adicional enorme de provas.
A Dusk inverteu essa lógica: já que o objetivo é privacidade e cálculo verificável, o modelo de execução, o conjunto de instruções e o gerenciamento de estado devem ser projetados desde o primeiro dia em torno das provas de conhecimento zero. O resultado é um salto de desempenho que parece contraintuitivo, mas é realmente viável — o tempo de geração das provas foi drasticamente reduzido, transformando o ZK de uma ideia teórica em um produto utilizável.