Ontem à noite reli o white paper @Dusk e, quando cheguei à página sobre a “arquitetura de dupla VM”, travei.
Vamos começar pela arquitetura. Piecrust é uma VM nativa de conhecimento zero, baseada em WASM, com liquidação em 2–3 segundos. DuskEVM é compatível com Solidity; você consegue colocar Hardhat e MetaMask direto e fazer rodar. A privacidade é completada no nível de ZK pela Hedger. A ideia de design em duas trilhas realmente faz sentido: uma cuida dos contratos de privacidade e a outra cuida da compatibilidade, cada uma no seu papel.
Mas quanto mais eu avançava, mais parecia errado. A Piecrust desenvolveu sua própria VM. Em março deste ano, a auditoria AEGIS revelou 39 problemas, sendo 7 de severidade alta; dois bugs críticos ficaram presos na camada de sandbox. Mesmo nós honestos, executando o mesmo trecho de código, podem obter resultados diferentes. Contratos maliciosos podem empurrar o runtime para um estado em que a garantia de propriedade fica inválida. Se a sandbox for comprometida, todo o contrato confidencial acima vai à falência. Já a DuskEVM, por si só, só suporta transações públicas; toda a privacidade depende de módulos adicionais para “segurar a onda”. No fim, são duas VMs batendo uma na outra, e tanto o volume de código quanto a superfície de ataque praticamente dobram.
Agora, sobre a parceria. NPEX, Chainlink, Cordial, Quantoz, 21X — no site consta €300M+ em emissão confirmada, alcance de 50K+ investidores e 210M+ DUSK apostado. Os recursos realmente parecem mais sólidos do que projetos que só contam histórias de RWA. Mas o próprio time oficial também admite: tokenização reduz atrito, mas não dá para criar compradores, vendedores e profundidade de mercado. O Dusk Trade ainda está em Building/Waitlist, e tanto DuskEVM quanto Hedger ainda estão no Testnet. A lista de parcerias mostra que as partes topam colaborar; para valer mesmo, é preciso ver métricas duras como volume de ativos on-chain, número de traders e profundidade no secundário.
Por fim, a conexão entre compliance e privacidade. A Zedger, no momento da emissão, escreve na própria proposta a whitelist, identidade única por conta, e aprovação explícita do destinatário. A transferência é dividida em duas etapas; se houver timeout, ela é automaticamente cancelada. A Phoenix usa uma arquitetura UTXO: o dinheiro fica guardado em notas criptografadas; na execução, o ZK valida simultaneamente cinco coisas, e Pedersen Commitments esconde valores e endereços. O DuskDS confirma em três fases — quando o bloco é produzido, é definitivo. As regras definem o que pode ou não acontecer, a Phoenix controla quais partes não precisam ser públicas, e a DuskDS define qual estado conta. Esses três elos completam o mesmo ponto de ruptura: da emissão à liquidação, para que as operações não precisem voltar à camada off-chain e coordenar de novo.
A lista de parcerias já está bem “institucionalizada”. Na próxima fase, eu quero ver migração real e dados de成交 — não ficar sempre preso em PPT. #dusk $DUSK
Vamos começar pela arquitetura. Piecrust é uma VM nativa de conhecimento zero, baseada em WASM, com liquidação em 2–3 segundos. DuskEVM é compatível com Solidity; você consegue colocar Hardhat e MetaMask direto e fazer rodar. A privacidade é completada no nível de ZK pela Hedger. A ideia de design em duas trilhas realmente faz sentido: uma cuida dos contratos de privacidade e a outra cuida da compatibilidade, cada uma no seu papel.
Mas quanto mais eu avançava, mais parecia errado. A Piecrust desenvolveu sua própria VM. Em março deste ano, a auditoria AEGIS revelou 39 problemas, sendo 7 de severidade alta; dois bugs críticos ficaram presos na camada de sandbox. Mesmo nós honestos, executando o mesmo trecho de código, podem obter resultados diferentes. Contratos maliciosos podem empurrar o runtime para um estado em que a garantia de propriedade fica inválida. Se a sandbox for comprometida, todo o contrato confidencial acima vai à falência. Já a DuskEVM, por si só, só suporta transações públicas; toda a privacidade depende de módulos adicionais para “segurar a onda”. No fim, são duas VMs batendo uma na outra, e tanto o volume de código quanto a superfície de ataque praticamente dobram.
Agora, sobre a parceria. NPEX, Chainlink, Cordial, Quantoz, 21X — no site consta €300M+ em emissão confirmada, alcance de 50K+ investidores e 210M+ DUSK apostado. Os recursos realmente parecem mais sólidos do que projetos que só contam histórias de RWA. Mas o próprio time oficial também admite: tokenização reduz atrito, mas não dá para criar compradores, vendedores e profundidade de mercado. O Dusk Trade ainda está em Building/Waitlist, e tanto DuskEVM quanto Hedger ainda estão no Testnet. A lista de parcerias mostra que as partes topam colaborar; para valer mesmo, é preciso ver métricas duras como volume de ativos on-chain, número de traders e profundidade no secundário.
Por fim, a conexão entre compliance e privacidade. A Zedger, no momento da emissão, escreve na própria proposta a whitelist, identidade única por conta, e aprovação explícita do destinatário. A transferência é dividida em duas etapas; se houver timeout, ela é automaticamente cancelada. A Phoenix usa uma arquitetura UTXO: o dinheiro fica guardado em notas criptografadas; na execução, o ZK valida simultaneamente cinco coisas, e Pedersen Commitments esconde valores e endereços. O DuskDS confirma em três fases — quando o bloco é produzido, é definitivo. As regras definem o que pode ou não acontecer, a Phoenix controla quais partes não precisam ser públicas, e a DuskDS define qual estado conta. Esses três elos completam o mesmo ponto de ruptura: da emissão à liquidação, para que as operações não precisem voltar à camada off-chain e coordenar de novo.
A lista de parcerias já está bem “institucionalizada”. Na próxima fase, eu quero ver migração real e dados de成交 — não ficar sempre preso em PPT. #dusk $DUSK