Quando eu olhei para blockchains de privacidade antes, eu sempre pensei que as provas de conhecimento zero já seriam suficientes para atender a maior parte das necessidades criptográficas: basta colocar os parâmetros da transação na prova e deixar a execução a cargo da ZK Virtual Machine. Mas depois que eu pesquisei o modelo de transações do Phoenix, da Dusk, mudei essa visão. O verdadeiro desafio não é gerar uma transação anônima, mas sim manter continuamente, em ambientes complexos, regras de permissões de privacidade que estão sempre mudando.
Acho que o modelo de transações do Phoenix é mais parecido com um sistema de controle de acesso por níveis de um prédio comercial. Contratos de privacidade comuns são como uma chave fixa: enquanto você gerar uma prova válida, consegue destrancar. Já o sistema Phoenix é como um administrador dinâmico de permissões: ele não apenas verifica se você tem uma prova válida; também determina se o cenário da transação, as permissões de divulgação, as exigências de auditoria e o nível de conformidade atendem aos requisitos. Para aplicações de privacidade na camada de blockchain, essa avaliação dinâmica de permissões é ainda mais importante do que apenas gerar uma prova anônima.
A Dusk escolheu separar a camada de privacidade da camada transparente de EVM, essencialmente para resolver um problema de longo prazo. No passado, muitas chains de privacidade escreviam todas as regras de privacidade diretamente no contrato base; isso torna o custo de modificação alto e o risco de atualização também cresce. Conforme os cenários de aplicação ficam mais complexos e as necessidades de privacidade dos usuários ficam mais diversas, um único modo anônimo dificilmente consegue acompanhar demandas de negócios que mudam com frequência. Após a separação entre contas de dois modos, os desenvolvedores podem ajustar com mais flexibilidade o nível de privacidade, de modo que a privacidade da transação deixe de ser uma permissão permanente totalmente anônima.
Mas esse tipo de design também traz novos desafios de engenharia. Com o aumento do número de transações entre camadas, o custo de sincronização de estado sobe; a compatibilidade entre versões se torna mais complexa; e os desenvolvedores precisam investir mais tempo para entender a lógica de interação entre os dois modos. Além disso, a velocidade de geração das provas ZK, a experiência de integração com o SDK da Rusk e se usuários institucionais estarão dispostos a migrar também afetam o resultado real de implementação.
Na minha visão, o que a Dusk realmente precisa validar não é se a ideia de privacidade com ZK é conceitualmente correta, mas se esse sistema de privacidade em dois modos consegue ser usado por muitos desenvolvedores por um longo tempo. No futuro, vou continuar observando e testando os dados de transações entre camadas na testnet, a situação de integração dos desenvolvedores e a frequência com que as permissões de privacidade mudam em aplicações reais. Uma questão que vale refletir é: se no futuro houver cada vez mais cenários de privacidade na cadeia, precisamos de capacidades criptográficas mais fortes ou de um jeito melhor de gerenciar permissões de privacidade.
#dusk $DUSK @Dusk
Acho que o modelo de transações do Phoenix é mais parecido com um sistema de controle de acesso por níveis de um prédio comercial. Contratos de privacidade comuns são como uma chave fixa: enquanto você gerar uma prova válida, consegue destrancar. Já o sistema Phoenix é como um administrador dinâmico de permissões: ele não apenas verifica se você tem uma prova válida; também determina se o cenário da transação, as permissões de divulgação, as exigências de auditoria e o nível de conformidade atendem aos requisitos. Para aplicações de privacidade na camada de blockchain, essa avaliação dinâmica de permissões é ainda mais importante do que apenas gerar uma prova anônima.
A Dusk escolheu separar a camada de privacidade da camada transparente de EVM, essencialmente para resolver um problema de longo prazo. No passado, muitas chains de privacidade escreviam todas as regras de privacidade diretamente no contrato base; isso torna o custo de modificação alto e o risco de atualização também cresce. Conforme os cenários de aplicação ficam mais complexos e as necessidades de privacidade dos usuários ficam mais diversas, um único modo anônimo dificilmente consegue acompanhar demandas de negócios que mudam com frequência. Após a separação entre contas de dois modos, os desenvolvedores podem ajustar com mais flexibilidade o nível de privacidade, de modo que a privacidade da transação deixe de ser uma permissão permanente totalmente anônima.
Mas esse tipo de design também traz novos desafios de engenharia. Com o aumento do número de transações entre camadas, o custo de sincronização de estado sobe; a compatibilidade entre versões se torna mais complexa; e os desenvolvedores precisam investir mais tempo para entender a lógica de interação entre os dois modos. Além disso, a velocidade de geração das provas ZK, a experiência de integração com o SDK da Rusk e se usuários institucionais estarão dispostos a migrar também afetam o resultado real de implementação.
Na minha visão, o que a Dusk realmente precisa validar não é se a ideia de privacidade com ZK é conceitualmente correta, mas se esse sistema de privacidade em dois modos consegue ser usado por muitos desenvolvedores por um longo tempo. No futuro, vou continuar observando e testando os dados de transações entre camadas na testnet, a situação de integração dos desenvolvedores e a frequência com que as permissões de privacidade mudam em aplicações reais. Uma questão que vale refletir é: se no futuro houver cada vez mais cenários de privacidade na cadeia, precisamos de capacidades criptográficas mais fortes ou de um jeito melhor de gerenciar permissões de privacidade.
#dusk $DUSK @Dusk
