Contenido como este debe ser apreciado 👍
Publicación
precious Zarmalaa
·
--
$DUSK @Dusk #dusk
Antes asumía que "EVM-compatible" significaba que una cadena solo ejecuta EVM y ya está.
Dusk no lo hace.
Seguí el rastro de lo que realmente es DuskVM: basado en Wasmtime, ejecuta contratos Rust/WASM directamente en la L1 de Dusk, totalmente separado de DuskEVM. eso no es una capa de compatibilidad pegada a EVM: es un segundo entorno de ejecución independiente que está al lado.
Hmm.
Entonces, ¿por qué construir un VM separado en lugar de solo incluir soporte para EVM?
Seguí investigando. DuskVM existe específicamente para contratos que necesitan acceso directo a activos de la L1, modelos nativos de transacción de Dusk, privacidad o capacidades de cero conocimiento: cosas que el modelo de ejecución de EVM no estaba diseñado para exponer de forma nativa. Piecrust, el motor que está debajo, funciona aproximadamente diez veces más rápido que su predecesor, y se entrega con funciones host compatibles con ZK: PLONK, Groth16 y BLS; integradas directamente en el runtime.
Revisé qué cubre, en cambio, DuskEVM. Equivalencia total de EVM, herramientas estándar, y liquidación a través de DuskDS: la capa para desarrolladores que quieren flujos de trabajo familiares de Solidity sin necesidad de primitivas nativas de privacidad.
Así que "VM nativa en lugar de solo EVM" no es realmente un rechazo de EVM. es Dusk negándose a enrutar contratos nativos de privacidad y ZK a través de un modelo de ejecución que nunca se diseñó para manejarlos de manera eficiente.
¿Ejecutar dos entornos de ejecución separados hace a Dusk más capaz, o solo divide la atención de los desarrolladores entre dos sistemas que hacen trabajos superpuestos?
#dusk $DUSK
Antes asumía que "EVM-compatible" significaba que una cadena solo ejecuta EVM y ya está.
Dusk no lo hace.
Seguí el rastro de lo que realmente es DuskVM: basado en Wasmtime, ejecuta contratos Rust/WASM directamente en la L1 de Dusk, totalmente separado de DuskEVM. eso no es una capa de compatibilidad pegada a EVM: es un segundo entorno de ejecución independiente que está al lado.
Hmm.
Entonces, ¿por qué construir un VM separado en lugar de solo incluir soporte para EVM?
Seguí investigando. DuskVM existe específicamente para contratos que necesitan acceso directo a activos de la L1, modelos nativos de transacción de Dusk, privacidad o capacidades de cero conocimiento: cosas que el modelo de ejecución de EVM no estaba diseñado para exponer de forma nativa. Piecrust, el motor que está debajo, funciona aproximadamente diez veces más rápido que su predecesor, y se entrega con funciones host compatibles con ZK: PLONK, Groth16 y BLS; integradas directamente en el runtime.
Revisé qué cubre, en cambio, DuskEVM. Equivalencia total de EVM, herramientas estándar, y liquidación a través de DuskDS: la capa para desarrolladores que quieren flujos de trabajo familiares de Solidity sin necesidad de primitivas nativas de privacidad.
Así que "VM nativa en lugar de solo EVM" no es realmente un rechazo de EVM. es Dusk negándose a enrutar contratos nativos de privacidad y ZK a través de un modelo de ejecución que nunca se diseñó para manejarlos de manera eficiente.
¿Ejecutar dos entornos de ejecución separados hace a Dusk más capaz, o solo divide la atención de los desarrolladores entre dos sistemas que hacen trabajos superpuestos?
#dusk $DUSK
Aviso legal: Incluye opiniones de terceros. No es asesoramiento. Binance Ai puede utilizarse sin garantía. Consultar Términos y condiciones.