Quanto mais olho para o DuskEVM, mais acho que a parte interessante não é apenas o fato de o Dusk agora suportar EVM.
É que os desenvolvedores não precisam abandonar o fluxo de trabalho que já conhecem.
Se você está construindo com Solidity, Foundry, Hardhat, viem, ethers ou carteiras EVM familiares, o DuskEVM foi projetado para trazer essa experiência para o ecossistema do Dusk.
Mas foi a arquitetura por baixo que chamou minha atenção.
O DuskEVM gerencia a execução compatível com Ethereum, enquanto o DuskDS fornece a camada subjacente de consenso, liquidação e disponibilidade de dados.
O DUSK é usado para execução e ele pode se mover entre o Dusk L1 e o DuskEVM via a ponte.
O caminho da transação também vale a pena entender.
Uma transação chega ao sequenciador do DuskEVM, é incluída em um bloco de L2 e o empacotador publica os dados da transação no DuskDS. Depois, compromissos de estado e provas de falha conectam o estado resultante de volta ao DuskDS para a liquidação.
Essa distinção importa.
Incluir uma transação não é automaticamente a mesma coisa que liquidação final.
Também gosto de ver que o Dusk não está forçando todos os desenvolvedores a trabalharem em um único ambiente.
Desenvolvedores de EVM podem usar o DuskEVM e suas ferramentas existentes, enquanto desenvolvedores que constroem contratos em Rust/WASM diretamente para o Dusk L1 podem continuar usando o DuskVM.
Então meu entendimento é bem simples:
O DuskEVM não é interessante apenas porque traz compatibilidade com EVM para o Dusk.
Ele é interessante porque oferece aos desenvolvedores um ambiente de execução familiar, conectando esse ambiente à própria arquitetura de liquidação e disponibilidade de dados do Dusk.
Isso parece uma história muito maior do que simplesmente dizer: “O Dusk já tem um EVM”.
@Dusk_Foundation
#dusk $DUSK
$EDEN $AKE
É que os desenvolvedores não precisam abandonar o fluxo de trabalho que já conhecem.
Se você está construindo com Solidity, Foundry, Hardhat, viem, ethers ou carteiras EVM familiares, o DuskEVM foi projetado para trazer essa experiência para o ecossistema do Dusk.
Mas foi a arquitetura por baixo que chamou minha atenção.
O DuskEVM gerencia a execução compatível com Ethereum, enquanto o DuskDS fornece a camada subjacente de consenso, liquidação e disponibilidade de dados.
O DUSK é usado para execução e ele pode se mover entre o Dusk L1 e o DuskEVM via a ponte.
O caminho da transação também vale a pena entender.
Uma transação chega ao sequenciador do DuskEVM, é incluída em um bloco de L2 e o empacotador publica os dados da transação no DuskDS. Depois, compromissos de estado e provas de falha conectam o estado resultante de volta ao DuskDS para a liquidação.
Essa distinção importa.
Incluir uma transação não é automaticamente a mesma coisa que liquidação final.
Também gosto de ver que o Dusk não está forçando todos os desenvolvedores a trabalharem em um único ambiente.
Desenvolvedores de EVM podem usar o DuskEVM e suas ferramentas existentes, enquanto desenvolvedores que constroem contratos em Rust/WASM diretamente para o Dusk L1 podem continuar usando o DuskVM.
Então meu entendimento é bem simples:
O DuskEVM não é interessante apenas porque traz compatibilidade com EVM para o Dusk.
Ele é interessante porque oferece aos desenvolvedores um ambiente de execução familiar, conectando esse ambiente à própria arquitetura de liquidação e disponibilidade de dados do Dusk.
Isso parece uma história muito maior do que simplesmente dizer: “O Dusk já tem um EVM”.
@Dusk_Foundation
#dusk $DUSK
$EDEN $AKE