Algo a lo que sigo volviendo en la arquitectura de @Dusk es lo deliberadamente que separa la liquidación de la ejecución, en lugar de obligar a una sola capa a hacer ambos trabajos.
DuskDS se encuentra en la parte inferior y se encarga del consenso, la disponibilidad de datos y la liquidación. Por encima, DuskVM ejecuta contratos nativos en Rust/WASM para aplicaciones centradas en la privacidad, mientras que DuskEVM ofrece a los desarrolladores de Solidity una vía familiar mediante compatibilidad con OP Stack. Estilos de ejecución distintos, pero todo vuelve a publicarse en DuskDS y hereda la misma finalidad.
Para las finanzas reguladas, creo que este desglose es la decisión correcta. Un bono tokenizado y una aplicación de trading confidencial tienen necesidades de ejecución muy diferentes, pero ambos necesitan una liquidación que se comporte de la misma manera cada vez. Y como las licencias de NPEX cubren la pila completa, un activo no sale de su perímetro regulatorio solo porque se mueve entre entornos. Un token DUSK paga el gas en todas las capas, con un puente gestionado por validadores que transfiere valor entre ellas en lugar de activos envueltos.
Lo que me resulta fácil subestimar es que agregar entornos de ejecución es la mitad sencilla. Mantenerlos a todos anclados a una única capa de liquidación y de datos sin debilitarla es el problema de ingeniería más difícil: las uniones entre capas suelen ser donde se ponen a prueba los diseños modulares. Que Dusk suspendiera su puente para una revisión de seguridad antes del lanzamiento de DuskEVM fue una buena señal de que se toman esas uniones en serio.
Lo que quiero ver a continuación es qué tan bien resiste DuskDS cuando DuskEVM lleve hacia la liquidación una mezcla más pesada y variada de cargas de trabajo.
¿Preferirías ver que #dusk se amplíe a más entornos de ejecución, o seguir endureciendo la conexión entre las capas que ya tiene?
$DUSK #dusk @Dusk _Foundation.
DuskDS se encuentra en la parte inferior y se encarga del consenso, la disponibilidad de datos y la liquidación. Por encima, DuskVM ejecuta contratos nativos en Rust/WASM para aplicaciones centradas en la privacidad, mientras que DuskEVM ofrece a los desarrolladores de Solidity una vía familiar mediante compatibilidad con OP Stack. Estilos de ejecución distintos, pero todo vuelve a publicarse en DuskDS y hereda la misma finalidad.
Para las finanzas reguladas, creo que este desglose es la decisión correcta. Un bono tokenizado y una aplicación de trading confidencial tienen necesidades de ejecución muy diferentes, pero ambos necesitan una liquidación que se comporte de la misma manera cada vez. Y como las licencias de NPEX cubren la pila completa, un activo no sale de su perímetro regulatorio solo porque se mueve entre entornos. Un token DUSK paga el gas en todas las capas, con un puente gestionado por validadores que transfiere valor entre ellas en lugar de activos envueltos.
Lo que me resulta fácil subestimar es que agregar entornos de ejecución es la mitad sencilla. Mantenerlos a todos anclados a una única capa de liquidación y de datos sin debilitarla es el problema de ingeniería más difícil: las uniones entre capas suelen ser donde se ponen a prueba los diseños modulares. Que Dusk suspendiera su puente para una revisión de seguridad antes del lanzamiento de DuskEVM fue una buena señal de que se toman esas uniones en serio.
Lo que quiero ver a continuación es qué tan bien resiste DuskDS cuando DuskEVM lleve hacia la liquidación una mezcla más pesada y variada de cargas de trabajo.
¿Preferirías ver que #dusk se amplíe a más entornos de ejecución, o seguir endureciendo la conexión entre las capas que ya tiene?
$DUSK #dusk @Dusk _Foundation.
