A cadeia de conformidade com privacidade correu por três semanas, e a Dusk ficou travada na toolchain, não no consenso
Ao fazer deploy numa testnet de um contrato com saldo confidencial, o tempo de compilação do circuito PlonK de @Dusk levou quase o dobro do esperado. Não é exatamente fatal, mas a sensação de “fragmentação” da toolchain é bem clara: do nó local até a assinatura do lado do navegador, muitas vezes é preciso alternar manualmente o RPC, e os exemplos da documentação não batem com as versões mais recentes. A experiência de desenvolvimento na Secret Network tende a ser mais suave, mas eu nunca aceitei muito bem o conjunto de pressupostos de confiança do TEE.
A Dusk quer seguir o caminho das finanças reguladas: amarrar transações de privacidade e validação de identidade na mesma camada. A direção faz sentido. Na prática, porém, a geração de provas de conhecimento zero ainda é mais pesada do que o que eu esperava para hardware comum, e o consumo de memória dos nós de validação também não é baixo. A Oasis faz modularização na camada de privacidade: o desenvolvimento fica mais flexível, mas a identidade on-chain e os componentes de conformidade não ficam tão acoplados à Dusk. No meu fluxo de emissão de ativos testado, o desenho de permissões da Dusk é mais detalhado: consegue diferenciar emissores, nós de auditoria e detentores comuns. Isso é mais útil na prática do que simplesmente ter uma chain voltada a transferências anônimas.
O problema também está aqui. A barreira para desenvolvedores na Dusk foi elevada pelos parâmetros de conformidade: muitas configurações exigem entender a terminologia regulatória para colocar a mão. O cold start do ecossistema pode ser mais lento do que o esperado. $DUSK tem uma lógica clara para taxa e token de governança, mas os tipos de aplicações atualmente deployáveis on-chain ainda são relativamente limitados. Os contratos de privacidade da Aleph Zero são mais genéricos e o Gas é mais estável; porém, em cenários de ativos regulados, faltam a ela um framework nativo de conformidade.
Se a Dusk conseguisse deixar o SDK um pouco mais “fino”, e transformar os parâmetros de conformidade em modelos predefinidos, a experiência de desenvolvimento ficaria muito melhor. Do contrário, parece mais uma chain sob medida para instituições do que um lugar onde desenvolvedores comuns consigam testar e errar rapidamente. Pelo menos até agora, o consenso dá conta; o gargalo está nas ferramentas e na documentação.
#dusk
Ao fazer deploy numa testnet de um contrato com saldo confidencial, o tempo de compilação do circuito PlonK de @Dusk levou quase o dobro do esperado. Não é exatamente fatal, mas a sensação de “fragmentação” da toolchain é bem clara: do nó local até a assinatura do lado do navegador, muitas vezes é preciso alternar manualmente o RPC, e os exemplos da documentação não batem com as versões mais recentes. A experiência de desenvolvimento na Secret Network tende a ser mais suave, mas eu nunca aceitei muito bem o conjunto de pressupostos de confiança do TEE.
A Dusk quer seguir o caminho das finanças reguladas: amarrar transações de privacidade e validação de identidade na mesma camada. A direção faz sentido. Na prática, porém, a geração de provas de conhecimento zero ainda é mais pesada do que o que eu esperava para hardware comum, e o consumo de memória dos nós de validação também não é baixo. A Oasis faz modularização na camada de privacidade: o desenvolvimento fica mais flexível, mas a identidade on-chain e os componentes de conformidade não ficam tão acoplados à Dusk. No meu fluxo de emissão de ativos testado, o desenho de permissões da Dusk é mais detalhado: consegue diferenciar emissores, nós de auditoria e detentores comuns. Isso é mais útil na prática do que simplesmente ter uma chain voltada a transferências anônimas.
O problema também está aqui. A barreira para desenvolvedores na Dusk foi elevada pelos parâmetros de conformidade: muitas configurações exigem entender a terminologia regulatória para colocar a mão. O cold start do ecossistema pode ser mais lento do que o esperado. $DUSK tem uma lógica clara para taxa e token de governança, mas os tipos de aplicações atualmente deployáveis on-chain ainda são relativamente limitados. Os contratos de privacidade da Aleph Zero são mais genéricos e o Gas é mais estável; porém, em cenários de ativos regulados, faltam a ela um framework nativo de conformidade.
Se a Dusk conseguisse deixar o SDK um pouco mais “fino”, e transformar os parâmetros de conformidade em modelos predefinidos, a experiência de desenvolvimento ficaria muito melhor. Do contrário, parece mais uma chain sob medida para instituições do que um lugar onde desenvolvedores comuns consigam testar e errar rapidamente. Pelo menos até agora, o consenso dá conta; o gargalo está nas ferramentas e na documentação.
#dusk