Antes pensaba que, si una blockchain pública ofrecía varios entornos de ejecución, lo máximo que hacía era darle a los desarrolladores más de una ruta. Pero después de descomponer la arquitectura de @Dusk , descubrí que la relación entre DuskVM y DuskEVM no es tan sencilla: más bien son dos puertas de entrada orientadas a necesidades distintas.$DUSK
DuskVM se ejecuta directamente sobre Dusk L1, usando Rust/WASM, y es adecuado para llamar a activos nativos, capacidades de privacidad y funciones ZK; DuskEVM, en cambio, es como un puente de migración, para que los desarrolladores de Solidity sigan usando carteras, frameworks y herramientas de prueba que ya conocen. Al final, los resultados de ambos lados se entregan a cargo de DuskDS para la liquidación.#dusk
Esto significa que el papel de DuskEVM no es solo reducir el umbral de migración. Por ejemplo, si una aplicación financiera típica quiere empezar conectándose a una cadena de herramientas EVM ya madura, puede comenzar con DuskEVM; pero si lo que se construye es una seguridad privada, transferencias de activos controlados o se necesita invocar capacidades nativas de confidencialidad de Dusk, entonces no se puede quedarse únicamente en la capa EVM: gran parte de la lógica todavía tiene que depender de DuskVM.
Y entonces surgen las preguntas. Supongamos que una aplicación quiere, a la vez, interactuar con contratos Solidity y gestionar activos nativos privados de Dusk: ¿dónde se almacena el estado principal? ¿Cómo se sincroniza entre ambos entornos? ¿Quién verifica las llamadas entre capas? Si algo falla, ¿el desarrollador debe depurar problemas del contrato, del entorno de ejecución o de la capa de liquidación?$BTC
Así que ahora veo que el enfoque de Dusk con múltiples entornos de ejecución no se puede entender solo como una ventaja de compatibilidad. Por un lado permite que entre más desarrolladores; por otro lado, le entrega al equipo de desarrollo los retos difíciles del diseño del sistema. Lo realmente importante para observar no es cuántas formas de ejecución ofrece Dusk, sino si entre estos entornos puede establecerse una frontera clara, para que los desarrolladores hagan menos renuncias innecesarias, en lugar de apilar cada vez más complejidad de arquitectura de la aplicación solo para poder invocar capacidades diferentes al mismo tiempo.$ETH
DuskVM se ejecuta directamente sobre Dusk L1, usando Rust/WASM, y es adecuado para llamar a activos nativos, capacidades de privacidad y funciones ZK; DuskEVM, en cambio, es como un puente de migración, para que los desarrolladores de Solidity sigan usando carteras, frameworks y herramientas de prueba que ya conocen. Al final, los resultados de ambos lados se entregan a cargo de DuskDS para la liquidación.#dusk
Esto significa que el papel de DuskEVM no es solo reducir el umbral de migración. Por ejemplo, si una aplicación financiera típica quiere empezar conectándose a una cadena de herramientas EVM ya madura, puede comenzar con DuskEVM; pero si lo que se construye es una seguridad privada, transferencias de activos controlados o se necesita invocar capacidades nativas de confidencialidad de Dusk, entonces no se puede quedarse únicamente en la capa EVM: gran parte de la lógica todavía tiene que depender de DuskVM.
Y entonces surgen las preguntas. Supongamos que una aplicación quiere, a la vez, interactuar con contratos Solidity y gestionar activos nativos privados de Dusk: ¿dónde se almacena el estado principal? ¿Cómo se sincroniza entre ambos entornos? ¿Quién verifica las llamadas entre capas? Si algo falla, ¿el desarrollador debe depurar problemas del contrato, del entorno de ejecución o de la capa de liquidación?$BTC
Así que ahora veo que el enfoque de Dusk con múltiples entornos de ejecución no se puede entender solo como una ventaja de compatibilidad. Por un lado permite que entre más desarrolladores; por otro lado, le entrega al equipo de desarrollo los retos difíciles del diseño del sistema. Lo realmente importante para observar no es cuántas formas de ejecución ofrece Dusk, sino si entre estos entornos puede establecerse una frontera clara, para que los desarrolladores hagan menos renuncias innecesarias, en lugar de apilar cada vez más complejidad de arquitectura de la aplicación solo para poder invocar capacidades diferentes al mismo tiempo.$ETH