DuskEVM: Aquilo que me fez mudar a forma de ver “EVM compatível”
Antes, sempre que via uma chain dizer “nós temos EVM”, eu pensava: mais um fork de EVM, mais uma coisa para aprender, mais um monte de detalhes.
Mas quando coloquei o DuskEVM ao lado do workflow do OP Stack que eu já estava acostumado a usar, percebi que a história era completamente diferente.
Hardhat continua sendo.
Foundry continua sendo.
JSON-RPC continua sendo.
Blockscout continua sendo.
E, além disso, como o DuskEVM usa o OP Stack / op-geth, a sensação é de que a implementação quase não tem “curva de aprendizado” relevante.
Mas o ponto que realmente me chamou atenção está abaixo da camada do EVM.
O DuskEVM não é simplesmente colocar um ambiente EVM em outra chain. Os dados de transação são enviados para o DuskDS, a camada de settlement & data availability da Dusk, em vez de depender do Ethereum L1, como nos modelos do OP Mainnet/Base.
E a partir daqui, o que muda não é Solidity nem as ferramentas de developer.
O que muda é onde a aplicação é liquidada (settled).
@Dusk m leva para o sistema as coisas que eles construíram ao longo de muitos anos: settlement determinístico, Zedger e os componentes relacionados a compliance/infraestrutura institucional.
É por isso que comecei a enxergar o DuskEVM não como “mais uma chain EVM”, mas como uma forma de levar aplicações EVM já existentes para uma infraestrutura desenhada para finanças reguladas.
A questão mais interessante agora não é mais:
“O developer precisa aprender uma nova stack?”
Mas sim:
Com o atrito técnico praticamente zero, o que fará o developer escolher o DuskEVM em vez de Base ou OP Mainnet?
Ecossistema?
Adoção institucional?
Compliance?
Ou a economia do gas e do settlement?
Esta é a parte que eu acho que vale acompanhar na história #dusk . $DUSK
Antes, sempre que via uma chain dizer “nós temos EVM”, eu pensava: mais um fork de EVM, mais uma coisa para aprender, mais um monte de detalhes.
Mas quando coloquei o DuskEVM ao lado do workflow do OP Stack que eu já estava acostumado a usar, percebi que a história era completamente diferente.
Hardhat continua sendo.
Foundry continua sendo.
JSON-RPC continua sendo.
Blockscout continua sendo.
E, além disso, como o DuskEVM usa o OP Stack / op-geth, a sensação é de que a implementação quase não tem “curva de aprendizado” relevante.
Mas o ponto que realmente me chamou atenção está abaixo da camada do EVM.
O DuskEVM não é simplesmente colocar um ambiente EVM em outra chain. Os dados de transação são enviados para o DuskDS, a camada de settlement & data availability da Dusk, em vez de depender do Ethereum L1, como nos modelos do OP Mainnet/Base.
E a partir daqui, o que muda não é Solidity nem as ferramentas de developer.
O que muda é onde a aplicação é liquidada (settled).
@Dusk m leva para o sistema as coisas que eles construíram ao longo de muitos anos: settlement determinístico, Zedger e os componentes relacionados a compliance/infraestrutura institucional.
É por isso que comecei a enxergar o DuskEVM não como “mais uma chain EVM”, mas como uma forma de levar aplicações EVM já existentes para uma infraestrutura desenhada para finanças reguladas.
A questão mais interessante agora não é mais:
“O developer precisa aprender uma nova stack?”
Mas sim:
Com o atrito técnico praticamente zero, o que fará o developer escolher o DuskEVM em vez de Base ou OP Mainnet?
Ecossistema?
Adoção institucional?
Compliance?
Ou a economia do gas e do settlement?
Esta é a parte que eu acho que vale acompanhar na história #dusk . $DUSK
