Hoje à noite, derramei e revisei os logs do nó e, de repente, me lembrei de uma treta que tive semana passada com um amigo que faz auditoria.
A queda do cenário (boatos) foi um pouco, mas a tendência de alta do BTC continua!
Ele me perguntou: “Vocês que rodam Dusk, realmente ficam tranquilos em jogar a lógica de validação fora do WASM?” Eu não consegui responder na hora — de boca dura eu disse “o whitepaper é auditado”, mas por dentro eu estava inseguro. Só hoje à noite, ao abrir o GitHub deles e ver o conjunto de testes do Piecrust para a função host, é que senti que peguei um pedaço do caminho.
Em outras palavras: a mentalidade tradicional de “trancar tudo no sandbox” é como ir a uma conveniência comprar um maço de cigarros — primeiro você passa no detector de segurança, verifica o documento, revira a bolsa, e só então te deixam pagar. É seguro, mas quem está na fila depois vai reclamar.
A Dusk apostou em outra rota: ações de alta frequência vão por um canal dedicado, e só as ações de baixa frequência passam pela catraca.
Eles citaram dados de terceiros — eu fui conferir o texto original. O artigo mede a perda de desempenho do WASM em relação ao nativo sob diferentes conjuntos de instruções. No cenário de criptografia mais extremo, chega a 255% de overhead. Faz a conta: quantas transações por dia a Dusk tem que passar por validação de assinatura BLS, e quantas têm que passar por prova ZK? Se cada transação fizer o WASM interpretar tudo, é como rodar cada quilômetro e ainda pagar meio litro a mais de “gasolina” por mais 2,5 quilômetros. Quem aguenta?
Então eles transformam essas coisas em nível de chamada de sistema, chamando diretamente a implementação nativa. O custo disso é que o raio de confiança, que antes era “esse caixote do sandbox do WASM”, encolhe para “aquelas poucas linhas de código C da função do host”. Esses dois riscos não têm a mesma ordem de grandeza: um é isolamento físico, o outro é qualidade de código.
Eu revisei o relatório de auditoria da Q3 de 2024 deles (escondido bem num canto do site). Pelo menos naquela época, os casos de borda testados não estouraram. Mas, sendo bem honesto, esse tipo de superfície de ataque não é “medido e descoberto” — é “explorado”. Um dia alguém fornece um conjunto de dados de prova cuidadosamente construído, gatilha algum estouro de inteiro na host function que ninguém tinha notado… a cena é até demais pra eu imaginar.
Mas, por outro lado: se você realmente busca “segurança absoluta”, não brinque com blockchain pública — volte e escreva um programa standalone. O pessoal da Dusk aposta que o gargalo de desempenho te trava primeiro, e que os problemas de segurança ainda dá para corrigir. @Dusk $DUSK #dusk
A queda do cenário (boatos) foi um pouco, mas a tendência de alta do BTC continua!
Ele me perguntou: “Vocês que rodam Dusk, realmente ficam tranquilos em jogar a lógica de validação fora do WASM?” Eu não consegui responder na hora — de boca dura eu disse “o whitepaper é auditado”, mas por dentro eu estava inseguro. Só hoje à noite, ao abrir o GitHub deles e ver o conjunto de testes do Piecrust para a função host, é que senti que peguei um pedaço do caminho.
Em outras palavras: a mentalidade tradicional de “trancar tudo no sandbox” é como ir a uma conveniência comprar um maço de cigarros — primeiro você passa no detector de segurança, verifica o documento, revira a bolsa, e só então te deixam pagar. É seguro, mas quem está na fila depois vai reclamar.
A Dusk apostou em outra rota: ações de alta frequência vão por um canal dedicado, e só as ações de baixa frequência passam pela catraca.
Eles citaram dados de terceiros — eu fui conferir o texto original. O artigo mede a perda de desempenho do WASM em relação ao nativo sob diferentes conjuntos de instruções. No cenário de criptografia mais extremo, chega a 255% de overhead. Faz a conta: quantas transações por dia a Dusk tem que passar por validação de assinatura BLS, e quantas têm que passar por prova ZK? Se cada transação fizer o WASM interpretar tudo, é como rodar cada quilômetro e ainda pagar meio litro a mais de “gasolina” por mais 2,5 quilômetros. Quem aguenta?
Então eles transformam essas coisas em nível de chamada de sistema, chamando diretamente a implementação nativa. O custo disso é que o raio de confiança, que antes era “esse caixote do sandbox do WASM”, encolhe para “aquelas poucas linhas de código C da função do host”. Esses dois riscos não têm a mesma ordem de grandeza: um é isolamento físico, o outro é qualidade de código.
Eu revisei o relatório de auditoria da Q3 de 2024 deles (escondido bem num canto do site). Pelo menos naquela época, os casos de borda testados não estouraram. Mas, sendo bem honesto, esse tipo de superfície de ataque não é “medido e descoberto” — é “explorado”. Um dia alguém fornece um conjunto de dados de prova cuidadosamente construído, gatilha algum estouro de inteiro na host function que ninguém tinha notado… a cena é até demais pra eu imaginar.
Mas, por outro lado: se você realmente busca “segurança absoluta”, não brinque com blockchain pública — volte e escreva um programa standalone. O pessoal da Dusk aposta que o gargalo de desempenho te trava primeiro, e que os problemas de segurança ainda dá para corrigir. @Dusk $DUSK #dusk