E se tornar a infraestrutura de blockchain mais fácil de usar às vezes significar dar aos desenvolvedores mais de uma forma de construir sobre ela?
Percebi isso ao explorar o DUSK, e a divisão entre DuskVM e DuskEVM me fez pausar. Em geral, penso que uma blockchain tem um ambiente principal de execução, e tudo o que vem depois é tratado como uma ferramenta ao redor dele.
O DUSK segue um caminho diferente. O DuskEVM oferece execução em Solidity e Vyper com ferramentas familiares do ecossistema Ethereum, enquanto o DuskVM executa contratos em Rust/WASM diretamente na Dusk L1. As duas rotas se assentam na mesma rede subjacente, mas atendem a necessidades diferentes de desenvolvimento.
No começo, isso pareceu apenas uma comodidade técnica. Então comecei a pensar no problema por baixo disso.
Os desenvolvedores já têm hábitos, bibliotecas, carteiras e bases de código que entendem. Pedir que toda aplicação financeira abandone essas ferramentas apenas para acessar um ambiente de liquidação diferente cria atrito desnecessário. Ao mesmo tempo, algumas aplicações podem precisar de acesso direto a ativos nativos, recursos de privacidade ou capacidades mais próximas do protocolo que um ambiente EVM não fornece naturalmente.
Essa troca parece surpreendentemente relevante para o design de infraestrutura.
Ao pesquisar o DUSK, me peguei pensando se a interoperabilidade às vezes é discutida de forma estreita demais. Talvez compatibilidade não seja apenas sobre conectar cadeias diferentes; ela também pode significar permitir que diferentes modelos de desenvolvimento coexistam sem forçar cada aplicação a seguir um único caminho técnico.
A pergunta interessante para mim é onde a abstração deve terminar. Pouca abstração cria atrito, enquanto muita abstração pode esconder capacidades de que os desenvolvedores eventualmente precisam.
O DUSK faz com que essa fronteira valha a pena ser examinada pela perspectiva de quem constrói, e não apenas pela perspectiva do mercado.
#dusk $DUSK @Dusk
Percebi isso ao explorar o DUSK, e a divisão entre DuskVM e DuskEVM me fez pausar. Em geral, penso que uma blockchain tem um ambiente principal de execução, e tudo o que vem depois é tratado como uma ferramenta ao redor dele.
O DUSK segue um caminho diferente. O DuskEVM oferece execução em Solidity e Vyper com ferramentas familiares do ecossistema Ethereum, enquanto o DuskVM executa contratos em Rust/WASM diretamente na Dusk L1. As duas rotas se assentam na mesma rede subjacente, mas atendem a necessidades diferentes de desenvolvimento.
No começo, isso pareceu apenas uma comodidade técnica. Então comecei a pensar no problema por baixo disso.
Os desenvolvedores já têm hábitos, bibliotecas, carteiras e bases de código que entendem. Pedir que toda aplicação financeira abandone essas ferramentas apenas para acessar um ambiente de liquidação diferente cria atrito desnecessário. Ao mesmo tempo, algumas aplicações podem precisar de acesso direto a ativos nativos, recursos de privacidade ou capacidades mais próximas do protocolo que um ambiente EVM não fornece naturalmente.
Essa troca parece surpreendentemente relevante para o design de infraestrutura.
Ao pesquisar o DUSK, me peguei pensando se a interoperabilidade às vezes é discutida de forma estreita demais. Talvez compatibilidade não seja apenas sobre conectar cadeias diferentes; ela também pode significar permitir que diferentes modelos de desenvolvimento coexistam sem forçar cada aplicação a seguir um único caminho técnico.
A pergunta interessante para mim é onde a abstração deve terminar. Pouca abstração cria atrito, enquanto muita abstração pode esconder capacidades de que os desenvolvedores eventualmente precisam.
O DUSK faz com que essa fronteira valha a pena ser examinada pela perspectiva de quem constrói, e não apenas pela perspectiva do mercado.
#dusk $DUSK @Dusk
