No meio do ano passado, eu ainda ficava discutindo com gente — “Verificar lógica fora do sandbox do WASM? Isso não é você mesmo cavar um buraco pra si”. Naquela época, eu tinha acabado de ler um relatório de retrospecto de certa cadeia que foi esvaziada por causa de uma brecha em contrato inteligente, e minha cabeça estava cheia de “quanto menos código, mais seguro”.
Mas a correção vai voltar em que ponto? O BTC ainda tem espaço pra subir?
Só que, quando finalmente coloquei a mão pra rodar um nó do Dusk, percebi que não era tão simples.
Eu revisei o código de teste daquela solução deles, a Piecrust, e também procurei a paper de desempenho que foi citada várias vezes — o estudo mediu o overhead do WASM em relação ao código nativo sob diferentes conjuntos de instruções, e em cenários de criptografia o custo chegou a 255%. Você imagina: as assinaturas BLS e as provas ZK que o Dusk lida todo dia… qual delas não é uma grande consumidora de computação? Cada transação precisa interpretar e executar dentro do WASM; é como você rodar um carro com consumo de 25 litros a cada 100 km — o dono do posto até ri à vontade, mas sua carteira não aguenta primeiro.
Então eles transformam as operações de cripto de alta frequência em host functions e chamam diretamente a implementação nativa. Em outras palavras: não coloca obstáculos nas rotas que você percorre o tempo todo; quando for uma rota ocasional, aí sim fiscaliza mais.
Risco, claro, existe — a “distância de confiança” diminuiu de “todo o sandbox do WASM” para “se aquelas poucas linhas de C código têm ou não escrito algo que solta fumaça”. A primeira é aquela sensação de segurança por isolamento físico; a segunda depende totalmente de o engenheiro ser cuidadoso e manter a mão firme. Eu fui até um cantinho do site oficial e achei o relatório de auditoria do 3º trimestre de 2024 — pelo menos, naquele momento, os limites que eles testaram não explodiram. Mas, no fim das contas, esse tipo de vulnerabilidade nunca é descoberto só “testando”; ele é alimentado por dados fornecidos por pessoas. Um dia alguém injeta uma prova cuidadosamente forjada e ativa um overflow inteiro num host function que ninguém notou — puxa… essa cena eu, por enquanto, não quero ver com meus próprios olhos.
Mas se você busca algo quase infalível, então nem mexa com blockchain pública: volte e escreva um programa local, é muito mais tranquilo. O pessoal do Dusk está fazendo outra conta: desempenho é um problema de hoje; segurança pode ser remendada amanhã. Eu rodei nós por três anos e vi cadeias morrerem em nove de cada dez casos porque o gas era alto demais pra ninguém usar, ou porque, ao ser comprometida, tudo zera direto — enfim, não foi algo que eu tenha presenciado ao vivo.
Então minha postura hoje não é tão rígida. Antes, com amigos, eu ainda insistia no “vamos observar mais um pouco” e, de volta pra casa, silenciosamente atualizei a versão do nó pra a mais recente. Projetos que realmente abrem buracos no sandbox não são muitos; o Dusk conta um. #dusk $DUSK @Dusk
Mas a correção vai voltar em que ponto? O BTC ainda tem espaço pra subir?
Só que, quando finalmente coloquei a mão pra rodar um nó do Dusk, percebi que não era tão simples.
Eu revisei o código de teste daquela solução deles, a Piecrust, e também procurei a paper de desempenho que foi citada várias vezes — o estudo mediu o overhead do WASM em relação ao código nativo sob diferentes conjuntos de instruções, e em cenários de criptografia o custo chegou a 255%. Você imagina: as assinaturas BLS e as provas ZK que o Dusk lida todo dia… qual delas não é uma grande consumidora de computação? Cada transação precisa interpretar e executar dentro do WASM; é como você rodar um carro com consumo de 25 litros a cada 100 km — o dono do posto até ri à vontade, mas sua carteira não aguenta primeiro.
Então eles transformam as operações de cripto de alta frequência em host functions e chamam diretamente a implementação nativa. Em outras palavras: não coloca obstáculos nas rotas que você percorre o tempo todo; quando for uma rota ocasional, aí sim fiscaliza mais.
Risco, claro, existe — a “distância de confiança” diminuiu de “todo o sandbox do WASM” para “se aquelas poucas linhas de C código têm ou não escrito algo que solta fumaça”. A primeira é aquela sensação de segurança por isolamento físico; a segunda depende totalmente de o engenheiro ser cuidadoso e manter a mão firme. Eu fui até um cantinho do site oficial e achei o relatório de auditoria do 3º trimestre de 2024 — pelo menos, naquele momento, os limites que eles testaram não explodiram. Mas, no fim das contas, esse tipo de vulnerabilidade nunca é descoberto só “testando”; ele é alimentado por dados fornecidos por pessoas. Um dia alguém injeta uma prova cuidadosamente forjada e ativa um overflow inteiro num host function que ninguém notou — puxa… essa cena eu, por enquanto, não quero ver com meus próprios olhos.
Mas se você busca algo quase infalível, então nem mexa com blockchain pública: volte e escreva um programa local, é muito mais tranquilo. O pessoal do Dusk está fazendo outra conta: desempenho é um problema de hoje; segurança pode ser remendada amanhã. Eu rodei nós por três anos e vi cadeias morrerem em nove de cada dez casos porque o gas era alto demais pra ninguém usar, ou porque, ao ser comprometida, tudo zera direto — enfim, não foi algo que eu tenha presenciado ao vivo.
Então minha postura hoje não é tão rígida. Antes, com amigos, eu ainda insistia no “vamos observar mais um pouco” e, de volta pra casa, silenciosamente atualizei a versão do nó pra a mais recente. Projetos que realmente abrem buracos no sandbox não são muitos; o Dusk conta um. #dusk $DUSK @Dusk