#dusk $DUSK
Sobre o DUSK, sempre tive uma dúvida que não consigo entender!
A ponte do Dusk e a ponte cross-chain comum não são da mesma espécie.
Os dois lados que ela sincroniza têm lógicas de livro-razão totalmente diferentes: do lado do DuskDS é um livro-razão de liquidação com privacidade; todos os saldos e transações ficam dentro de cifras, então por fora parece apenas uma sequência sem sentido; do lado do DuskEVM, o que roda são contratos de títulos XSC, exigindo transparência e verificabilidade.
O trabalho da ponte é: você faz um depósito/caucionamento de um ativo XSC na camada de privacidade e, quando for executar uma transação na camada EVM, a ponte precisa primeiro confirmar que esse ativo realmente existe, sem ter sido forjado ou usado duas vezes.
Mas há um nó aqui. Como o livro-razão de privacidade é criptografado, como a ponte “enxerga” que o ativo de fato existe? Ela não consegue ver. Então, só resta o usuário enviar um proof ZK para provar que eu realmente detenho esse XSC na camada de privacidade e que a mudança de estado é válida.
A geração do proof roda uma vez um cálculo ZK; na verificação, a ponte roda de novo — uma segunda execução do ZK. A segurança da ponte fica totalmente apoiada nesse sistema de provas.
Então a OtterSec descobriu uma vulnerabilidade no dusk-plonk. O verificador pulou uma checagem crítica, e um proof falso passou direto. Em uma camada isso equivale a cunhar moedas do nada; travando US$ 60 milhões, isso já foi corrigido.
Mas eu verifiquei todo o material público e ninguém respondeu: a lógica de verificação da ponte nativa é a mesma coisa que o dusk-plonk, ou não?
Se não for, tudo bem. Se for, ou se reutilizar parcialmente parâmetros e templates de circuito, o problema sai de “cunhar moedas em uma camada” e vira “cunhar moedas entre camadas”: você falsifica uma posição de XSC inexistente na camada de privacidade, usa um proof falso para enganar a ponte e faz a camada EVM liberar o ativo correspondente, que então você usa para despejar/vender.
O atacante nem precisa mexer na lógica de contrato da ponte: basta que o sistema de provas tenha uma brecha, e a ponte vira uma máquina de saque.
Dito de forma justa: a verificação da ponte pode ter sido implementada de maneira independente, com auditorias extras, só que não foi divulgada publicamente. Eu não consigo provar que ela seja insegura, mas também não encontro evidências que provem que é segura.
Até hoje a oficial não divulgou o relatório de auditoria independente da ponte nativa, nem explicou se a verificação entre camadas é isolada por código ou não em relação ao dusk-plonk.
Antes do NPEX migrar títulos de alguns milhões de euros, esse problema precisa ser respondido de forma direta.
Não dá para passar apenas com “vulnerabilidade corrigida” em quatro palavras. A ponte não conecta apenas duas cadeias — ela é a única porta entre o mundo da privacidade e o mundo público. Se essa porta tem fechadura ou não, não espere alguém entrar para só então descobrir.
@Dusk
Sobre o DUSK, sempre tive uma dúvida que não consigo entender!
A ponte do Dusk e a ponte cross-chain comum não são da mesma espécie.
Os dois lados que ela sincroniza têm lógicas de livro-razão totalmente diferentes: do lado do DuskDS é um livro-razão de liquidação com privacidade; todos os saldos e transações ficam dentro de cifras, então por fora parece apenas uma sequência sem sentido; do lado do DuskEVM, o que roda são contratos de títulos XSC, exigindo transparência e verificabilidade.
O trabalho da ponte é: você faz um depósito/caucionamento de um ativo XSC na camada de privacidade e, quando for executar uma transação na camada EVM, a ponte precisa primeiro confirmar que esse ativo realmente existe, sem ter sido forjado ou usado duas vezes.
Mas há um nó aqui. Como o livro-razão de privacidade é criptografado, como a ponte “enxerga” que o ativo de fato existe? Ela não consegue ver. Então, só resta o usuário enviar um proof ZK para provar que eu realmente detenho esse XSC na camada de privacidade e que a mudança de estado é válida.
A geração do proof roda uma vez um cálculo ZK; na verificação, a ponte roda de novo — uma segunda execução do ZK. A segurança da ponte fica totalmente apoiada nesse sistema de provas.
Então a OtterSec descobriu uma vulnerabilidade no dusk-plonk. O verificador pulou uma checagem crítica, e um proof falso passou direto. Em uma camada isso equivale a cunhar moedas do nada; travando US$ 60 milhões, isso já foi corrigido.
Mas eu verifiquei todo o material público e ninguém respondeu: a lógica de verificação da ponte nativa é a mesma coisa que o dusk-plonk, ou não?
Se não for, tudo bem. Se for, ou se reutilizar parcialmente parâmetros e templates de circuito, o problema sai de “cunhar moedas em uma camada” e vira “cunhar moedas entre camadas”: você falsifica uma posição de XSC inexistente na camada de privacidade, usa um proof falso para enganar a ponte e faz a camada EVM liberar o ativo correspondente, que então você usa para despejar/vender.
O atacante nem precisa mexer na lógica de contrato da ponte: basta que o sistema de provas tenha uma brecha, e a ponte vira uma máquina de saque.
Dito de forma justa: a verificação da ponte pode ter sido implementada de maneira independente, com auditorias extras, só que não foi divulgada publicamente. Eu não consigo provar que ela seja insegura, mas também não encontro evidências que provem que é segura.
Até hoje a oficial não divulgou o relatório de auditoria independente da ponte nativa, nem explicou se a verificação entre camadas é isolada por código ou não em relação ao dusk-plonk.
Antes do NPEX migrar títulos de alguns milhões de euros, esse problema precisa ser respondido de forma direta.
Não dá para passar apenas com “vulnerabilidade corrigida” em quatro palavras. A ponte não conecta apenas duas cadeias — ela é a única porta entre o mundo da privacidade e o mundo público. Se essa porta tem fechadura ou não, não espere alguém entrar para só então descobrir.
@Dusk