#dusk $DUSK @Dusk
Me seguía preguntando por qué @Dusk separaría su capa de activos nativa de la capa de cómputo, en lugar de tratarlo todo como un único entorno de ejecución.
Cuanto más miraba DuskVM y DuskDS, más práctica me parecía la decisión. DuskVM se encarga de ejecutar contratos Rust/WASM, mientras que DuskDS gestiona el consenso, la liquidación y la disponibilidad de datos. Eso significa que una aplicación puede cambiar la forma en que realiza el cómputo sin obligar a que la parte responsable de mantener el estado compartido de la red tenga que cambiar con ello.
Sin embargo, aquí hay un intercambio menos evidente. La separación puede hacer la arquitectura más limpia, pero también crea una dependencia entre capas. Si la ejecución de contratos se vuelve más exigente, la presión no simplemente desaparece; hay que gestionarla sin perturbar las funciones que mantienen la cadena coordinada.
Creo que esto importa especialmente cuando el uso crece. Imagina diez aplicaciones compitiendo de repente por cómputo. Un diseño estrechamente acoplado podría hacer que esa presión afecte a operaciones más amplias de la red. Con una capa de cómputo distinta, al menos el problema puede aislarse y razonarse por separado.
Así que me interesa menos si DuskVM es “rápida” y más si esta separación se mantiene predecible cuando las cargas de trabajo se vuelven caóticas.
¿En qué momento el límite entre la ejecución y la liquidación se convierte en una ventaja real de escalado, en lugar de ser solo una preferencia arquitectónica?
#dusk #DUSK
Me seguía preguntando por qué @Dusk separaría su capa de activos nativa de la capa de cómputo, en lugar de tratarlo todo como un único entorno de ejecución.
Cuanto más miraba DuskVM y DuskDS, más práctica me parecía la decisión. DuskVM se encarga de ejecutar contratos Rust/WASM, mientras que DuskDS gestiona el consenso, la liquidación y la disponibilidad de datos. Eso significa que una aplicación puede cambiar la forma en que realiza el cómputo sin obligar a que la parte responsable de mantener el estado compartido de la red tenga que cambiar con ello.
Sin embargo, aquí hay un intercambio menos evidente. La separación puede hacer la arquitectura más limpia, pero también crea una dependencia entre capas. Si la ejecución de contratos se vuelve más exigente, la presión no simplemente desaparece; hay que gestionarla sin perturbar las funciones que mantienen la cadena coordinada.
Creo que esto importa especialmente cuando el uso crece. Imagina diez aplicaciones compitiendo de repente por cómputo. Un diseño estrechamente acoplado podría hacer que esa presión afecte a operaciones más amplias de la red. Con una capa de cómputo distinta, al menos el problema puede aislarse y razonarse por separado.
Así que me interesa menos si DuskVM es “rápida” y más si esta separación se mantiene predecible cuando las cargas de trabajo se vuelven caóticas.
¿En qué momento el límite entre la ejecución y la liquidación se convierte en una ventaja real de escalado, en lugar de ser solo una preferencia arquitectónica?
#dusk #DUSK