Conteúdo como este deve ser apreciado 👍
Publicar
precious Zarmalaa
·
--
$DUSK @Dusk #dusk
eu costumava achar que "compatível com EVM" significava apenas que uma cadeia executa a EVM e pronto.
A Dusk não faz isso.
eu rastreei o que o DuskVM realmente é: baseado no Wasmtime, executando contratos Rust/WASM diretamente na L1 da Dusk, totalmente separado do DuskEVM. isso não é uma camada de compatibilidade acoplada à EVM — é um segundo ambiente de execução independente, que fica ao lado.
Hmm.
então por que construir uma VM inteira separada em vez de apenas fornecer suporte a EVM?
continuei cavando. o DuskVM existe especificamente para contratos que precisam de acesso direto aos ativos da L1, aos modelos nativos de transação da Dusk, privacidade, ou recursos de zero-knowledge — coisas que o modelo de execução da EVM não foi projetado para expor de forma nativa. Piecrust, o motor por baixo, roda cerca de dez vezes mais rápido que seu antecessor, e vem com funções de host amigáveis a ZK — PLONK, Groth16 e BLS — embutidas diretamente no runtime.
eu verifiquei o que o DuskEVM cobre, por outro lado. equivalência completa à EVM, ferramentas padrão, liquidação através do DuskDS — a camada para desenvolvedores que querem fluxos de trabalho familiares do Solidity sem precisar de primitivas nativas de privacidade.
então "VM nativa em vez de apenas EVM" não é exatamente uma rejeição da EVM. é a Dusk se recusando a fazer contratos nativos de privacidade-e-ZK trafegarem por um modelo de execução que nunca foi construído para lidar com isso de forma eficiente.
executar dois ambientes de execução separados torna a Dusk mais capaz, ou apenas divide a atenção dos desenvolvedores entre dois sistemas que fazem trabalhos sobrepostos?
#dusk $DUSK
eu costumava achar que "compatível com EVM" significava apenas que uma cadeia executa a EVM e pronto.
A Dusk não faz isso.
eu rastreei o que o DuskVM realmente é: baseado no Wasmtime, executando contratos Rust/WASM diretamente na L1 da Dusk, totalmente separado do DuskEVM. isso não é uma camada de compatibilidade acoplada à EVM — é um segundo ambiente de execução independente, que fica ao lado.
Hmm.
então por que construir uma VM inteira separada em vez de apenas fornecer suporte a EVM?
continuei cavando. o DuskVM existe especificamente para contratos que precisam de acesso direto aos ativos da L1, aos modelos nativos de transação da Dusk, privacidade, ou recursos de zero-knowledge — coisas que o modelo de execução da EVM não foi projetado para expor de forma nativa. Piecrust, o motor por baixo, roda cerca de dez vezes mais rápido que seu antecessor, e vem com funções de host amigáveis a ZK — PLONK, Groth16 e BLS — embutidas diretamente no runtime.
eu verifiquei o que o DuskEVM cobre, por outro lado. equivalência completa à EVM, ferramentas padrão, liquidação através do DuskDS — a camada para desenvolvedores que querem fluxos de trabalho familiares do Solidity sem precisar de primitivas nativas de privacidade.
então "VM nativa em vez de apenas EVM" não é exatamente uma rejeição da EVM. é a Dusk se recusando a fazer contratos nativos de privacidade-e-ZK trafegarem por um modelo de execução que nunca foi construído para lidar com isso de forma eficiente.
executar dois ambientes de execução separados torna a Dusk mais capaz, ou apenas divide a atenção dos desenvolvedores entre dois sistemas que fazem trabalhos sobrepostos?
#dusk $DUSK
Aviso legal: inclui opiniões de terceiros. Não constitui aconselhamento. A Binance AI pode ser utilizada sem garantia. Consulta os Termos e Condições.