Anoche, al revisar la documentación de Dusk, recién me di cuenta de que siempre había entendido “soportar EVM” de una manera demasiado simplista. Dusk no mete todos los contratos en una sola máquina virtual: las aplicaciones que ya conocen Solidity y Foundry pueden usar DuskEVM, pagar el Gas con @Dusk DUSK, y luego encargar los datos por lotes y las confirmaciones de estado a DuskDS para que realice la liquidación; si se trata de contratos con privacidad nativa y capacidades de conocimiento cero, o de contratos con control de activos a nivel de protocolo, entonces se ejecutan directamente en DuskVM con Rust/WASM.
Yo lo interpreté como dos mesas de operación de una misma institución de transacciones. Una conserva los botones familiares y permite una migración más rápida; la otra se acerca al cofre subyacente, puede invocar reglas más nativas y, al final, todo vuelve a la misma base de liquidación para confirmar el libro contable. 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 el doble camino también incrementa la complejidad de puentes e interacciones entre capas, además de exigir una evaluación precisa del estado. La documentación oficial lo indica con claridad: el empaquetado rápido de DuskEVM no equivale a que ya se haya completado la liquidación en DuskDS. No me quedaré solo con que la página muestre “éxito” como si eso significara que ya quedó finalizado. Más adelante, hay que ver si la experiencia entre capas es fluida, si las herramientas maduran y si el volumen real de contratos crece. La arquitectura ofrece opciones; adoptar una es lo que da la respuesta.
#dusk $DUSK
Yo lo interpreté como dos mesas de operación de una misma institución de transacciones. Una conserva los botones familiares y permite una migración más rápida; la otra se acerca al cofre subyacente, puede invocar reglas más nativas y, al final, todo vuelve a la misma base de liquidación para confirmar el libro contable. 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 el doble camino también incrementa la complejidad de puentes e interacciones entre capas, además de exigir una evaluación precisa del estado. La documentación oficial lo indica con claridad: el empaquetado rápido de DuskEVM no equivale a que ya se haya completado la liquidación en DuskDS. No me quedaré solo con que la página muestre “éxito” como si eso significara que ya quedó finalizado. Más adelante, hay que ver si la experiencia entre capas es fluida, si las herramientas maduran y si el volumen real de contratos crece. La arquitectura ofrece opciones; adoptar una es lo que da la respuesta.
#dusk $DUSK