#dusk $DUSK @Dusk Passou a tarde cavando o relatório do incidente do Dusk do início deste ano, especificamente a pausa da ponte em janeiro. Você sabe como é: você começa com a postagem oficial do blog e acaba três commits mais fundo no repositório tentando descobrir o que exatamente quebrou.
O Dusk se vende como uma camada 1 com foco em privacidade e pronta para regulação voltada a finanças institucionais. Mas em janeiro, a equipe teve que desativar endereços de ponte e reciclar uma carteira porque perdeu o controle dela. A versão oficial é que "os fundos dos usuários não foram afetados" e que "não foi um problema de protocolo". Tudo bem.
Mas essa distinção está fazendo muito trabalho pesado. Uma ponte é a porta de entrada para a rede; se o porteiro derruba as chaves, não importa o quão segura seja a caixa-forte. A blocklist do Web Wallet que eles lançaram às pressas é também um lembrete contundente de que, embora o Dusk fale em conformidade descentralizada, a arquitetura ainda se inclina para controles administrativos baseados em multisig.
E, para ser justo, os devs não estão dormindo. Eles estavam empurrando melhorias na UX de bridging do DuskEVM quase imediatamente, correndo para colocar a migração do testnet de volta no ar antes que a liquidez se dispersasse. O foco do desenvolvimento claramente mudou de consenso do nó central do Rusk para a camada de compatibilidade com EVM e uma UX de bridging mais segura.
Quando eu comparo isso com o ethos da Ethereum, em que, quando um contrato inteligente tem um problema, ele é imutável — muitas vezes resultando em perdas catastróficas para usuários, mas com zero intervenção administrativa. O Dusk escolheu o caminho oposto: contenção centralizada via contratos inteligentes atualizáveis para proteger os usuários, mas ao custo da narrativa de "ininterruptibilidade".
Então, se uma cadeia de privacidade compatível exige controles multisig para pausar fundos e colocar endereços em blacklist no momento em que uma chave vaza, o que exatamente estamos comprando? É só TradFi com etapas extras, ou o controle administrativo é o produto, e não o bug?
O Dusk se vende como uma camada 1 com foco em privacidade e pronta para regulação voltada a finanças institucionais. Mas em janeiro, a equipe teve que desativar endereços de ponte e reciclar uma carteira porque perdeu o controle dela. A versão oficial é que "os fundos dos usuários não foram afetados" e que "não foi um problema de protocolo". Tudo bem.
Mas essa distinção está fazendo muito trabalho pesado. Uma ponte é a porta de entrada para a rede; se o porteiro derruba as chaves, não importa o quão segura seja a caixa-forte. A blocklist do Web Wallet que eles lançaram às pressas é também um lembrete contundente de que, embora o Dusk fale em conformidade descentralizada, a arquitetura ainda se inclina para controles administrativos baseados em multisig.
E, para ser justo, os devs não estão dormindo. Eles estavam empurrando melhorias na UX de bridging do DuskEVM quase imediatamente, correndo para colocar a migração do testnet de volta no ar antes que a liquidez se dispersasse. O foco do desenvolvimento claramente mudou de consenso do nó central do Rusk para a camada de compatibilidade com EVM e uma UX de bridging mais segura.
Quando eu comparo isso com o ethos da Ethereum, em que, quando um contrato inteligente tem um problema, ele é imutável — muitas vezes resultando em perdas catastróficas para usuários, mas com zero intervenção administrativa. O Dusk escolheu o caminho oposto: contenção centralizada via contratos inteligentes atualizáveis para proteger os usuários, mas ao custo da narrativa de "ininterruptibilidade".
Então, se uma cadeia de privacidade compatível exige controles multisig para pausar fundos e colocar endereços em blacklist no momento em que uma chave vaza, o que exatamente estamos comprando? É só TradFi com etapas extras, ou o controle administrativo é o produto, e não o bug?