Algo en la documentación me interrumpió hoy mientras me desplazaba.
Dusk Network, $DUSK , #dusk , @Dusk — el ángulo de compatibilidad con EVM es cómo la mayoría de la gente encuentra este proyecto. Pasa tus contratos de Solidity, usa herramientas conocidas, carteras EVM existentes. El repositorio duskevm-genesis en GitHub se actualizó por última vez el 8 de agosto, mostrando trabajo activo de configuración de rollup. Así que la maquinaria está en marcha. Pero lo más profundo que no pude dejar de notar estaba, en realidad, dentro de la propia documentación de la arquitectura, escondido bajo una sola línea: "La inclusión de transacciones es rápida, pero la inclusión y el asentamiento son etapas diferentes."
Ahí está la pista. DuskEVM se ejecuta sobre OP Stack — esencialmente op-geth como secuenciador, agrupando los datos de las transacciones y devolviéndolos a DuskDS como blobs. Comportamiento estándar de rollup. Pero DuskDS, el propósito real por debajo — asentamiento determinista, contratos inteligentes ZK, privacidad nativa — es un entorno de ejecución completamente distinto. Los documentos lo dicen sin rodeos: construye sobre DuskEVM para Solidity y herramientas familiares, o construye nativamente sobre DuskDS con Rust y WASM para una privacidad real a nivel de protocolo y lógica de mercado personalizada. Dos caminos. No una sola cosa unificada.
hmm… Me tomó demasiado tiempo asumir que aquí la compatibilidad con EVM significaba que el código en Solidity heredaría automáticamente la infraestructura financiera de Dusk. No lo hace. El puente entre esas dos capas es deliberado y opcional, no automático.
Lo cual me lleva a preguntarme — ¿cuántos desarrolladores que portan a DuskEVM realmente volverán a re-arquitecturar para DuskDS cuando se den cuenta de lo que dejaron sobre la mesa?
Dusk Network, $DUSK , #dusk , @Dusk — el ángulo de compatibilidad con EVM es cómo la mayoría de la gente encuentra este proyecto. Pasa tus contratos de Solidity, usa herramientas conocidas, carteras EVM existentes. El repositorio duskevm-genesis en GitHub se actualizó por última vez el 8 de agosto, mostrando trabajo activo de configuración de rollup. Así que la maquinaria está en marcha. Pero lo más profundo que no pude dejar de notar estaba, en realidad, dentro de la propia documentación de la arquitectura, escondido bajo una sola línea: "La inclusión de transacciones es rápida, pero la inclusión y el asentamiento son etapas diferentes."
Ahí está la pista. DuskEVM se ejecuta sobre OP Stack — esencialmente op-geth como secuenciador, agrupando los datos de las transacciones y devolviéndolos a DuskDS como blobs. Comportamiento estándar de rollup. Pero DuskDS, el propósito real por debajo — asentamiento determinista, contratos inteligentes ZK, privacidad nativa — es un entorno de ejecución completamente distinto. Los documentos lo dicen sin rodeos: construye sobre DuskEVM para Solidity y herramientas familiares, o construye nativamente sobre DuskDS con Rust y WASM para una privacidad real a nivel de protocolo y lógica de mercado personalizada. Dos caminos. No una sola cosa unificada.
hmm… Me tomó demasiado tiempo asumir que aquí la compatibilidad con EVM significaba que el código en Solidity heredaría automáticamente la infraestructura financiera de Dusk. No lo hace. El puente entre esas dos capas es deliberado y opcional, no automático.
Lo cual me lleva a preguntarme — ¿cuántos desarrolladores que portan a DuskEVM realmente volverán a re-arquitecturar para DuskDS cuando se den cuenta de lo que dejaron sobre la mesa?
