Anoche, mientras revisaba la documentación de Dusk, recién me di cuenta de que siempre había entendido “soportar EVM” de forma demasiado superficial. Dusk no mete todos los contratos en una sola máquina virtual: las aplicaciones que ya conocen Solidity y Foundry pueden usar DuskEVM, pagando el Gas con DUSK; los datos y los compromisos de estado por lotes se encargan a DuskDS para la liquidación. Si se necesitan capacidades nativas de privacidad y pruebas de conocimiento cero, o contratos con control de activos a nivel de protocolo, entonces se ejecutan directamente en DuskVM con Rust/WASM.
Lo entendí como dos mesas de operación abiertas por la misma entidad de transacciones. Una conserva los botones con los que ya estoy familiarizado, para migrar más rápido; la otra se acerca al “bóveda” a nivel subyacente, puede llamar reglas más nativas y, al final, ambas vuelven a la misma base de liquidación para confirmar el libro mayor. Esta decisión es más importante que las cuatro palabras “compatible con EVM”, porque separa la eficiencia de desarrollo de las capacidades nativas.
Pero contar con dos rutas también incrementa la complejidad del puente y la interacción entre capas, además de requerir una evaluación precisa del estado. La documentación oficial lo deja claro: el empaquetado rápido de DuskEVM no significa que ya se haya completado la liquidación en DuskDS. No voy a confiar solo en que la página muestre “éxito” como si eso confirmara la finalización real. Después debo comprobar si la experiencia entre capas es fluida, si las herramientas están maduras y si aumenta la cantidad de contratos reales. La arquitectura ofrece la elección; adoptar la opción es lo que da la respuesta.
@Dusk $DUSK #dusk
Lo entendí como dos mesas de operación abiertas por la misma entidad de transacciones. Una conserva los botones con los que ya estoy familiarizado, para migrar más rápido; la otra se acerca al “bóveda” a nivel subyacente, puede llamar reglas más nativas y, al final, ambas vuelven a la misma base de liquidación para confirmar el libro mayor. Esta decisión es más importante que las cuatro palabras “compatible con EVM”, porque separa la eficiencia de desarrollo de las capacidades nativas.
Pero contar con dos rutas también incrementa la complejidad del puente y la interacción entre capas, además de requerir una evaluación precisa del estado. La documentación oficial lo deja claro: el empaquetado rápido de DuskEVM no significa que ya se haya completado la liquidación en DuskDS. No voy a confiar solo en que la página muestre “éxito” como si eso confirmara la finalización real. Después debo comprobar si la experiencia entre capas es fluida, si las herramientas están maduras y si aumenta la cantidad de contratos reales. La arquitectura ofrece la elección; adoptar la opción es lo que da la respuesta.
@Dusk $DUSK #dusk