#dusk $DUSK @Dusk No começo, eu tratei a compatibilidade com EVM como se fosse apenas uma caixinha.
Se uma cadeia suporta Solidity, os desenvolvedores podem migrar. Simples, certo?
Então eu olhei com mais atenção para o DuskEVM, e essa suposição começou a parecer um pouco rasa demais.
O que realmente importa é o que os desenvolvedores conseguem manter quando se mudam.
Com o DuskEVM, os desenvolvedores podem trabalhar em um ambiente equivalente a EVM usando Solidity e as ferramentas de EVM com as quais já estão familiarizados. Isso significa que a conversa não é simplesmente sobre adicionar mais um ambiente de execução. É sobre reduzir a distância entre o que os desenvolvedores já conhecem e o que o Dusk está construindo.
Essa parte me chamou atenção.
Porque pedir a um desenvolvedor para aprender uma pilha totalmente nova é uma coisa. Permitir que ele leve fluxos de trabalho conhecidos de smart contracts para uma arquitetura de blockchain diferente é outra.
E então existe o DuskDS.
O DuskEVM cuida da execução, enquanto o DuskDS fornece a base de liquidação e de disponibilidade de dados por baixo. O DuskVM é outro caminho de execução, executando contratos Rust/WASM diretamente no Dusk L1.
Então comecei a me perguntar:
Se diferentes ambientes de execução podem se apoiar na mesma base de liquidação, isso torna a arquitetura geral mais flexível?
Talvez.
Mas eu não acho que a compatibilidade com EVM, sozinha, prove qualquer coisa.
O teste real é o que acontece depois que os desenvolvedores chegam. Eles realmente constroem? As ferramentas são confortáveis o bastante? As aplicações se beneficiam da separação entre execução e liquidação?
É isso que estou mais interessado em acompanhar agora.
Para uma Layer 1 emergente, suportar Solidity é suficiente para atrair desenvolvedores, ou o teste real começa quando as pessoas de fato começam a construir?
@Dusk $DUSK
#Dusk #DuskEVM
Se uma cadeia suporta Solidity, os desenvolvedores podem migrar. Simples, certo?
Então eu olhei com mais atenção para o DuskEVM, e essa suposição começou a parecer um pouco rasa demais.
O que realmente importa é o que os desenvolvedores conseguem manter quando se mudam.
Com o DuskEVM, os desenvolvedores podem trabalhar em um ambiente equivalente a EVM usando Solidity e as ferramentas de EVM com as quais já estão familiarizados. Isso significa que a conversa não é simplesmente sobre adicionar mais um ambiente de execução. É sobre reduzir a distância entre o que os desenvolvedores já conhecem e o que o Dusk está construindo.
Essa parte me chamou atenção.
Porque pedir a um desenvolvedor para aprender uma pilha totalmente nova é uma coisa. Permitir que ele leve fluxos de trabalho conhecidos de smart contracts para uma arquitetura de blockchain diferente é outra.
E então existe o DuskDS.
O DuskEVM cuida da execução, enquanto o DuskDS fornece a base de liquidação e de disponibilidade de dados por baixo. O DuskVM é outro caminho de execução, executando contratos Rust/WASM diretamente no Dusk L1.
Então comecei a me perguntar:
Se diferentes ambientes de execução podem se apoiar na mesma base de liquidação, isso torna a arquitetura geral mais flexível?
Talvez.
Mas eu não acho que a compatibilidade com EVM, sozinha, prove qualquer coisa.
O teste real é o que acontece depois que os desenvolvedores chegam. Eles realmente constroem? As ferramentas são confortáveis o bastante? As aplicações se beneficiam da separação entre execução e liquidação?
É isso que estou mais interessado em acompanhar agora.
Para uma Layer 1 emergente, suportar Solidity é suficiente para atrair desenvolvedores, ou o teste real começa quando as pessoas de fato começam a construir?
@Dusk $DUSK
#Dusk #DuskEVM
