Ao ler a documentação de desenvolvimento do @Dusk , vi uma mudança de perspectiva: o que o Dusk realmente quer resolver não é “se devemos ou não ser compatíveis com a EVM”, mas sim qual lógica deve permanecer na camada nativa e qual lógica é mais adequada para ser entregue à EVM. Entradas duplas parecem capturar tanto desenvolvedores Rust quanto Solidity; porém, quanto mais pontos de entrada existem, mais precisa ficar claramente explicado como ficam os limites de estado, de ativos e de segurança.
O DuskVM permite que contratos Rust/WASM usem diretamente o modelo de transações nativo, capacidades de privacidade e ativos em nível de protocolo; o DuskEVM, por sua vez, oferece para Solidity, Vyper, carteiras comuns e ferramentas prontas um caminho familiar, além de delegar o processamento de liquidação e a disponibilidade de dados ao DuskDS. Essa divisão é bem pragmática: não é necessário forçar todos os times a reaprender uma pilha inteira de tecnologia, nem empurrar negócios que exigem privacidade nativa para dentro da lógica pública da EVM.
Mas a pressão de engenharia pode acabar sendo distribuída entre essas duas camadas. Um aplicativo executado no DuskEVM, com os ativos finalmente liquidados no DuskDS, pode ainda chamar um Hedger no meio para tratar fluxos de privacidade. Em ambientes estáveis, os desenvolvedores só perceberão a compatibilidade; porém, quando houver congestionamento de RPC, atrasos em mensagens entre camadas, ou falha na sincronização do estado de privacidade, a questão que realmente define a qualidade do sistema é se o saldo que o usuário vê, o resultado da execução do contrato e o estado final na camada subjacente conseguem permanecer consistentes.
Por isso eu não vou olhar apenas quantos contratos foram adicionados no #dusk . O que vale mais a pena observar depois é: o volume real de deploy do DuskEVM, a taxa de falhas entre camadas, o tempo de confirmação, a taxa de erros das ferramentas de desenvolvimento e se há uma descrição clara de estado do mesmo ativo tanto no caminho público quanto no caminho de privacidade. Como $DUSK é tanto para gas quanto para ativo de staking, o crescimento da demanda precisa ser fundamentado no pressuposto de que a aplicação realmente está rodando.
O valor do ambiente de execução dupla não é determinado pela quantidade de funcionalidades, e sim por quão bem as responsabilidades conseguem ser separadas. A EVM deve reduzir o custo de migração, enquanto a camada nativa fornece capacidades diferenciadas; se cada lado apenas contar sua própria história, a compatibilidade corre o risco de virar mais uma fragmentação.
$SNXXB $AKE
O DuskVM permite que contratos Rust/WASM usem diretamente o modelo de transações nativo, capacidades de privacidade e ativos em nível de protocolo; o DuskEVM, por sua vez, oferece para Solidity, Vyper, carteiras comuns e ferramentas prontas um caminho familiar, além de delegar o processamento de liquidação e a disponibilidade de dados ao DuskDS. Essa divisão é bem pragmática: não é necessário forçar todos os times a reaprender uma pilha inteira de tecnologia, nem empurrar negócios que exigem privacidade nativa para dentro da lógica pública da EVM.
Mas a pressão de engenharia pode acabar sendo distribuída entre essas duas camadas. Um aplicativo executado no DuskEVM, com os ativos finalmente liquidados no DuskDS, pode ainda chamar um Hedger no meio para tratar fluxos de privacidade. Em ambientes estáveis, os desenvolvedores só perceberão a compatibilidade; porém, quando houver congestionamento de RPC, atrasos em mensagens entre camadas, ou falha na sincronização do estado de privacidade, a questão que realmente define a qualidade do sistema é se o saldo que o usuário vê, o resultado da execução do contrato e o estado final na camada subjacente conseguem permanecer consistentes.
Por isso eu não vou olhar apenas quantos contratos foram adicionados no #dusk . O que vale mais a pena observar depois é: o volume real de deploy do DuskEVM, a taxa de falhas entre camadas, o tempo de confirmação, a taxa de erros das ferramentas de desenvolvimento e se há uma descrição clara de estado do mesmo ativo tanto no caminho público quanto no caminho de privacidade. Como $DUSK é tanto para gas quanto para ativo de staking, o crescimento da demanda precisa ser fundamentado no pressuposto de que a aplicação realmente está rodando.
O valor do ambiente de execução dupla não é determinado pela quantidade de funcionalidades, e sim por quão bem as responsabilidades conseguem ser separadas. A EVM deve reduzir o custo de migração, enquanto a camada nativa fornece capacidades diferenciadas; se cada lado apenas contar sua própria história, a compatibilidade corre o risco de virar mais uma fragmentação.
$SNXXB $AKE
