Después de volver a ver Dusk, comencé a prestar atención a un tema que rara vez se discute: ¿dónde debería colocarse realmente el “poder de ejecución” en la cadena?
En mis investigaciones recientes sobre @Dusk , descubrí que en vez de obsesionarme con una sola función, empecé a observar cómo una cadena financiera pública distribuye la capacidad de ejecución.
Dusk no es, en esencia, quien intenta meter todo en un único entorno de ejecución. DuskEVM se encarga de Solidity, Vyper y de las herramientas del ecosistema EVM; DuskVM, en cambio, se ejecuta directamente sobre Dusk L1, orientado a contratos Rust/WASM, y puede acceder a activos a nivel de protocolo, al modelo nativo de transacciones, a capacidades de privacidad y a capacidades de ZK; mientras que DuskDS de la capa inferior se encarga del consenso, la liquidación y la disponibilidad de datos. La documentación oficial describe con claridad esta división de responsabilidades.
Creo que aquí hay una diferencia fácil de pasar por alto: la compatibilidad con EVM resuelve el problema de “cómo hacer que entren los desarrolladores”, mientras que el entorno de ejecución nativo resuelve “qué cosas deben estar estrechamente adheridas a la L1 para hacerlo bien”.
Para aplicaciones DeFi comunes, las herramientas de EVM son lo bastante convenientes; pero si la aplicación en sí involucra transacciones privadas, activos regulados o necesita llamar directamente a capacidades nativas de Dusk, tratar todo bajo los paradigmas tradicionales de EVM puede, en realidad, limitar el diseño del protocolo.
Esa también es una forma en que volví a entender Dusk: no se trata solo de “ser compatible con más”, sino de intentar asignar diferentes ubicaciones de ejecución para distintos tipos de aplicaciones, y aun así hacer que el resultado final vuelva a una misma capa de liquidación.
Luego, al mirar $DUSK , vemos que en sí mismo asume tanto el papel de Gas como el de staking, por lo que la ejecución de transacciones y la seguridad de la red comparten el mismo activo económico.
Por supuesto, si esta arquitectura realmente puede reflejar su valor depende de si los desarrolladores están dispuestos a abandonar la ruta puramente EVM para aprovechar capacidades nativas, y de qué enfoque de ejecución elegirá finalmente una aplicación financiera real.
Así que ahora, lo que más quiero observar no es si Dusk “tiene EVM”, sino si puede demostrar una idea: que, en escenarios financieros complejos, el entorno de ejecución en sí mismo también puede convertirse en una parte del diseño del protocolo. #dusk $DUSK @Dusk
En mis investigaciones recientes sobre @Dusk , descubrí que en vez de obsesionarme con una sola función, empecé a observar cómo una cadena financiera pública distribuye la capacidad de ejecución.
Dusk no es, en esencia, quien intenta meter todo en un único entorno de ejecución. DuskEVM se encarga de Solidity, Vyper y de las herramientas del ecosistema EVM; DuskVM, en cambio, se ejecuta directamente sobre Dusk L1, orientado a contratos Rust/WASM, y puede acceder a activos a nivel de protocolo, al modelo nativo de transacciones, a capacidades de privacidad y a capacidades de ZK; mientras que DuskDS de la capa inferior se encarga del consenso, la liquidación y la disponibilidad de datos. La documentación oficial describe con claridad esta división de responsabilidades.
Creo que aquí hay una diferencia fácil de pasar por alto: la compatibilidad con EVM resuelve el problema de “cómo hacer que entren los desarrolladores”, mientras que el entorno de ejecución nativo resuelve “qué cosas deben estar estrechamente adheridas a la L1 para hacerlo bien”.
Para aplicaciones DeFi comunes, las herramientas de EVM son lo bastante convenientes; pero si la aplicación en sí involucra transacciones privadas, activos regulados o necesita llamar directamente a capacidades nativas de Dusk, tratar todo bajo los paradigmas tradicionales de EVM puede, en realidad, limitar el diseño del protocolo.
Esa también es una forma en que volví a entender Dusk: no se trata solo de “ser compatible con más”, sino de intentar asignar diferentes ubicaciones de ejecución para distintos tipos de aplicaciones, y aun así hacer que el resultado final vuelva a una misma capa de liquidación.
Luego, al mirar $DUSK , vemos que en sí mismo asume tanto el papel de Gas como el de staking, por lo que la ejecución de transacciones y la seguridad de la red comparten el mismo activo económico.
Por supuesto, si esta arquitectura realmente puede reflejar su valor depende de si los desarrolladores están dispuestos a abandonar la ruta puramente EVM para aprovechar capacidades nativas, y de qué enfoque de ejecución elegirá finalmente una aplicación financiera real.
Así que ahora, lo que más quiero observar no es si Dusk “tiene EVM”, sino si puede demostrar una idea: que, en escenarios financieros complejos, el entorno de ejecución en sí mismo también puede convertirse en una parte del diseño del protocolo. #dusk $DUSK @Dusk