#dusk $DUSK
Antes de ver “EVM compatível”, eu basicamente não pensava muito a respeito.
Se dá para escrever em Solidity, se o Foundry roda, e se a carteira também consegue conectar — então não é só continuar usando o mesmo pacote do Ethereum?
Recentemente, ao ler a Reference do DuskEVM do @Dusk , percebi que, na prática, ao fazer o deploy de verdade, não dá para ser tão preguiçoso.
Um exemplo bem simples: hoje o DuskEVM tem o seu próprio sequencer.
Quando você obtém um receipt da transação, isso quer dizer que ela já foi empacotada.
Mas isso não é a mesma coisa que settlement depois.
E ainda tem o prevrandao.
No Ethereum, alguns desenvolvedores costumam usá-lo de forma conveniente para lógica relacionada a números aleatórios.
Mas a documentação oficial do Dusk faz questão de alertar: no DuskEVM, não trate isso como uma fonte de aleatoriedade segura e imparcial.
Coisas assim, se você não olhar a Reference no dia a dia, é muito fácil escrever direto no modo antigo, por hábito.
Então hoje eu entendo EVM compatibility de um jeito bem mais realista do que antes:
Ela pode economizar bastante custo de migração — isso está certo.
Mas “familiaridade com a interface” e “ambiente subjacente é igual” não são a mesma coisa.
Quando for realmente planejar colocar em produção, ainda precisa rever de novo coisas como sequencer, finality e estados entre camadas.
Eu, na verdade, gosto bastante de a documentação oficial já escrever essas limitações diretamente.
O que eu mais temo não são as diferenças.
É você achar que não existem diferenças.
Antes de ver “EVM compatível”, eu basicamente não pensava muito a respeito.
Se dá para escrever em Solidity, se o Foundry roda, e se a carteira também consegue conectar — então não é só continuar usando o mesmo pacote do Ethereum?
Recentemente, ao ler a Reference do DuskEVM do @Dusk , percebi que, na prática, ao fazer o deploy de verdade, não dá para ser tão preguiçoso.
Um exemplo bem simples: hoje o DuskEVM tem o seu próprio sequencer.
Quando você obtém um receipt da transação, isso quer dizer que ela já foi empacotada.
Mas isso não é a mesma coisa que settlement depois.
E ainda tem o prevrandao.
No Ethereum, alguns desenvolvedores costumam usá-lo de forma conveniente para lógica relacionada a números aleatórios.
Mas a documentação oficial do Dusk faz questão de alertar: no DuskEVM, não trate isso como uma fonte de aleatoriedade segura e imparcial.
Coisas assim, se você não olhar a Reference no dia a dia, é muito fácil escrever direto no modo antigo, por hábito.
Então hoje eu entendo EVM compatibility de um jeito bem mais realista do que antes:
Ela pode economizar bastante custo de migração — isso está certo.
Mas “familiaridade com a interface” e “ambiente subjacente é igual” não são a mesma coisa.
Quando for realmente planejar colocar em produção, ainda precisa rever de novo coisas como sequencer, finality e estados entre camadas.
Eu, na verdade, gosto bastante de a documentação oficial já escrever essas limitações diretamente.
O que eu mais temo não são as diferenças.
É você achar que não existem diferenças.