La parte que no esperaba en DuskEVM no es el soporte de Solidity: es lo que sucede cuando DUSK vuelve a la capa nativa.
La guía oficial de la red de pruebas de Dusk dice que un retiro desde DuskEVM requiere tres acciones on-chain separadas: iniciar en DuskEVM, probar en Dusk L1 y, luego, finalizar en Dusk L1. El usuario también necesita suficiente DUSK sin protección en L1 para pagar tanto las transacciones de prueba como de finalización. La preparación para el retiro depende del estado de red publicado, la madurez de la prueba y las verificaciones del juego de disputas, en lugar de depender de un temporizador simple.
Eso me hizo mirar dos veces, porque “compatibilidad EVM” puede sonar como si toda la experiencia se volviera familiar por defecto. En la práctica, el puente revela la arquitectura más profunda: DuskEVM es un entorno de ejecución EVM que asienta y publica datos a través de DuskDS, no es la misma capa de ejecución que los contratos nativos de Rust/WASM de Dusk.
No interpreto los pasos adicionales como algo automáticamente malo. La documentación vincula la preparación con la madurez de la prueba y las verificaciones del juego de disputas, así que la fricción al menos está conectada con el modelo de seguridad. Pero plantea una pregunta real de producto para $DUSK : ¿pueden las aplicaciones en producción abstraer este flujo de prueba/finalización lo suficientemente bien como para que los usuarios obtengan los beneficios de seguridad sin sentir la complejidad entre capas?
Parece más importante vigilar eso que otra demostración de despliegue.
@Dusk_Foundation $DUSK #dusk
La guía oficial de la red de pruebas de Dusk dice que un retiro desde DuskEVM requiere tres acciones on-chain separadas: iniciar en DuskEVM, probar en Dusk L1 y, luego, finalizar en Dusk L1. El usuario también necesita suficiente DUSK sin protección en L1 para pagar tanto las transacciones de prueba como de finalización. La preparación para el retiro depende del estado de red publicado, la madurez de la prueba y las verificaciones del juego de disputas, en lugar de depender de un temporizador simple.
Eso me hizo mirar dos veces, porque “compatibilidad EVM” puede sonar como si toda la experiencia se volviera familiar por defecto. En la práctica, el puente revela la arquitectura más profunda: DuskEVM es un entorno de ejecución EVM que asienta y publica datos a través de DuskDS, no es la misma capa de ejecución que los contratos nativos de Rust/WASM de Dusk.
No interpreto los pasos adicionales como algo automáticamente malo. La documentación vincula la preparación con la madurez de la prueba y las verificaciones del juego de disputas, así que la fricción al menos está conectada con el modelo de seguridad. Pero plantea una pregunta real de producto para $DUSK : ¿pueden las aplicaciones en producción abstraer este flujo de prueba/finalización lo suficientemente bien como para que los usuarios obtengan los beneficios de seguridad sin sentir la complejidad entre capas?
Parece más importante vigilar eso que otra demostración de despliegue.
@Dusk_Foundation $DUSK #dusk